[TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informational RFC

"D. J. Bernstein" <djb@cr.yp.to> Tue, 11 August 2026 10:51 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 9B248127BD5E6 for <tls@mail2.ietf.org>; Tue, 11 Aug 2026 03:51:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786445473; bh=7G8vC21xpJlHUF0gWz2D6mzV9rf0FJc0U2Eyv0ToCjg=; h=Date:From:To:Subject:In-Reply-To; b=TYaFTd694vCuQWJCz54gUiYa0YbxA8lWC7IxYRdMJOFkAy7J3hNXQqj+KlAPTkYrt FaHBnE5V8cATRyChKhhIccllTFhNnOtCVUJ68cXLt96SXVNooQEhdMA1oCWcpFC8vH mqYhrA98YPLs8ZLBZSELeNoDQUhRQhb5FXwa5/kE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qvo7uG6nItki for <tls@mail2.ietf.org>; Tue, 11 Aug 2026 03:51:12 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 3B50B127BD5DE for <tls@ietf.org>; Tue, 11 Aug 2026 03:51:10 -0700 (PDT)
Received: (qmail 3430689 invoked by uid 1010); 11 Aug 2026 10:51:03 -0000
Received: from unknown (unknown) by unknown with QMTP; 11 Aug 2026 10:51:03 -0000
Received: (qmail 2792931 invoked by uid 1000); 11 Aug 2026 10:50:51 -0000
Date: Tue, 11 Aug 2026 10:50:51 -0000
Message-ID: <20260811105051.2792930.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: last-call@ietf.org, tls@ietf.org
Mail-Followup-To: last-call@ietf.org, tls@ietf.org
In-Reply-To: <178544388075.1456866.1870629541321453783@dt-datatracker-d4d6ff9d9-fsx7d>
Message-ID-Hash: GUAGT7SCTME3KB4MPAIWGOI5ETJMNYKG
X-Message-ID-Hash: GUAGT7SCTME3KB4MPAIWGOI5ETJMNYKG
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; header-match-tls.ietf.org-1; header-match-tls.ietf.org-2; header-match-tls.ietf.org-3; header-match-tls.ietf.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Last Call: <draft-ietf-tls-mlkem-09.txt> (ML-KEM Post-Quantum Key Agreement for TLS 1.3) to Informational RFC
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

This is the first in a series of four messages responding to IESG's
"last call" for draft-ietf-tls-mlkem. (Conceptually these messages all
belong together, but I've split them at what I think are reasonable
dividing lines to avoid known problems with some mail software.)

Solo PQ, as in draft-ietf-tls-mlkem, incurs unnecessary security risks
compared to ECC+PQ, as in draft-ietf-tls-ecdhe-mlkem (now RFC 10024).

82 people spoke up on the TLS WG mailing list stating unambiguous,
non-withdrawn opposition to draft-ietf-tls-mlkem during the most recent
TLS WGLC for that document, the third WGLC after two admitted failures.

For 75 of those 82 people, I see no way that anyone can even try arguing
that anything in their messages suggests the possibility of document
modifications removing the objections.

My second and third messages in this series together give one quote from
each of those 75 people (including one from me), along with links to
archived copies of the complete original statements. This first message
provides important context for those quotes.

_Proponents_ of the document gave various arguments during WGLC that I
find non-responsive, unconvincing, and often untethered to reality. My
fourth message comments on this in more detail. What _should_ matter is
simply that the 75 quotes in my second and third messages are from 75
objectors who have not withdrawn their objections, but I think it's also
important to forestall any claims along the lines of "opponents simply
aren't listening to the arguments from proponents".

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including these four messages. See

    https://www.nytimes.com/2026/04/13/well/ai-chatbots-cancer.html?unlocked_article_code=1.4FA.nfHn.tMfHDs5AvOKj&smid=url-share

for motivation. I request that responses also avoid all use of LLMs.


## Clarification: This is not all of the opposition

The 75 quotes I'll give _do not_ include everybody who spoke up in
opposition. On the contrary, I've applied some constraining criteria,
understating the opposition, in the interests of avoiding any
accusations that the quotes overstate the level of opposition.

For example, there are credible reports of the chairs silently blocking
various further messages; but what happens if the chairs deny this? The
75 quotes include only messages that appeared on list. (This is not in
any way meant to endorse the chairs blocking messages.)

As another example, further people already registered clear statements
of opposition on list _before_ WGLC, such as Izzy Grosof writing "The
performance improvements of a non-hybrid approach are trifling; the
security risks are immense ... Do not endorse or standardize any
non-hybrid post-quantum cryptosystem, via this document or any other".
Unfortunately, the pre-WGLC timing makes it too easy for the chairs to
claim that those objections somehow don't apply to the current document
(even though the chairs on another occasion wrote "If you did not
recommend changes, then your position will remain the same, unless you
state that you are reconsidering"). The 75 quotes include only messages
that appeared on the list _during the third WGLC_ with "WG Last Call:
draft-ietf-tls-mlkem-08" inside the Subject line.

As yet another example, some statements beyond the 82 mentioned above
sound to me like opposition (e.g., Erwin Hoffman's statement) but don't
phrase this in an unambiguous way. I'm also narrowing the 82 to 75 as
explained above. (Concretely, the 82 include, but the 75 don't include,
opposition statements from Bruno Henc, Christian Huitema, David Gessel,
Jacob Appelbaum, Jan Zerebecki, Josh Cepek, and Wessel Jacobi.) I don't
want debates about these corner cases to distract attention from the
main content of what's happening here. The 75 quotes focus on cases that
avoid these distractions.

I think a special note is required here since the discussion on list
included some comments regarding an off-list public statement last month
by an ML-KEM team member. Specifically, Roberto Avanzi in

    https://web.archive.org/web/20260710230832/https://www.linkedin.com/posts/billatnapier_the-debate-around-hybrid-key-exchange-ecdh-activity-7480546081622196225-aldO

said "as a codesigner of ML-KEM myself I would not trust using it
exclusively: what if it gets broken mathematically and in the classical
computational model (I.e. non-quantum)? Hybrid is better, and the
additional time used by ECC is not significant".

Some proponents of solo PQ seem to agree that hybrid ECC+PQ is safer
than solo PQ _but_ claim that this isn't an objection to standardizing a
solo-PQ option. (As an analogy, a proponent of cars without seatbelts
might agree that seatbelts are safer but claim that this isn't an
objection to standardizing a car-without-seatbelt option.) It's not that
a message from Roberto Avanzi appeared on list during WGLC expressing
his position on this document. I don't see any point in arguing about
what this hypothetical message might have said. In particular, he's not
counted as one of the 75 (or 82) people. The 75 quotes focus instead on
statements from 75 people who sent messages to the list.


## Clarification: There was also support

Opponents were _not_ the only people sending messages to the TLS list
regarding draft-ietf-tls-mlkem during WGLC. On the contrary, I noticed
support statements from

    * NSA employee Mark Motley (from his icloud address),
    * NSA employee Mike Jenkins,
    * NSA employee Morgan Stern,
    * NSA employee Nicholas Gajcowski,
    * NSA employee Peter Yee (from his "Akayla" address),
    * NSA employee William Layton,
    * Cisco employee David McGrew,
    * Cisco employee Eliot Lear (from his home address),
    * Cisco employee Richard Barnes (from his home address),
    * Cisco employee Scott Fluhrer,
    * Google employee David Adrian (from his Michigan-alumnus address),
    * Google employee David Benjamin,
    * Google employee Roland Shoemaker,
    * Google employee Sophie Schmieg,
    * GCHQ employee "Flo D",
    * GCHQ employee "Michael P",
    * GCHQ employee "Peter C",

and other people, such as "Q Misell" and "Soatok Dreamseeker".

The multiple occurrences of NSA etc. above are impossible to reconcile
with IETF's claim not to be a pay-to-play organization, even without
regard to the documented money flow regarding draft-ietf-tls-mlkem.
However, resolving this is not necessary for this message: there were
far fewer repeated employers in opposition statements, so removing
duplicates would only marginally affect the 75 number.

I should also note that IETF doesn't have a real-name policy, so there
doesn't seem to be any bar on the inputs from "Flo D", "Michael P",
"Peter C", "Q Misell", or "Soatok Dreamseeker" supporting the document.
It seems that there were five opponents in a similar situation, which
again is a very small fraction of the opposition, so a real-name policy
would again make little difference for this message.


## The chairs have grossly misrepresented what happened

The way that the chairs have reported the WGLC events is insanely far
from the facts. I'm concerned about the possibility of IESG placing so
much trust in the chairs that IESG doesn't even _read_ the 75 quotes. So
let me emphasize that (1) the chairs are wrong about the facts---I'll go
through details here---and (2) RFC 2026 says, regarding the "Last-Call"
procedures, that "Comments on a Last-Call shall be accepted from anyone".

The chairs sent email "WG Last Call: draft-ietf-tls-mlkem-08 (Ends
2026-07-08)" dated 24 Jun 2026 08:00:07 -0700 to the TLS mailing list.
That message included the following claim: "Significant developments
have occurred both within this document and in the broader TLS ecosystem
to address the concerns raised in the last WGLC. Therefore, the third
consensus call is warranted."

The reader understands "address the concerns" to mean that _all_ the
concerns were addressed, not just some tiny corner of the concerns. But
the claim that the concerns were addressed is, to borrow Cory Doctorow's
wording, "one of those radioactively false statements whose falsity is
so glaring that it can be seen from orbit".

There were 22 people listed (with links for verification) in

    https://blog.cr.yp.to/20260405-votes.html

as objecting in the second (failed) WGLC. Only 3 of those dropped their
objections after what the chairs claim were "significant developments
... to address the concerns raised in the last WGLC": "Recommended: Y"
for another document switched Stephen Farrell's stated position on this
document from objecting to neutral; a prohibition on key reuse switched
John Mattsson's stated position from objecting to supporting; a
"symbolic" analysis changed Muhammad Usama Sardar's stated position from
objecting to neutral-maybe-supporting.

Within the other 19 out of 22, the 19 who _haven't_ dropped objections,
the following quotes show that at least 15 were _clearly_ expressing
concern about draft-ietf-tls-mlkem incurring unnecessary security risks
compared to draft-ietf-tls-ecdhe-mlkem (again, these are quotes from the
second WGLC, separate from the 75 quotes in my second and third messages
of people stating opposition in the third WGLC), with the numbers being
as in https://blog.cr.yp.to/20260405-votes.html:

    * #4, Simon Josefsson: "I don't think the TLS WG should publish
      this document. Pure PQ KEM's in TLS comes with cryptographic
      risks, and the risks aren't sufficiently motivated by reasonable
      needs here."

    * #5, Joshua Nabors: "The purpose of TLS 1.3 is to choose a small
      selection of the most conservative ciphersuites for long-term
      confidentiality. Introducing standalone ML-KEM alongside the
      currently deployed hybrids goes against that principle. ... I do
      not support publication of this document."

    * #6, me.

    * #7, Izzy Grosof: "The performance improvements of a non-hybrid
      approach are trifling; the security risks are immense ... Do not
      endorse or standardize any non-hybrid post-quantum cryptosystem,
      via this document or any other."

    * #8, Nadim Kobeissi: "I would like to register my objection to the
      publication of this draft. ... Hybrid constructions protect us
      from classes of attacks that pure-PQ constructions do not protect
      us against. Hybrid constructions have a negligible overhead
      compared to pure-PQ constructions."

    * #10, Nicola Tuveri: "I oppose to the publication of this draft.
      The motivation isn't substantial enough, the risks of abandoning
      hybrids are clear and substantiated by evidence, the gains in
      shedding a smaller amount of bytes/cycles quantifiably irrelevant."

    * #12, Fabiana da Pieve: "it is not clear to me yet the main issue -
      the reason why we would go for a path that is not based on a
      common good sense, by removing the assurance of security given by
      'old' good crypto. This adds up to the fact that the cost of
      keeping it is actually cheap, and to the fact that an outstanding
      work has been done already to deploy hybrid ML-KEM in TLS. Hybrid
      ML-KEM is such a cheap way to reduce risks. So, overall, I still
      cannot crystallize in my head what is the advantage in security
      and costs in throwing away ECC and how to reconcile this with what
      is pushed in my own part of the world. Not sure what would be the
      advantage in fragmenting things now."

    * #13, Tanja Lange: "I strongly object to the publication. ... Users
      will take the reputation of the IETF and understand this as a
      recommendation, whether it says = N or not. ... I love formally
      verified software like everybody else and it's the best we can do,
      but also that is still a research area and we are currently in a
      situation where code can be formally verified and have bugs at the
      same time. That's not even addressing the mathematical stability
      of the problems. ... If I understand the email from Keegan
      correctly then we have a perfect example of the damage that this
      RFC can be causing as the Canadian government seems to be waiting
      for this RFC in order to recommend ditching hybrids in favor of
      fully exposed PQC. It's not hypothetical that people would ignore
      the = N, we have a stated intention on list."

    * #15, Jacob Appelbaum: "I am in full agreement with Nadim and
      others on the list pushing back against publication of this draft.
      ... It is prudent from a risk management perspective to use hybrid
      constructions with an appropriate combiner."

    * #16, David Stainton: "I oppose this draft. We should use hybrid
      KEMs instead of just MLKEM." Later: "Are we really optimizing TLS
      1.3 around 32 bytes? If so, then why? ... The safest available
      path during transition should be the baseline, not the exception."

    * #17, Ivan Visconti: "I completely agree with David."

    * #18, Thomas Bellebaum: "We should only publish this once we are
      collectively convinced that ML-KEM, when implemented, provides
      adequate security. This is not the case. Until that point, we
      should push for hybrids."

    * #19, Ludovic Perret: "I completely agree with Tanja and am opposed
      to this draft at this stage."

    * #20, Tibor Jager: "I think it is unwise to rely only on ML-KEM (or
      any other scheme based on relatively new hardness assumptions),
      and currently do not support any draft that does not use hybrid
      cryptography. In particular when the use of hybrid crypto comes
      with negligible overhead, as for ML-KEM + ECC. For almost every
      broken cryptosystem there was a time when there seemed to be no
      evidence that it is weak. ML-KEM still needs to stand the test of
      time."

    * #22, Christoph Striecks: "+1 on Tibor's thoughts below."

That's 15 clear counterexamples to the chair claim that "Significant
developments have occurred both within this document and in the broader
TLS ecosystem to address the concerns raised in the last WGLC". None of
those developments addressed these concerns about draft-ietf-tls-mlkem
incurring unnecessary security risks vs. draft-ietf-tls-ecdhe-mlkem.
None of these people ever withdrew their objections.

In short---I'll write this with all due respect to the chairs---the
chair rationale for the 24 June 2026 WGLC was an outright lie. But wait:
the situation is even worse than that.

In the same WGLC, the chairs asked people to "refrain from further
discussion on this topic". When some people engaged in discussion, the
chairs sent, e.g., email dated 28 Jun 2026 15:44:52 -0400: "AGAIN!!!!
Let's stick to the consensus call, 'I support' or do 'I do not support'
as was requested in the email that began this thread."

The repeated chair demands to just shut up and vote (I'm not saying that
this is how they phrased it) certainly didn't stop _all_ discussion, but
those demands surely deterred quite a few of the opponents from saying
more than "I do not support" and from engaging in discussion.

(Many of the proponents were similarly brief in their messages. For
example, here's the message from NSA's Peter Yee: "As the IEEE 802.11
liaison to IETF, I support publication of this document." Note that IETF
policy says that people participate as individuals.)

What's astounding about the chairs discouraging discussion is that the
chairs later used a supposed lack of "demonstrated expertise" as an
excuse for disenfranchising people, in particular disenfranchising more
opponents than proponents. Were they planning this from the outset? I'll
come back to the disenfranchisement in a moment.

At what I guess was exactly the end of the designated WGLC period AoE
(9 Jul 2026 05:00:00 -0700), one of the chairs sent email as follows:
"The working group last call for draft-ietf-tls-mlkem-08 has concluded.
Responses received after this point will not be considered in the
consensus call. Sean and I will go through the responses to see what the
consensus is. Due to the amount of responses this will take some time."

The chairs then sent email dated 19 Jul 2026 04:31:20 -0700 with claims
that "there is rough consensus to move forward" and that "We believe we
have consensus to publish this as an informational working group
document".

https://web.archive.org/web/20260704221723/https://www.ietf.org/process/wgs/
says that "rough consensus" means "that a very large majority of those
who care must agree, and that those in the minority have had a chance to
explain why and their points have been addressed, even if they were not
agreed with". The chair argument was, however, _not_ structured as
quoting these criteria and checking whether the criteria were met. In
particular, the chairs never asserted that a "very large majority of
those who care" supported this document.

Instead the chairs made the following two claims, without evidence,
regarding the level of support for the document: (1) "By pure numbers,
more people want to progress the document than not"; (2) "if we look at
pre-existing WG participants or people with demonstrated expertise,
roughly 7/10 WG participants favor advancing the document".

Various WG participants challenged these claims. For example, Fabiana da
Pieve, Team Leader Post-Quantum Cryptography, European Commission, DG
Communications Networks, Content and Technology, Unit C4 - Emerging &
Disruptive Technologies, wrote the following:

> Can I kindly ask if there is evidence that can be provided for your
> statements about the numbers, and more info on the weights / method
> you apply to weigh answers, from both sides ?
>
> I imagine you have a table/a scheme/something, with participants, an
> established method for the weights, weights associated to each person
> on both sides, other elements you may have considered relevant ....

But the chairs refused to provide any evidence for their claims about
the numbers, and refused to provide any explanation of how they
evaluated "demonstrated expertise": "All of the mail used as part of
this process is publicly available. We do not intend to release any
further detailed analysis including 'numbers' or 'weights/methods'."

To see that the "publicly available" excuse doesn't work, consider three
hypothetical observers:

    * Observer #1 thinks that anyone who stated support for this
      document is either incompetent or corrupt or both, and that anyone
      who stated opposition was, by saying so, demonstrating sufficient
      expertise for purposes of the WGLC.

    * Observer #2 is the other way around.

    * Observer #3 has invented some more complicated secret rule for
      deciding who has "demonstrated expertise".

Observers #1 and #2 would certainly arrive at wildly different tallies
of the number of "people with demonstrated expertise" in support of the
document, and wildly different tallies of the number of "people with
demonstrated expertise" opposing the document.

Observer #3 could arrive at many different possibilities between those
extremes, but there are vastly more possibilities for the secret rules,
so there is no way for readers to work backwards from the numbers---or
from a vague "roughly 7/10" claim---to the secret rules.

If the chairs hadn't disenfranchised anybody then reaching 65% support
(the minimum possibility for "roughly 7/10") with 82 people in
opposition would have meant at least 153 people in support. That's
clearly nowhere near reality. Evidently the chairs disenfranchised many
opponents. But we don't have a list from the chairs saying

    * "The chairs decided to disenfranchise person A after deciding on
      the following grounds that A didn't demonstrate expertise: ..."

    * "The chairs decided to disenfranchise person B after deciding on
      the following grounds that B didn't demonstrate expertise: ..."

and so on.

The chairs claimed that "a consensus call is not a vote". But the chairs
explicitly relied on their "roughly 7/10" claim as the basis for
claiming "rough consensus": "if we look at pre-existing WG participants
or people with demonstrated expertise, roughly 7/10 WG participants
favor advancing the document, which shows rough consensus to move the
document forward". The chairs refused to provide evidence to back up
the 7/10 claim. No legitimate SDO would tolerate such chair behavior.

With all due respect to the chairs: Do the words "roughly 7/10" sound
like they're coming from chairs who actually collected tallies pro and
con, as opposed to chairs fabricating a ratio that they think sounds
good enough to ram this controversial document through IETF?

Meanwhile the chairs told a different story in their official report on
this document, claiming that they had "focused their consensus judgement
on people that participated in TLS prior to the last WGLC":

    https://web.archive.org/web/20260729142704/https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/shepherdwriteup/

Wait, what happened to the second part of "pre-existing WG participants
or people with demonstrated expertise"? Were the chairs counting new
participants who they thought had "demonstrated expertise", or not?

Were the chairs disenfranchising, for example, famed cryptanalyst Orr
Dunkelman, who spoke up against this document during WGLC (and also
pointed out the Roberto Avanzi comment) but hadn't sent email to the TLS
list before?

In response to a challenge from another WG participant, the chairs
claimed in

    https://web.archive.org/web/20260810164318/https://mailarchive.ietf.org/arch/msg/tls/ckh4S8usKpKrp_Ai12xAAJzdHQs/

that "Consensus is determined by assessing the quality and resolution of
technical arguments rather than by simple counts". This begs even more
questions, and in any case it's irreconcilable with how the chairs had
previously described their consensus evaluation: "if we look at
pre-existing WG participants or people with demonstrated expertise,
roughly 7/10 WG participants favor advancing the document, which shows
rough consensus to move the document forward".

With, once again, all due respect to the chairs: How can the chairs be
trusted if they keep switching stories about what they did?

The chairs also claimed in

    https://web.archive.org/web/20260729142704/https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/shepherdwriteup/

that initially "the working group was fairly split between participants
that wanted to publish the document and those that did not" but that
during 3 WGLCs "changes to the document, changes to other documents and
liaison statements from other SDOs helped to shift the consensus to
publication".

This is, aside from being at the end of WGLC instead of the beginning,
essentially the same as the radioactively false claim that I addressed
above. Yes, there were a _few_ people such as John Mattsson dropping
their objections, but the switches are only a small fraction of the
overall opposition.

Nowhere have the chairs listed the people who objected before. Nowhere
have the chairs even admitted how many objectors there were. Nowhere
have the chairs listed the people who they claim dropped objections.
Nowhere have the chairs admitted how many people objected during the
most recent WGLC.

The chairs complained that "there were many new participants who joined
the discussion during the WGLC, due to extensive social media activation
of the last call". Let's compare this chair complaint to the facts:

    * NSA employee Mark Motley had never sent mail to the list before.

    * NSA employee Mike Jenkins had never sent mail to the list before.

    * NSA employee Morgan Stern had never sent mail to the list before.

    * NSA employee Nicholas Gajcowski had sent mail to the list only
      once before, namely to similarly support draft-ietf-tls-mldsa.

    * NSA employee Peter Yee had sent just seven short messages to the
      list between 2014 and 2019, plus one short message in 2025.

    * NSA employee William Layton had sent exactly one previous message
      to the list, three sentences.

These six NSA employees sent mail to this mailing list during this WGLC
to support draft-ietf-tls-mlkem. Are the chairs claiming that the new
participation by NSA employees on the TLS mailing list was "due to
extensive social media activation"?

When WGLC started, I saw a bunch of new WG participants showing up on
the mailing list to state _support_ for the document. I posted

    https://nsa.2026.action.cr.yp.to

in response: pointing to NSA's vote-packing; naming NSA's Mike Jenkins
as an example; saying "This is _allowed_ under IETF rules, which say
that 'There is no membership in the IETF' and that 'Anyone can
participate by signing up to a working group mailing list'"; and saying
"You can have your voice heard too" with appropriate pointers.

After that, faced with more and more people speaking up in opposition,
the chairs started making up rules to disenfranchise those people. They
didn't report the actual sequence of events.

What I'm saying about the number of previous messages is based on my own
archives of the mailing list going back to when I joined last century,
not IETF's more limited archives. I'm mostly a reader---there are many
aspects of TLS that I've never commented upon---but over the years I've
sent 189 messages that appeared on list (before this month), plus some
further messages that the chairs refused to post. My messages often have
in-depth analyses of TLS issues. Meanwhile NSA pays people to show up,
contributing essentially nothing. The chairs claim that they "have the
remit to judge consensus based on input such as taking into account the
level of previous participation of the sender"; how much did the chairs
discount the NSA input? There are no public records answering such
questions; there's just the "roughly 7/10" claim.

Suppose that, starting with 82 people who had filed clear objections,
the chairs disenfranchised everyone except "people that participated in
TLS prior to the last WGLC"---one of their conflicting stories about
what they did. That would still leave 19 people who had sent email to
the list before and were now filing clear objections:

    (1) Andrew Lee.
    (2) Christian Huitema.
    (3) David Stainton.
    (4) Fabiana Da Pieve.
    (5) Harry Halpin.
    (6) Jacob Appelbaum.
    (7) Justin Schnurbusch.
    (8) Ludovic Perret.
    (9) Nadim Kobeissi.
    (10) Nicola Tuveri.
    (11) Peter Gutmann.
    (12) Rob Sayre.
    (13) Simon Josefsson.
    (14) Sven Schaege.
    (15) Tanja Lange.
    (16) Thomas Bellebaum.
    (17) William Whyte.
    (18) Yaakov Stein.
    (19) Me.

This is _not_ counting people such as Izzy Grosof and Ivan Visconti who
had already registered objections. By issuing one WGLC after another and
pretending that the earlier objections ("the concerns raised in the last
WGLC") no longer apply, the chairs have improperly shifted burdens to
opponents to state objections repeatedly. Such burdens are a much bigger
problem for people on the public-interest side than for companies that
can afford the time to keep sending people to IETF.

Did the chairs admit that their abusive train of WGLCs, combined with
their dismissal of all prior filings and their mass disenfranchisement
of 63 new opponents, _still_ left 19 people objecting, almost as many as
the 22 who had objected in the second WGLC? No.

A few people withdrew their objections. The chairs wildly exaggerate
this into suggesting, falsely, that the opposition disintegrated: "The
consensus for this document was built over 3 WGLCs. Initially the
working group was fairly split between participants that wanted to
publish the document and those that did not. Over this time changes to
the document, changes to other documents and liaison statements from
other SDOs helped to shift the consensus to publication."

I should also note that IETF says "Anyone can participate by signing up
to a working group mailing list". When I'm looking at who has sent mail
to the list, I don't see people who have subscribed and diligently read
without ever seeing the need to speak up. They're WG participants too.

While my focus here is on the disconnect between the chair statements
and the facts, I also want to state plainly that the disenfranchisement
here is an outrageous abuse of power. The chairs are overtly tilting the
decision on this matter towards those who were able to afford earlier WG
participation regarding other topics---but, again, IETF says it isn't a
"pay-to-play organization". IETF also says that "participation is free
and open to all interested individuals. ... IETF activities are
conducted with extreme transparency, in public forums. Decision-making
requires achieving broad consensus via these public processes". IETF
says that WG decisions require, among other things, that a "very large
majority of those who care must agree". RFC 2418 has an absolute rule
that "51% of the working group does not qualify as 'rough consensus' ";
it doesn't say "51% of a quorum", and the proponents here are obviously
very far below 51% of the TLS WG.

I plan to file a complaint with the chairs under RFC 2026, Section 6.5,
regarding their consensus claims. However, my understanding is that the
RFC 2026 procedures require a "detailed and specific description of the
facts of the dispute"; the material I have collected so far covers only
part of the dispute. It's important, for example, to provide full
details of how NSA and its "vendors" packed this WGLC, while, amazingly,
_volunteers_ speaking up to represent the public interest were subjected
to accusations of "astroturfing". "Astroturf" means "to pay people to
display overt and apparently spontaneous grassroots support for a
particular product, policy, or event":

    https://www.collinsdictionary.com/dictionary/english/astroturf

I won't have the complaint done before IESG's deadline for the current
"last call". Even though I hope the chair declaration of consensus ends
up being overturned, that isn't a reason to avoid meeting the deadline.


---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

That language hereby applies to this document. This is not disclaiming
or limiting the applicability of IETF policies; it is strictly following
IETF policies. IETF has similarly published, e.g., RFC 7425, which says
the following: "This document may not be modified, and derivative works
of it may not be created, except to format it for publication as an RFC
or to translate it into languages other than English."

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

IETF Executive Director Jay Daley says that informative text can
"contextualise and disambiguate normative text as it does here". When he
was asked what he claimed was ambiguous about the BCP 78 "explicitly
disallowed" provision, he did not reply. There is no ambiguity, and an
"Exposition of Why These Procedures Are the Way They Are" is not a
change to the procedures.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. However, BCP 78's default
position, without the opt-out, is a power grab that goes far beyond
redistribution and far beyond what copyright law allows as fair use
(such as giving quotes for purposes of commentary). BCP 78 authorizes
arbitrary modifications, such as plagiarism, quote falsification, data
falsification, and IETF management selling IETF mailing-list text in
bulk to AI companies spreading further misinformation.

For example, Google, a major source of IETF funds, systematically
ingests IETF mailing-list text into its AI system, which modifies the
text and frequently spits out misinformation to readers. IETF is only
one of many terms-of-service battlegrounds; this is not a reason to skip
the battle.

IETF itself also carries out problematic modifications. For example, in
May 2025, IESG posted an IESG-mangled version of an appeal that I had
filed, and then in its response confused exactly the point obfuscated by
that mangling. When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management had the power to do whatever it wanted.