Imagine a big sports event with two teams in the final game, winner takes all.
The teams play. One team wins. But the referees then hide the scoreboard and replace it with the following announcement: "Sorry, it's not clear what the results were! The teams are going to have to play again."
The teams play again. The same team wins. The referees again hide the scoreboard. The referees again say that there will have to be another game.
Did you really need to see this happen twice before concluding that these are corrupt referees putting their thumbs on the scale to favor the other team?
The latest "last call". On 12 February 2026, the chairs of the IETF TLS working group issued a "second Working Group Last Call" regarding the NSA-driven proposal to publish an RFC on non-hybrid ML-KEM in TLS (sometimes mislabeled "pure ML-KEM"). The chairs wrote that "This working group last call will end on February 27, 2026."
You'd think that, immediately after the end of "last call", the chairs would issue an official statement of the results, filling in the blanks in the following form:
To proceed with publication, IETF rules require a quorum of ___ votes, with at least ___ percent of the votes being positive. All votes are public for transparency.
For this last call, there were ___ positive votes and ___ negative votes. For verification, here are links to all of the votes.
Instead the chairs took all the way until 23 March 2026 to post the following statement: "We are working through issues brought up during the working group last call. We believe addressing these issues is necessary to determine if we have rough consensus to move forward. We expect the author to address the following points: ... We expect resolving these issues will take a few weeks after which we will run a targeted consensus call to see if text changes are acceptable to the working group."
This makes it sound as if the "last call" results merely raised some minor objections that need to be resolved. But, hmmm, why are there no links to what the votes actually said? Could it be that the chairs are wildly understating the level of opposition to this spec?
You'd think that you could click on a link in IETF's official voting system to read the vote results for yourself. But IETF doesn't have an official voting system. IETF pretends that it doesn't vote. IETF tries hard to fool the public into believing that IETF doesn't endorse anything controversial. IETF claims that "IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes". Each IETF WG claims that each of its RFCs "represents the consensus of the IETF community", and prominently inserts this claim into each RFC, even when the claim is a lie.
Going back to the videotape. IETF says that all of a WG's "official work" is carried out on the WG's mailing list. In principle, you can look at the TLS mailing list and see all the votes for yourself.
This type of review is easier said than done. The fiction that IETF doesn't vote leads to endless euphemisms for voting; you have to translate those euphemisms into reality. The votes are expressed as unstructured email messages, normally interspersed with many other email messages. There have been thousands of TLS WG messages since 12 February 2026, including hundreds with "mlkem" in the subject line during the last-call period. The number of people expressing positions for or against this spec was only a small fraction of that.
In this blog post, I'll go through what the votes actually said. By my count, there were 22 negative votes regarding WG publication of this spec as an RFC. Meanwhile there were 21 positive votes. I'll include names and quotes and links for verification. There are a few cases where I'm not sure that the votes I'm counting were from real people (for example, see the "high-frequency trading" quote below in the list of positive votes) but there aren't enough of these cases to matter: it's not as if consensus means a mere majority one way or the other.
For the quotes, I've included enough context not just to see whether the vote was positive or negative, but also to see how few of the objections fit the picture painted by the chairs. My intention here isn't to discuss the arguments and counterarguments regarding the spec (see my previous blog post for a chart of claimed pros and cons); my intention is to compare the unsubstantiated chair summary to the facts.
Some questions to contemplate as you read through this: Why did the chairs delay almost a month before posting a statement regarding the results? Why didn't they post the vote tallies? Why didn't they report what each vote actually said?
The 22 votes against having the WG issue this spec as an RFC. These are listed chronologically.
Stephen Farrell: "I'd prefer this not be published at all for a few years at least. ... Much worse than either of the above would be to add specific text to this document saying we prefer hybrids. But at the very least that has to be done. If that's done soon and there's another WGLC for this document, I'll still oppose publication on the basis of the 1st two reasons above."
Muhammed Usama Sardar: "My concerns are unaddressed: 1. No introduction ... 2. Insufficient motivation ... 3. No additional references added in motivation since WGLC ... 4. Which 'regulatory frameworks require standalone PQ'? Please give authentic references ... 5. 'targeting smaller key sizes or less computation': smaller compared to what? Please give authentic references ... 6. simplicity: in terms of what criteria? Please give authentic references. Unless the above happens, I oppose publication of -07, independent of the mechanisms defined in the draft."
John Mattsson: "I support publication iff all text related to 'key reuse' is removed. In its current form, I do not believe -07 should be published."
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."
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."
Me.
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."
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."
Kurt Roeckx: "I still object, still for the same reason." Previous statement of the reason: "We should only publish it if we think it's actually a good idea, and I've not seen anybody arguing that."
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."
Rob Sayre: "it sort of seems like it's looking for an RFC number and IETF approval more than anything else. ... I don't support this one."
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."
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."
Watson Ladd: "To be clear I oppose publication as I don't think there's rough consensus and I think it's not required to achieve the desired end state in the registry while furthering confusion about what RFCs means and undoing the work this WG tried to do to avoid this confusion. Rough consensus is not an excuse to override serious objections with no explanation."
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."
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."
Ivan Visconti: "I completely agree with David."
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."
Ludovic Perret: "I completely agree with Tanja and am opposed to this draft at this stage."
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."
Andrey Jivsov: "I agree with this summary and conclusion and I oppose the pure ML-DSA draft as written." (Clearly the intention here was to say ML-KEM, although many of the arguments for hybrids apply verbatim to ML-DSA too.)
Christoph Striecks: "+1 on Tibor's thoughts below."
There was also Eric Rescorla, in a spinoff thread regarding another draft, writing "If others agree that this is a good policy, then I think we should enact it with retroactive effect, which is to say: ... Decline to publish draft-ietf-tls-mlkem"—which seems to be saying that declining publication would be good. But the statement relies too much on conditions for me to be sure that this is a negative vote.
Occasional quotes above are from people who evidently would support slightly modified documents (such as John Mattsson writing "I support publication iff all text related to 'key reuse' is removed"); but most of the quotes aren't at all like that, despite what's suggested in the chair summary. Within the 22 negative votes during the last call, about 20 are expressing fundamental objections that can't be addressed by minor tweaks to the spec.
The 21 votes for having the WG issue this spec as an RFC. As before, these are listed chronologically.
David Adrian: "I recommend the document be published as-is."
Russ Housley: "I support the publication of this document as an RFC."
Andrei Popov: "Private sector SW vendors need to comply with government rulemaking, at least if they hope to sell products and services to the government. Also, certain private sector organizations tend to adopt government guidelines for their own operations. I support the publication of this document as an RFC."
Quynh Dang: "I support the adoption of the document, specifically the 3 KEMs in the document as options for TLS." Later: "My apologies. I meant publication, not the adoption."
Anonymous individual described by Paul Wouters: "I was asked by a TLS participant to relay some information publicly regarding their pure PQ mlkem use case. ... There is a use case for MLKEM in the market of high-frequency trading. ... The individual stated they are in favour of adoption the pure mlkem document along with the hybrid document so people can pick either, depending in their use cases."
Sophie Schmieg: "I support publication of this draft, after having written a whole blog post on why the concerns about it are overblown"
Uri Blumenthal: "I am with Sophie here, and support publication of this draft."
Sanketh Menda: "I support the publication of this draft."
Filippo Valsorda: "I support the publication of this draft, both on the technical merits and to end the DoS on the resources of this WG."
Yaroslav Rosomakho: "I support publication of this document. ... Hybrid PQ/T is clearly a transitional mechanism. While we cannot predict the exact duration of that transition, its purpose is to enable safe migration rather than to become a permanent steady-state configuration."
Thom Wiggers: "I support the publication of this draft."
Scott Fluhrer: "I vote to approve this document"
Nick Sullivan: "I support publication of this draft. ... The intended RFC status is Informational, and the IANA actions allocate code points for reference and interoperability/testing, not as a WG recommendation for TLS deployments (Recommended: N)."
Keegan Dasilva Barbosa: "I will reiterate my support for the publication of this draft, since we do plan to include pure ML-KEM within our TLS guidance from the Cyber Centre."
Viktor Dukhovni: "I support publication as a stable reference for the already allocated code point that sports multiple implementations."
Peter Campbell: "I support publication provided that the draft has had at least some review by the FATT."
Mark Penninga: "I support publication of this document. As has been remarked before, the code points have already been allocated so the question is really only whether we want to document them."
Robert Relyea: "I support publication as well, for exactly Vikor's reason. ... I have customers that, despite our recommendations will want to 'pure' ML-KEM."
Jack Grigg: "I support the publication of this draft."
Nico Williams: "I also support publication on the grounds that 'the ship has sailed' and it targeting Informational is 'good enough', and given that I'd rather have a document that received WG, IETF, and IESG review than one that didn't."
Ilari Liusvaara: "I regard the inclusion of ML-KEM-1024 in CNSA2 as a serious endorsement. ... I support publication."
There was also Rich Salz at first casting a positive vote ("There are communities that want pure-PQ, even if this WG thinks it’s not the best thing to do. I support publication") but then withdrawing it (second part of the following quote: "For what it's worth, I have changed my view on the draft and do not object to its publication ... I also do not object to it not being published. Life's too short and I don't give a flying fig about this document any more").
The other comments. There are two reasons that the number of messages on the list regarding this draft was much larger than the number of voters. The main reason is that some voters sent multiple messages, but another reason is that five people commented during the last-call period without clear statements for or against issuing an RFC. Here are the five people:
Ben Schwartz sent three messages asking for evidence justifying the spec's unexplained new claim of "regulatory frameworks that require standalone post-quantum key establishment".
Dan Wing sent a message challenging a more specific claim along those lines.
Peter Gutmann sent three messages questioning the need for post-quantum cryptography, and (like various other people) sent a message challenging the claim that this spec helps for high-frequency trading.
Toerless Eckert sent a message asking for "a BIG BOLD FACE introductory warning" with text such as "THE IETF RECOMMENDS TO USE draft-ietf-tls-ecdhe-mlkem IN ALL CIRCUMSTANCES INSTEAD".
Benjamin Kaduk sent a message saying that new text listing "specific use cases where standalone PQ (i.e., non-hybrid) key exchange is perceived to be useful or is mandated" does not "address the crux of my concern", namely that this spec contradicts "the general guidance in {{HYBRID}} against such algorithms, which appears to put the two documents in conflict". Kaduk described various ways that this conflict might be resolved.
I think that's everybody who spoke up. I'll update this blog post if I missed something.
If you're opposed to this spec, you might think that people saying things like "this spec's supposed rationales collapse upon examination" or "this spec needs a warning saying NEVER USE THIS YOU FOOLS" are also opposed to the spec. But maybe they were just making suggestions and don't have strong enough views to cast a vote. Maybe they think that for some reason the spec should be published despite being a bad idea. I'm not comfortable listing any of these five people as having cast votes.
Anyway, given the 22 clear negative votes, this spec obviously doesn't have consensus, no matter how these five people are treated.
The chair summary. Now that we've looked at the actual content of the votes during the last-call period, let's look again at how the TLS WG chairs described these votes. I already quoted most of this before:
We are working through issues brought up during the working group last call. We believe addressing these issues is necessary to determine if we have rough consensus to move forward. We expect the author to address the following points:
- Key Reuse
- Text for preferring Hybrids
- Whether to include motivations (see Liaison Statement)
We expect resolving these issues will take a few weeks after which we will run a targeted consensus call to see if text changes are acceptable to the working group.
This is obviously not an honest report of the level of opposition that was stated to the spec during this "last call".
To be clear, I'm not saying that changes to the spec won't add any positive votes. For example, changing what the spec says about key reuse will flip John Mattsson's vote from negative to positive, according to what he wrote before. As another example, maybe adding text about preferring hybrids will obtain a positive vote from Benjamin Kaduk.
But there's also a huge pile of negative votes on grounds that clearly won't be affected by these tweaks. Why aren't the chairs admitting this? It's simply not true that "addressing these issues is necessary to determine if we have rough consensus to move forward".
Previous attempts to downplay the level of opposition to this spec. A year ago, the chairs called for "adoption" of this spec. That's a preliminary step before the WG considers potential publication.
The actual votes in response to the adoption call were 20 positive votes, 2 conditionally positive votes, and 7 negative votes. But the chairs didn't post this tally, and didn't acknowledge the level of opposition that had already built up at that point. Instead the chairs declared "consensus to adopt this draft as a working group item".
When I challenged the claim of "consensus", Wouters wrote "There is clearly consensus based on the 67 responses to the adoption call. ... The vast majority was in favour of adoption ... There were a few dissenting opinions". Wouters was an IETF "security area director" at the time. I'm also told that Wouters issued a sarcastic social-media posting saying "it is possible that 30+ TLS participants, 2 Working Group Chairs, 13 IESG members and 13 IAB members are all corrupt and only djb is right". Of course, Wouters didn't provide links to help readers check these supposed tallies of positive and negative votes.
The first "Working Group Last Call" regarding publication was in late 2025. There was again no official vote count from the chairs, but this time there were enough negative votes that the chairs weren't willing to claim consensus (or "rough consensus"). The chairs stalled for weeks after that "last call" ended and then posted the following:
The working group last call for pure ML-KEM has concluded, thanks to those that participated in the discussion. In summary, we do not have consensus to publish the document as is.
Okay: clear admission that this "last call" failed to reach consensus on publishing this spec. But the chairs continued:
The largest number of participants wanted to publish the document as is, however there was also a significant number that wanted changes to the document before publication and a small, but vocal, number of participants that do not want the document to be published at all.
Where are the numbers, names, and quotes backing up these claims about "largest" and "significant" and "small"?
There were several issues raised, but the main area of contention was around having a statement on the security and applicability of this mechanism versus the hybrid key mechanisms.
The chairs issued this "main area of contention" claim without providing any evidence. They then used this unsubstantiated claim to set up a second "last call":
Given this, the chairs will move the document back to the "WG Document" state and ask the author to work on resolving the issues brought up on the list including text to address concerns that there are reasons to prefer hybrid over the pure approach. The chairs will then redo a working group last call to see if there is rough consensus for publishing this document.
If a PQ-without-seatbelts spec fails to explain why seatbelts should be removed, and people are complaining about this lack of explanation, then maybe those people could be satisfied by an explanation. If, on the other hand, the core complaint is instead that removing seatbelts is frivolously incurring unnecessary security risks, then what's the excuse for a second "last call"?
The chairs issued a second "last call". More and more negative votes started piling up. Wouters then posted a message claiming that the spec had already reached consensus: "We already had a WGLC on this document [1] and the conclusion [2] was that it passed WGLC provided some clarifying text would be added that stated that for the general use case, hybrids were preferred. This 2nd WGLC is about that topic. ... the consensus call passed ... This 2nd WGLC is meant to get those people who provisionally said 'yes' to publication of this document pending some extra text, to review this text and let us know if that resolves the conditional part of their 'yes' statement."
David Adrian followed up to claim that objections to publishing the spec were inappropriate and should be ignored: "The chairs should exclude from their consensus determination mail from people who are not limiting their comments to clarifying text and are instead relitigating the same previously discussed arguments. There is no reason to believe the same people going off topic now, will not simply go off topic on yet another WGLC."
Also Uri Blumenthal: "WGLC has happened already. Enough is enough. The fact that some people being more loud than others, shouldn't impact the outcome."
Did these false claims about what had happened—about the supposed inappropriateness of objecting to the publication of this spec—deter some people from objecting? Was this the objective of issuing the claims?
Stephen Farrell, Nadim Kobeissi, and John Mattsson promptly challenged what Wouters had written. There were no admissions of error from Wouters (or from Adrian or from Blumenthal). Today Wouters is no longer "security area director"; does this remove his obligation to correct the misinformation that he issued as "security area director"?
After the March 2026 declaration from the chairs that "addressing these issues is necessary to determine if we have rough consensus" and that "we will run a targeted consensus call to see if text changes are acceptable to the working group", Wouters claimed based on unspecified "analyses" that "the group of 'yes with updated text' would be rough consensus".
After a commentator replied "I think the trend is that more and more people are showing reservations on the draft, rather than the other way around", Wouters claimed that those were "drummed up people. not people with skin in the game".
A dictionary says that having "skin in the game" means that you're "directly involved in something and will be affected by how it turns out". Billions of people rely on TLS to protect their communications against attack; do they not have "skin in the game"? Do their interests in security not matter? Sometimes "skin in the game" is used to refer specifically to financial interests; does this not include protecting against identity theft and ransomware? Do TLS users not have the right to speak up in the IETF TLS working group? Are their votes ignored when IETF management makes claims of "consensus"? What happened to IETF's claim that "Anyone can participate by signing up to a working group mailing list"?
Next steps. For the third "last call", presumably we'll see even more efforts to suppress negative votes. In particular, it sounds like the chairs won't ask whether there are objections to publication, but instead will issue a narrower "last call" for objections to some specific wording.
The chairs have claimed that people who don't speak up will be counted as having their previously stated position: "If you did not recommend changes, then your position will remain the same, unless you state that you are reconsidering." Um, how are we supposed to believe that negative votes will still be counted when they weren't counted in the first place?
The chairs have never admitted the extent of opposition that was stated already. If they did admit it then they would have no excuse for issuing a third "last call". But maybe some people will believe the chairs saying that the negative votes already cast will still be counted. Maybe those people will stay silent as a result—which will make it easier for the chairs to act as if those votes never happened.
Meanwhile there's clearly a big push to bring in new people to vote for the spec. One of those people spoke up in late March 2026 to say that he wants to "share" information about the "discussion with others in the vendor community" and to say that this discussion is "not an effort to 'ballot-stuff,' but a genuine attempt to" raise awareness of something.
Oh, okay, if they say it's not ballot-stuffing then I guess it's not ballot-stuffing! It's merely NSA's anti-hybrid "interactions with vendors" naturally producing "skin in the game"! New people showing up to vote against the document were "drummed up" and should be discounted, but new people showing up to vote for the document should be counted!
The actual question on the table is whether to publish this spec as an RFC. Every interested party has a right to speak up regarding this question. It's not a good look for the people in charge to be discarding votes and trying to intimidate opponents into silence.