To tls-chairs@ietf.org and rfc-editor@rfc-editor.org, cc'ing
tls@ietf.org for transparency:

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.

Furthermore, for 75 of these 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.

The WG chairs nevertheless forwarded draft-ietf-tls-mlkem to IESG for
issuance as an RFC, falsely claiming that this was "on behalf of the TLS
working group". The WG chairs also falsely claimed that the WG had
"consensus to publish this as an informational working group document",
that the WG had "rough consensus to move the document forward", etc.

I'm hereby complaining to the WG chairs about their false claims of
"rough consensus" and of "consensus", and about the other procedural
violations described below. I'm hereby asking the WG chairs to withdraw
their false claims, to undo the forwarding of this document to IESG, and
then, given the pattern of abuses, to resign their positions as chairs.

I'm also hereby asking rfc-editor@rfc-editor.org to confirm that it will
pause processing of this document until there has been full resolution
of all complaints filed, including this one. If decisions are locked
into place before complaints about those decisions are resolved then the
complaint procedures are meaningless.

To avoid a source of inaccuracies, I strictly avoid all use of LLMs in
writing all of my messages, including this one. 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.


1. Examples of the content of opposition statements

I'm hereby incorporating

    https://web.archive.org/web/20260815191224/https://mailarchive.ietf.org/arch/msg/tls/g-oB-wLzxRO9VCrX1FPHQxVEfBE/
    https://web.archive.org/web/20260811110635/https://mailarchive.ietf.org/arch/msg/tls/0yf-y5TdzghP8F9j3hlNoSV20jc/

into this complaint by reference. What these show is one quote from each
of the aforementioned 75 people (including one from me), along with
links to archived copies of the complete original statements.


2. Clarification: This is not all of the opposition

The 75 quotes _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. (Erwin Hoffman later elaborated on
his position, for example writing "I don't favor publishing this as RFC
in the current version", but I'm still not counting him within the 82
since this elaboration was after WGLC. Again, I don't want to be accused
of overstating the level of opposition that appeared during WGLC.

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 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.

In short, the list of 75 opposition statements is bulletproof.


3. 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".

I should 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
is a very small fraction of the opposition.)

The many occurrences of NSA etc. above are impossible to reconcile with
IETF's claim not to be a pay-to-play organization. (There were far fewer
repeated employers in opposition statements.) I think it's important to
say more about the corruption here.

In the TLS WG, specs for solo PQ were introduced without any pretense of
an engineering rationale. Instead there were claims that NSA demands
solo PQ and will refuse to authorize government purchases of ECC+PQ.

For example, in December 2024, a Cisco employee wrote the following:
"There are people whose cryptographic expertise I cannot doubt who say
that pure ML-KEM is the right trade-off for them, and more importantly
for my employer, that's what they're willing to buy. Hence, Cisco will
implement it; I am essentially just asking for code points." Certainly
"willing to buy" is a statement about funding, evidently from a source
large enough to dictate Cisco actions, evidently from a source asking
for non-hybrids, evidently from "people whose cryptographic expertise I
cannot doubt"; if that source isn't NSA, who is it?

Any doubt was removed in June 2025, when NSA's Mike Jenkins posted the
following: "As the CNSA 2.0 profiles should make clear, we are looking
for products that support /standalone/ ML-DSA-87 and /standalone/
ML-KEM-1024. If there is one vendor that produces one product that
complies, then that is the product that goes on the compliance list and
is approved for use. Our interactions with vendors suggests that this
won't be a problem in most cases." Evidently there are many companies
happy to jump when NSA says jump.

See https://blog.cr.yp.to/20251004-weakened.html#tls for more quotes
and links for verification.

What effect did NSA and its "vendors" have on the WGLC? Above I listed
six NSA employees filing support statements, four Cisco employees filing
support statements, four Google employees filing support statements, and
three employees of NSA's UK mass-surveillance partner, GCHQ, filing
support statements. Note that

    https://www.theguardian.com/uk-news/2013/aug/01/nsa-paid-gchq-spying-edward-snowden

revealed that NSA was secretly paying GCHQ "to secure access to and
influence over Britain's intelligence gathering programmes", and the
GCHQ director who created the UK "National Cybersecurity Centre" wrote
in

    https://web.archive.org/web/20200113194346/https://rusi.org/sites/default/files/20190227_hannigan_final_web.pdf

that "Complete ownership by GCHQ was also key to making the NCSC
acceptable to foreign intelligence allies".

Akamai, as another example, is the sole provider of the Global Content
Delivery Service to the Defense Information Systems Agency. There were
support statements from

    * Akamai employee Benjamin Kaduk ("lean slightly towards publishing"),
    * Akamai employee Jan Schaumann, and
    * Akamai employee Rich Salz.

Cloudflare and Nokia announced in March 2026 their participation in the
"Missile Defense Agency Scalable Homeland Innovative Enterprise Layered
Defense (SHIELD) indefinite-delivery/indefinite-quantity (IDIQ) contract
with a ceiling of $151B". There were support statements from

    * Cloudflare employee Christopher Patton and
    * Nokia employee Tirumal Reddy.

There were also support statements from

    * Department of Defense employee Ann Krieger,
    * Department of Defense lifer Michael StJohns, and
    * Lincoln Labs employee Uri Blumenthal,

where Lincoln Labs, despite being hosted at a university, is actually a
fully owned subsidiary of the Department of Defense.

The author of the solo ML-KEM document is employed by SandboxAQ, which
is funded by CIA's venture arm In-Q-Tel. She had the professionalism to
avoid filing a support statement for her own document, but there were
support statements from

    * SandboxAQ employee James Howe and
    * SandboxAQ employee Carlos Aguilar Melchor.

There was also a support statement from

    * CSE employee Jonathan Hammell

where CSE is NSA's Canadian mass-surveillance partner.

I've listed 28 people above. This isn't complete, but it's enough to
show a massive effect of NSA and its "vendors" upon this WGLC.


4. Examples of the content of support statements

I'm hereby incorporating

    https://web.archive.org/web/20260811110701/https://mailarchive.ietf.org/arch/msg/tls/yw4jeDTFmcHdWDehavATABn8pio/

into this complaint by reference. This quotes and replies to various
statements posted on the TLS list by proponents of draft-ietf-tls-mlkem
during WGLC.

For showing that there's no consensus here, it's sufficient---even
overkill---to observe that the aforementioned 75 quotes are from 75
objectors who have not withdrawn their objections. However, since the
chairs have been making up excuses for ignoring the opposition, I think
it's important to forestall any claims along the lines of "opponents
simply aren't listening to the arguments from proponents".

I find the arguments from proponents non-responsive, unconvincing, and
often untethered to reality. There are point-by-point responses to what
proponents are saying; there aren't point-by-point responses to the bulk
of what opponents are saying.


5. Responding to NSA's vote-packing

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.

This wasn't the sole source of volunteers speaking up to represent the
public interest, but it did contribute. What I find astounding is that
these volunteers were then subjected to accusations of "astroturfing".

Do the people using the word "astroturf" even understand what it means?
It 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

See the word "pay" there?

Let's be clear. Volunteers speaking up in the public interest aren't
corrupting the process. NSA is corrupting the process. NSA is waving
around money to ram security-damaging specs through IETF.


6. The chairs have grossly misrepresented what happened

The way that the chairs have reported the WGLC events is insanely far
from the facts.

The third WGLC began with the chairs sending 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".

Specifically, "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 (numbered here the same way
as in https://blog.cr.yp.to/20260405-votes.html) 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 of people
stating opposition in the third WGLC):

    * #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"?

As noted above, I explicitly _responded to_ NSA's vote packing by naming
NSA's Mike Jenkins as an example and calling for volunteers to speak up
in the public interest. NSA was already packing the vote before this
happened.

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 August), 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.

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".
Having the chairs disenfranchise people is an outrageous abuse of power.


7. The failure to resolve objections

Many objections were raised on list to solo PQ in TLS. Many of those
objections have not been resolved. Three people withdrew their
objections, but many more did not, as the 75 quotes illustrate.

None of the unresolved objections have received a group response. Some
objections have received individual responses; others have not. Some of
the individual answers obviously cannot reach group agreement.

For example, one proponent answered security objections to non-hybrids
by claiming that nobody outside NSA would use non-hybrid ML-KEM in TLS
so any breaks will be "not impacting anyone else". Meanwhile another
proponent claimed that deploying ECC+ML-KEM in TLS, rather than
non-hybrid ML-KEM in TLS, would require a subsequent "large-scale
engineering effort" for his company and would "consume literal years of
my life". As these quotes illustrate, the case stated for non-hybrids is
a pile of wildly incoherent claims regarding what's happening here.

The "not impacting" and "years of my life" claims haven't been
withdrawn. Both of them are wrong: there's overwhelming evidence that
the non-hybrid specs are aimed at changing behavior outside NSA;
meanwhile the "large-scale engineering effort" text is attacking a
strawman. But my point isn't simply that the case for the spec is full
of errors; my point is that _the working group_ hasn't settled on a case
for the spec, and hasn't even tried, which is why one finds proponents
stating irreconcilable arguments for the spec.


8. The lack of consensus

The Longman dictionary says that "consensus" is "an opinion that
everyone in a group agrees with or accepts". There are ample resources
available such as https://www.seedsforchange.org.uk/shortconsensus
explaining the process and value of building consensus, while
emphasizing that consensus means unanimous acceptance.

With this concept of consensus, obviously the chairs were wrong in
claiming consensus. But this is not the end of the analysis. The word
"consensus" can be used in less stringent ways: for example, another
source says that "consensus" can be "general agreement : unanimity" or
"the judgment arrived at by most of those concerned".

Legitimate standards-development organizations need clear,
well-documented procedures to protect against errors and abuse. These
organizations converged many years ago on a concept of "consensus" that
_can_ allow non-unanimous standards but that still imposes important
procedural constraints to protect the interests of minorities. The
central requirements are as follows:

    * general agreement;

    * fair consideration of each comment;

    * a process of attempting to resolve each objection; and

    * documentation---for any objection that was not resolved but that
      was instead overridden by general agreement---of _why_ that
      objection was overridden.

For example, the ISO/IEC Directives say "Committees are required to
respond to all comments received"; define "consensus" as "General
agreement, characterized by the absence of sustained opposition to
substantial issues by any important part of the concerned interests and
by a process that involves seeking to take into account the views of
all parties concerned and to reconcile any conflicting arguments"; and
say "Consensus, which requires the resolution of substantial objections,
is an essential procedural principle and a necessary condition for the
preparation of International Standards that will be accepted and widely
used". Similar comments apply to ANSI, ASME, etc.

_None_ of these requirements were met when the TLS chairs claimed WG
consensus to issue an RFC on solo ML-KEM in TLS:

    * The working group did not reach general agreement on this action.
      The relevant meaning of "general" from the Longman dictionary is
      "shared by or affecting most people, or most of the people in a
      group"; "most" means "nearly all of the people or things in a
      group, or nearly all of something".

    * There was not fair consideration of each comment. There was not a
      process of attempting to resolve each objection. There was not
      documentation, for each objection, of why that objection was
      overridden.

Fundamentally, conflict resolution was replaced by a voting process,
which was then warped by the chairs selectively disenfranchising many
opponents.

When the chairs claimed WG consensus, they were providing false
information to essentially all readers, including readers who expect the
word "consensus" to mean unanimity, readers who expect it to mean
general agreement, and readers familiar with how legitimate
standards-development organizations operate.

It doesn't matter here whether another definition of "consensus" for
IETF insiders is buried somewhere in IETF documents (I'll discuss "rough
consensus" below). IETF management's claims of consensus are _public_
statements and need to avoid deceiving a general audience.


9. The lack of "rough consensus"

RFC 2418 includes some absolute requirements for WG decisions. One of
them is to reach at least "rough consensus". This did not happen for
draft-ietf-tls-mlkem.

RFC 2418 states that "51% of the working group does not qualify" as
"rough consensus". This does not merely say that 51% _of the people
responding_ does not qualify; it says that 51% _of the working group_
does not qualify.

In this case, the supporters didn't even reach a majority of the people
who spoke up regarding this document during WGLC, let alone a majority
of the TLS working group. The level of support here is very far below
the level of support that RFC 2418 says is _still_ not enough.

Claiming "rough consensus" violated this RFC 2418 rule. Claiming "rough
consensus" without even posting the list of names counted pro and the
list of names counted con is another outrageous abuse of power, a direct
assault against the concept of independent review of chair actions.

IETF says in

    https://web.archive.org/web/20250603130154/https://www.ietf.org/about/introduction/

that "Anyone can participate by signing up to a working group mailing
list". RFC 2418 says the same: "Participation is open to all. This
participation may be by on-line contribution, attendance at face-to-face
sessions, or both. Anyone from the Internet community who has the time
and interest is urged to participate in IETF meetings and any of its
on-line working group discussions."

So, according to IETF rules, even TLS newbie Mike Jenkins from NSA
counts as a TLS WG participant---as do hundreds of people who _have not_
stated support for this spec. The chairs do not have authority to
exclude WG participants.

IETF's page

    https://web.archive.org/web/20260704221723/https://www.ietf.org/process/wgs/

further 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 level of support here wasn't even in the same
universe as a "very large majority of those who care"; furthermore, many
points from opponents haven't been addressed.

The same page says that it is "up to the chairs to decide when the
Working Group has reached rough consensus". This is an assignment of a
clerical duty to do the work of collecting the necessary information.
It's not an assignment of authority for Humpty Dumpty to declare "rough
consensus means just what I choose it to mean".

Back in 2014, IETF's research arm IRTF refused to remove an NSA employee
as co-chair of CFRG. This refusal was by the IRTF chair, who quoted IRTF
rules stating that co-chairs "perform the administrative functions of
the group", and who concluded that "co-chairs are little more than group
secretaries. Their ability to influence the technical work of the group
is little different from that of any other group participant". (See
<https://mailarchive.ietf.org/arch/msg/cfrg/Aqe9HaZQ4JStGeXeWujt6hLS6uU/>.)

But IETF rules, just like IRTF rules, state that co-chairs merely
"perform the administrative functions of the group"! See RFC 2418.

Furthermore, saying that "rough consensus" is _required_ doesn't mean
that it's _sufficient_. The notion that it's _sufficient_ is directly
contradicted by other IETF statements. For example:

    * IETF prominently claims that it does not vote.

    * IETF also prominently claims that its "decision-making requires
      achieving broad consensus".

    * Every WG-issued RFC claims "consensus of the IETF community". This
      doesn't say "rough". It doesn't say "majority support". It doesn't
      say "support of a majority within the people who spoke up on a WG
      mailing list during a two-week WG last call, not counting those
      who were disenfranchised by out-of-control WG chairs".

The chair claim of consensus is fraudulent. The chair claim of "rough
consensus" is fraudulent. All WG-issued RFCs are stamped as "consensus
of the IETF community", which in this case will also be fraudulent.

My complaint is primarily about the dishonesty here, where a
controversial document is being non-consensually rammed through IETF and
falsely labeled as consensus. But, to be clear, dishonesty is not the
_only_ problem here. From a security perspective, security-damaging
specs should not be allowed as any type of RFC, even something as
minimal as an independent-stream RFC that makes no claims regarding
consensus. Purchasing managers frequently specify RFCs without checking
the wording of the RFCs.

(On 3 April 2026, Eric Rescorla wrote "I think it's clear that many
regard the publication of an RFC by the TLS WG as a form of endorsement,
even when Recommended=N ... this is precisely why the publication of
some documents has become so controversial". People who don't actually
read RFCs won't see "Recommended=N"---and also won't see whether those
are WG documents in the first place.)

Having said that: False claims of consensus make the situation much
worse, actively deceiving readers regarding what happened. These claims
need to be corrected for the record.


10. Further violations of RFC 2418 and RFC 2026

Another RFC 2418 requirement that has been violated here, perhaps the
most fundamental requirement, is the following: "Disputes are possible
at various stages during the IETF process. As much as possible the
process is designed so that compromises can be made, and genuine
consensus achieved; however, there are times when even the most
reasonable and knowledgeable people are unable to agree. To achieve the
goals of openness and fairness, such conflicts must be resolved by a
process of open review and discussion."

This mandated resolution process did not occur here. This isn't just a
question of what happened during the latest "last call": most of the
objections were already raised earlier and still haven't been resolved.

Part of the responsibility of the chairs is to track disputes and
enforce the "must be resolved" rule, so that spec proponents are forced
to build consensus. What the chairs have instead been doing is issuing
one "last call" after another while not acknowledging most of the
objections to these specs.

For rich companies, it's no problem to pay employees to flood the IETF
process with redundant support statements (and the costs are even less
noticeable since the chairs allow one-line support statements). People
acting in the public interest very often can't afford redundant work,
and yet the chairs are demanding that objections be stated and explained
again and again. RFC 2418 does not allow burdens to be shifted in this
way: it requires the WG to resolve objections by a process of open
review and discussion.

The chairs have also been censoring my objections. This chair action
violates the openness component of the "open review and discussion"
requirement in RFC 2418. The chairs claim, falsely, that my messages
are "disruptive". I'm following the RFC 2418 process by raising
objections; the chairs are sabotaging this process by censoring
objections.

The chairs are also violating RFC 2026's record-keeping requirements. As
background, the spec in question is related to (and normatively cites)
the TLS 1.3 spec, which is on the IETF standards track. This makes the
spec "standards-related", bringing the chair discussion of the spec
within RFC 2026's rule that the public record of IETF's
"standards-related activity shall include at least the following: ...
complete and accurate minutes of meetings; ... all written contributions
from participants that pertain to the organization's standards-related
activity". Obviously the chairs had a discussion of whether to issue a
"last call" and of how to handle the results, but the records of those
discussions aren't publicly available. This secrecy makes the appeal
process unnecessarily difficult and violates RFC 2026.


---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.