Remember how IETF claims that its decision-making "requires achieving broad consensus"? And claims that "anyone can participate" in IETF by simply "signing up to a working group mailing list", the list that carries out all "official work" of the working group? Also, remember how IETF/IRTF chairs claim to be "little more than group secretaries"?
In reality, IETF chairs decide when to call votes, what to call votes on, and whether they can get away with declaring that the vote results qualify as "consensus". If a controversial document that they're pushing receives an overwhelming number of objections, they can simply wait and try again, issuing another "last call" for objections. Dissenters are forced to again and again spell out their objections in detail. Proponents who think they have majority support—not from the majority of the public; rather from the majority of those who can afford to keep showing up to IETF—tend to issue only cursory explanations, sometimes simply casting "+1" votes with no explanation at all.
This brings me to current events: Joseph Salowey, one of the chairs of the IETF TLS working group, has issued another "last call" for objections to non-hybrid ML-KEM in TLS. The call was issued last week (12 February 2026), with a deadline next week (27 February 2026). In this blog post I'll look at what's going on.
Recap of last season. The following paragraphs are for readers catching up. For my regular readers, just skip ahead to the new part.
General context first: NSA has "signals intelligence as its primary mission". In support of this mass-surveillance mission, NSA has again and again sabotaged cryptographic standards.
There are many historical examples of overt surveillance triggering a backlash, so NSA has a cover story of improving security. This cover was blown to smithereens in 2013. Internal NSA documents showed NSA's quarter-billion-dollar-a-year budget for a project that "actively engages the US and foreign IT industries to covertly influence and/or overtly leverage their commercial products' designs. These design changes make the systems in question exploitable ... To the consumer and other adversaries, however, the systems' security remains intact." This project includes activities to "influence policies, standards and specification for commercial public key technologies" and to "shape the worldwide commercial cryptography marketplace to make it more tractable to advanced cryptanalytic capabilities being developed by NSA/CSS". (Emphasis added.)
Even before 2013, NSA's cover story was not plausible for people paying attention to public information about NSA. But paying attention takes time, and most people are busy with other things. Even after 2013, NSA continued investing in its marketing department, and gullible people continued believing that this department is an independent pro-security organization rather than NSA's primary conduit for sabotage.
Now the specific context: Post-quantum cryptography is risky. Designers of PQ proposals say that they're trying to protect against quantum computers, but half of the proposals for PQ standardization have already been publicly shown to flunk their security goals even in a world without quantum computers. Presumably NSA knows how to break even more PQ proposals than the public does.
The common-sense response to the PQ dangers is the popular approach of rolling out PQ as an extra security layer beyond traditional ECC, rather than replacing ECC with PQ. In the TLS context, shared secrets are obtained by hashing multiple inputs together in any case, and ECC+PQ simply keeps an ECC session key as one of those inputs while including a PQ session key as another input. Continuing to use ECC is like wearing your seatbelt: if the car crashes then the seatbelt reduces the chance that the crash will kill you.
Unsurprisingly, NSA and its spying partners have posted various arguments against hybrids. These arguments collapse upon examination. For example, there are complexity arguments that range from inapplicable to backwards; there are cost arguments that rely on not quantifying the costs; and the possibility of a PQ security failure is described as a "cryptanalytic breakthrough" with no admission that we've seen many PQ security failures already.
In 2024, one of the IETF TLS WG chairs posted a document specifying non-hybrid ML-KEM as an option for TLS. The document's stated rationale was short and circular: "Having a fully post-quantum (not hybrid) FIPS-compliant key agreement option for TLS 1.3 is necessary for eventual movement beyond hybrids and for users that need to be fully post-quantum sooner than later."
When someone asked for actual motivation, the document author responded with another circular argument and then an unsupported claim that hybrids were "a big 'maybe' at best" for "FIPS / CNSA 2.0 compliance". In fact, NIST SP 800-227 explicitly approves a "key combiner" where "at least one shared secret" is approved (i.e., NIST's approval of PQ implies NIST approval for ECC+PQ); even before NIST SP 800-227, NIST had never said that hybrids would be prohibited; NSA has a series of official CNSA 2.0 documents saying "hybrid solutions may be allowed or required due to protocol standards"; and another official NSA document describes an NSA program that asks for two independent encryption layers "to mitigate the ability of an adversary to exploit a single cryptographic implementation".
To be clear, there's ample evidence of NSA pressuring military contractors to support non-hybrids. For example, a Cisco employee wrote "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"; and an NSA employee wrote "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".
On the other hand, NSA doesn't seem to want the public-relations problem of issuing official compliance regulations demanding that vendors abandon seatbelts. I'm reminded of the backlash many years ago after NSA employee Joseph A. Meyer claimed that cryptographers such as Hellman were violating government regulations; the claims weren't official NSA statements, and NSA responded to the backlash by denying that it had "directed any employee to bring pressure on Mr. Hellman or the others".
In April 2025, the TLS WG chairs called for WG "adoption" of the non-hybrid document. "Adoption" is a preliminary step before an IETF WG deliberates upon and potentially publishes a document.
In response, seven people, including me, raised a variety of objections. The most important objection is that using non-hybrid PQ instead of ECC+PQ creates unnecessary security risks.
As a concrete example of the risks, after Google and Cloudflare had used CECPQ2b to encrypt tens of millions of real user connections, the SIKE component of CECPQ2b was publicly ripped to shreds. The only reason that the weakness of SIKE didn't immediately expose the CECPQ2b-encrypted user data to attackers is that CECPQ2b was a hybrid: CECPQ2b encrypted data with SIKE and with ECC.
Back to the adoption call. More people voted in favor of the document: there were 20 supporters and 2 conditional supporters. That's a majority of the people who cast votes. This is, however, far below 51% of the TLS working group, and it definitely didn't achieve consensus, never mind the legal requirements that standards organizations have to follow.
The chairs nevertheless abused their power to declare "consensus" on adopting the document (and my objections to this consensus call were met with a series of runarounds). On 5 November 2025, the chairs issued "last call" for objections to publishing the document, with a deadline of 26 November 2025.
Part 1 of this series of blog posts was already in October 2025. The next three parts were during "last call" in November 2025. Part 2 highlighted the corruption. Part 3 focused on the way that an IETF "security area director" named Paul Wouters has been dodging every important topic at hand, most importantly security. Part 4 gave an example of how dissent on this topic has been censored, despite IETF's claims of openness. The chairs did eventually allow that specific censored message through, but only after I blogged about it.
That's it for the recap! Now for the main new events in part 5.
2026: One falsehood after another. Readers on 12 February 2026 seeing a "last call" for objections to this non-hybrid document are being told that the previous objections were resolved. But the previous objections weren't resolved. How is the reader supposed to realize that there were already objections on security grounds to non-hybrids, along with objections to each of the arguments for non-hybrids?
The call wording further misdirects readers as follows: "The main focus of this WGLC is to review new text providing more context around the use of pure ML-KEM. For those who indicated they wanted this text, please let us know if the new text satisfies you and if you support publication." There's no acknowledgment of, and no request for input regarding, the actual controversy. Readers are led to believe that there was merely a disagreement about the level of detail provided in the text. (Also, readers who have been watching the discussion and who already filed objections might not realize that if they don't repeat the objections then the chairs will ignore the objections.)
The chairs should be explicitly recognizing the controversy and actively soliciting broader participation to ensure that IETF meets its promise of "achieving broad consensus". Instead the chairs are concealing the controversy.
About 15 hours before the "last call" was issued, a new version of the document replaced the circular motivation sentence with a new sentence: "Use cases include regulatory frameworks that require standalone post-quantum key establishment, constrained environments where smaller key sizes or less computation are needed, and deployments where legacy middleboxes reject larger hybrid key shares." The document didn't provide any citations to justify these claims of virtues of non-hybrids, and certainly didn't discuss the objections that had already been raised to these claims:
"Regulatory frameworks that require standalone post-quantum key establishment": The original claim that hybrids were "a big 'maybe' at best" for "FIPS / CNSA 2.0 compliance" was disputed on list and not defended, so how can the new document be making this claim again? Actually, the rewritten claim sounds even stronger, since it says "require" without a "maybe".
"Constrained environments where smaller key sizes or less computation are needed": How exactly is someone sending 800+768 bytes for a key+ciphertext for ML-KEM-512 going to care about 32+32 extra bytes (4% extra) for X25519? More broadly, the costs of computation and communication for X25519 are negligible next to the ML-KEM communication costs. This has been pointed out quite a few times before, both on and off the TLS mailing list; I'll say more about this below. The non-hybrid document isn't looking at details of a specific platform and trying to engineer something that fits into the platform; it's pointing vaguely in the direction of unspecified constrained environments as a talisman to support a proposal for reducing cost, without regard to whether the cost difference actually matters.
"Deployments where legacy middleboxes reject larger hybrid key shares": This is a wild exaggeration of a claim that was made on the mailing list in November. The claim was that "ML-KEM-512 is the only adopted quantum-resistant algorithm that can be used to bypass legacy middle boxes"; this was a claim about 800 bytes for ML-KEM-512 vs. 1088 bytes for ML-KEM-768, not a claim that adding 32 bytes for X25519 would matter. Furthermore, I challenged the supposed evidence for the claim; there was no response to my objections.
Half an hour before "last call", there was yet another version of the document and in particular of its motivation sentence: "Use cases include regulatory frameworks that require standalone post-quantum key establishment, targeting smaller key sizes or less computation, and simplicity." So there's no longer the claim about middleboxes, and no longer a claim about a "need" for smaller key sizes in "constrained environments". Those claims have been replaced by generic pursuit of efficiency, but that's outside the scope of the TLS working group.
As for the claim of "simplicity", there's no response here to the objection that was already raised by Andrey Jivsov, namely that TLS already has ECC+PQ so having another PQ option makes TLS more complicated. The document does not remove ECC+PQ from TLS.
Hey, here's an idea for actually improving the efficiency and simplicity of TLS: mandate that every connection encrypt user data solely with the null cipher! Yes, this sounds absurd; that's because efficiency and simplicity by themselves are not the TLS objective. We pursue some forms of efficiency and simplicity for TLS to help security. The non-hybrid document complicates TLS, allows only minor efficiency improvements that will do nothing to expand TLS deployment, and incurs completely unnecessary risks of security disasters.
Continuing controversy. When I blogged about the previous "last call" in November, I named eight individuals who were speaking up in favor of the document (even if sometimes the support came with conditions). I'll repeat those names here:
Rebecca Guthrie, an employee of NSA.
Florence Driscoll, an employee of NSA's spying partner GCHQ.
Keegan Dasilva Barbosa, an employee of another NSA spying partner, Communications Security Establishment Canada.
Quynh Dang, an employee of NIST. (Dang wrote "I am not a representative of NIST or any other organization in this message.")
Uri Blumenthal, an employee of "MIT Lincoln Laboratory", which despite its name is a subsidiary of the U.S. military.
David Adrian, an employee of a company receiving massive U.S. military funding, namely Google. (Adrian later issued the following non-response: "Despite public accusations [2], I do not actually work for an intelligence agency." Here "[2]" linked to my earlier blog post on corruption. That blog post, exactly like this one, correctly describes Adrian as "an employee of a company receiving massive U.S. military funding, namely Google".)
John Mattsson, an employee of U.S. military contractor Ericsson.
Russ Housley, originally Air Force, now president of a small consulting firm called Akayla that has received $210000 in military contracts since 2023.
By the time the last-call period ended, there were several more commentators who sounded supportive of the document (sometimes explicitly conditioned on the document saying "RECOMMENDED=N"; I think most purchasing managers care only whether something is an RFC and will never even see the "RECOMMENDED=N" detail). But there were unequivocal objections from at least eight people (including me), as the following links show:
Thomas Bellebaum: "I strongly oppose publication of this document as is."
Daniel J. Bernstein: "This document doesn't serve any of the official goals in the TLS WG charter. Most importantly, this document is directly contrary to the 'improve security' goal, so it would violate the charter even if it contributed to another goal."
Stephen Farrell: "I'd prefer this not be published at all for a few years at least."
Simon Josefsson: "At this time, I believe that non-hybrid PQ KEMs are a security risk."
Benjamin Kaduk: "I do not support publication of this document at this time; see the 'discuss' points for specific items that IMO should be blocking."
Watson Ladd: "I think there is no real reason to publish this document, and publishing sends the wrong signal about hybrid vs not. We should not publish it."
Kurt Roeckx: "I'm also opposing this. There is no reason for this workgroup to get involved. We should only publish it if we think it's actually a good idea, and I've not seen anybody arguing that."
Muhammad Usama Sardar: "I do not support publication in its current state ... Introduction and motivation is too small: literally two sentences. That's clearly insufficient. Sure, I'm not a PQ expert but an I-D is not for experts only, isn't it? If compliance is the motivation, it should be added in the introduction/motivation with at least one pointer to authentic reference of concrete regulation."
Does this sound like a document that has consensus?
After taking weeks to think about this, the chairs finally admitted that "we do not have consensus to publish the document as is". But they laid the groundwork for another "last call", starting by misrepresenting the contents of the objections: "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". The claims from the chairs about what's "significant" vs. what's "small" weren't backed by tallies and names and links for verification.
What would you do as an attacker trying to ram this controversial non-hybrid document through the IETF process? You'd do whatever you can to reduce the visibility of the common-sense public-interest position of requiring hybrids. Maybe you can use side issues as a distraction. Maybe you can peel off some of the opponents by offering them something in exchange (support for one of their documents? contracts for their employer? a trip to Hawaii?). Maybe you can silence some of them with peer-pressure games, such as claiming that they're a "small, but vocal" minority. Maybe you can simply wear them down with the burden of having to raise their objections again and again and again.
Meanwhile you'd work behind the scenes to have more people show up and cast positive votes in the next "last call", probably delaying quite a few votes until the end of the "last call" period so that there wouldn't be a chance for opponents to react. Remember that the IETF TLS chairs did declare "consensus" to adopt this document when there were 20 supporters, 2 conditional supporters, and 7 opponents. The first "last call" on publication had fewer supporters and more opponents, but the gap doesn't seem insurmountable, does it? Just a temporary setback.
As noted above, the chairs issued their new "last call" on 12 February 2026. There have been reiterated statements of support from, e.g., David Adrian, Quynh Dang, Russ Housley, and (again conditionally) John Mattsson. There has been at least one statement of support from someone who didn't speak up in the previous "last call": Andrei Popov, an employee of another big U.S. military contractor, namely Microsoft. Meanwhile there have already been objections from, e.g., Stephen Farrell, Simon Josefsson, and Muhammad Usama Sardar.
Beyond serving as cover for a new "last call", did the changes to the document affect the debate? Sort of. Instead of the supposed benefits for "FIPS / CNSA 2.0 compliance" being a disputed claim outside the document, suddenly the document itself has a claim of "regulatory frameworks that require standalone post-quantum key establishment", as noted above. This claim is, as far as I can tell, pure fiction, but fictions can still influence decision-making processes.
Ben Schwartz from Meta (who hadn't commented before, and who doesn't seem to have taken a position for or against the document) asked whether there were actually any "regulatory frameworks that require standalone post-quantum key establishment". In response, Popov pointed to a document authored by an NSA employee; but this isn't even an official NSA document, let alone a regulation.
Popov then pointed to a document from NSA's Canadian spying partners as supposedly being "another regulatory reference". This one is at least an official document, but I don't see where it supposedly prohibits hybrids or, more broadly, how it's supposed to be a regulation. It merely states "recommended cryptographic algorithms".
To be clear, NSA does have official control over the cryptographic part of U.S. military purchasing. What happens if NSA someday does issue an official regulation prohibiting hybrids in this context? Answer: IETF can and should require hybrids. The official charter for IETF's Transport Layer Security working group states "improve security" as a goal. IETF says that "The IETF Will Work to Mitigate Pervasive Monitoring". IETF also says that "IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best solution for any particular network, technology, vendor, or user". IETF should not be following orders from NSA.
The negligible cost of keeping ECC. Do the people pushing non-hybrids think they're helping their case when they say things like "smaller key sizes"? It's too easy for observers to look up the sizes: 800 bytes for ML-KEM-512 keys, 1184 bytes for ML-KEM-768 keys, 1568 bytes for ML-KEM-1024 keys. It's not plausible that the application will have a problem adding 32 bytes for an X25519 key.
Saying "less computation" is more effective as a marketing strategy. People who look up the cycle counts for, e.g., ML-KEM-768 on an AMD Zen 2 CPU core will see, wow, only 44+43+45 kcycles for keygen+enc+dec, where the results for lib25519 on the same core are larger, 26+74 kcycles on each side.
However, anyone serious about engineering will ask whether this computational cost is important compared to the kilobyte of ML-KEM network traffic, and, more to point, whether this cost matters in the context of the application.
Readily available Dell servers—certainly not the state of the art in high-performance computing, but easy to install and use—were already carrying out 251 cycles of computation per dollar years ago. At the same time Xfinity was charging $75/month for a 1Gbps wired Internet plan allowing 1.2 terabytes/month. Filling up this 1.2-terabyte data cap would allow transmission of 229 ML-KEM-768 keys and 229 ML-KEM-768 ciphertexts in a month. Adding 100 kcycles of X25519 computation times 229 connections would consume just $0.02 in computation, a very small fraction of $75.
There are scenarios with lower networking costs per byte, such as back-end TLS connections inside a data center, but how is it supposed to be plausible that a TLS application using ML-KEM for key exchange won't be able to afford X25519+ML-KEM?
Bas Westerbaan reported in 2024 that Cloudflare was handling 251 HTTP requests per year, plus "many more TLS connections" beyond browser connections; he guessed that in total there are "more than 258 TLS connections established worldwide per year". Cloudflare reportedly handles 20% of web sites, so let's figure that there are 253 TLS requests from browsers per year out of 258 TLS connections in total. Let's now try tilting the costs in favor of ML-KEM by adding ML-KEM-768 traffic to just half of the 253 HTTP requests and counting only one side of the networking costs for that, while considering the computational costs of X25519 for all 258 TLS connections:
252 ML-KEM-768 keys and 252 ML-KEM-768 ciphertexts add 263 bytes of communication exchanged with end users. That's 223 times the 1.2-terabyte data cap mentioned above for a $75/month connection, so about 229 dollars worldwide.
258 X25519 computations cost about 265 kcycles server-side, so about 224 dollars. Let's double this to account for the client-side costs: 225 dollars worldwide.
This massive tilting still doesn't push the X25519 cost above a small fraction of the ML-KEM cost, never mind the bigger picture of total TLS costs and total application costs. Cloudflare's revenue in 2025 was $2 billion. Google's revenue in 2025 was $400 billion.
The basic lesson here is that ECC is an easily affordable security tool. It's already in place. Throwing it away as part of a PQ switch would frivolously incur unnecessary security risks, compared to the normal approach of upgrading to ECC+PQ. So how exactly is the anti-ECC narrative supposed to work?
Constrained devices. Remember the talisman! We can make the ECC computation sound more problematic by claiming that the computational costs of ECC are a problem for unspecified "constrained environments", that the code size of ECC is a problem for unspecified "constrained implementations", etc.
Vague claims of this type have triggered questions on the TLS list about the actual costs of cryptography on small devices. So here are two specific cost comparisons of hybrid ECC+PQ and non-hybrid PQ. I'll focus on the usual options for TLS: X25519 for ECC plus ML-KEM-768 for PQ. (As a side note, this also matches the ML-KEM size recommended by NIST. Moving down to ML-KEM-512 would be particularly scary given the neverending drumbeat of improvements in attacks against lattice problems, as illustrated by attack papers in October 2025 and February 2026.)
One question was about "a scenario involving a 16-bit CPU operating at a 100 MHz clock speed and with a 5 kBps network connection".
A tiny 16-bit MSP430X takes just 8 million cycles for an X25519 computation, and therefore just 16 million cycles in total for ECC keygen+encryption (with a trivial reuse of ECDH for keygen rather than putting more work into speeding up keygen), i.e., 0.16 seconds at 100 MHz. The 32+32 bytes of traffic add at most 0.0128 seconds.
My experience is that small devices consistently allow computation to be overlapped with communication, so a device busy with a series of X25519 and ML-KEM-768 computations will overlap each X25519 computation with the 0.2368 seconds for receiving an ML-KEM-768 key (1184 bytes), whether or not the radio hardware allows that communication to be overlapped with the 0.2176 seconds for sending an ML-KEM-768 ciphertext (1088 bytes). A full investigation would require studying the cost of ML-KEM computation and (more importantly) TLS on this CPU, but in the end I would expect the bottleneck to be communication. The only slowdown from X25519 is then from the extra 32 bytes of ciphertext (0.0066 seconds) and the extra 32 bytes of key (0.0066 seconds), making ECC+PQ just 3% slower than non-seatbelt PQ. There would be even less effect on the total cost of a connection: various other TLS costs, such as the symmetric cryptosystems used to encrypt and authenticate user data, are independent of whether a key is exchanged with ECC+PQ or with PQ. The X25519 costs will be even less noticeable on a device that isn't busy.
The other question was about "how much code size we are talking about" including "usage of flash memory" (the code per se) and "usage of RAM" (stack): how much TLS code size would in fact be saved in a hypothetical scenario of ECC+PQ disappearing in favor of PQ. I should emphasize that this gets the simplicity comparison backwards since TLS has ECC+PQ anyway—again, the draft in question does not remove ECC+PQ from TLS—but I also think it's important to look at the numbers to combat persistent misinformation about the relative complexity of PQ and ECC.
The literature reports exact code-size numbers for ML-KEM-768 and X25519 if one upgrades from a 16-bit MSP430X to a more powerful 32-bit Cortex-M4 (which also avoids the question of whether any deployments are actually managing to squeeze TLS into an MSP430X):
ML-KEM-768 on Cortex-M4 takes 5120 code bytes, 10248/13384/14480 stack bytes for keygen/enc/dec, and 989/1138/1388 kcycles with the "clean" implementation; or 13320 code bytes, 2820/2860/2844 stack bytes, and 644/665/714 kcycles with the "m4fstack" implementation. (There's also an "m4fspeed" implementation that doesn't provide competitive tradeoffs.) Overall that's over 15000 bytes of code+stack with either implementation.
X25519 on Cortex-M4 takes 1472 code bytes, 348 stack bytes, and 441 kcycles. Normally these kcycles won't be noticeable next to the time for other operations (such as communicating PQ ciphertexts and other data), so it'll be better to use another option from the same source, namely 1132 code bytes and 348 stack bytes for 521 kcycles. Overall that's just 1480 bytes of code+stack.
Flash and RAM have different costs and are often supplied in different amounts, but, no matter what the flash-RAM balance is, the sizes for X25519 are far smaller than the sizes for ML-KEM. Even without looking at other costs for TLS, one can see from these numbers how implausible it is that a device would be able to use TLS with ML-KEM without also being able to afford X25519.