Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES. NSA used export-law exceptions in the 1990s to entrench RC4 and RSA-512, causing security problems for decades. NSA in the 2000s sabotaged RNG standards and paid companies to deploy those. NSA by the 2010s had a quarter-billion-dollar-a-year budget to "covertly influence and/or overtly leverage" standards and other systems to make them "exploitable" while "the consumer and other adversaries" think that "the systems' security remains intact".
The current vote in the IETF TLS WG, labeled in IETF doublespeak as a "last call", is regarding an overtly NSA-driven push for an IETF RFC on solo ML-KEM in TLS. Issuing an RFC means issuing IETF endorsement of solo ML-KEM in TLS. Presumably the next step after RFCs on solo ML-KEM and solo ML-DSA in TLS is that NSA will keep spending money to encourage broader deployment of solo ML-KEM and solo ML-DSA. This will be an inexcusable security disaster because of the predictable influx of ML-KEM software bugs and ML-DSA software bugs, never mind the risk of security flaws in the specifications.
IETF rules say that participation is "open to all". This vote on solo ML-KEM says it "ends 2026-07-08". I don't know whether this means that on the 8th you'll still be able to file your vote, nor do I know which time zone they're talking about, but clearly the end is nigh.
IETF also says that all "official work" of a WG is carried out on the WG's mailing list. For this particular vote, opposition messages have appeared on the mailing list from more and more people (60 so far). Proponents are trying every argument they can think of to stop that number from growing—to make you hesitate to speak up. For example:
On 1 July 2026, "Michael P" from "ncsc.gov.uk" (i.e., from NSA's UK partner GCHQ) wrote that "speculative claims of insecurity" have "the potential to discourage migration to ML-KEM". Maybe you look at this and think, wow, that sounds worrisome; if we insist on ECC+ML-KEM then we might be slowing down an important migration!
But wait a minute. The situation last September was that ML-KEM had already grown to half of Cloudflare's HTTPS connections—and that's ECC+PQ, not solo PQ. (Specifically, "about 95% X25519MLKEM768 and 5% X25519Kyber768Draft00"; both of those are ECC+PQ, not solo PQ.) For people worried about ML-KEM security, migrating to solo ML-KEM sounds stupid, but migrating to ECC+ML-KEM sounds reasonable, so how would pointing out security concerns slow down migration?
On 3 July 2026, Paul Hoffman wrote as the rationale for his positive vote that "the credible cryptographic community supports both" ECC+ML-KEM and solo ML-KEM. Maybe you look at this and think, wow, if the cryptographic community thinks solo ML-KEM is just fine then it must be just fine!
Wait a minute. Orr Dunkelman, famous for developing the best attacks known against AES and many other well-known cryptosystems, filed an objection to solo ML-KEM during this "last call"; cryptlib author Peter Gutmann filed an objection to solo ML-KEM during this "last call"; Fabiana Da Pieve, European Commission Team Leader Post-Quantum Cryptography, filed an objection to solo ML-KEM during this "last call"; etc. Is Hoffman—who somehow neglects to mention his earlier role in an NSA push for TLS extensions that made Dual EC easier to exploit, and who doesn't disclose how much money he received from NSA—claiming that these people aren't "credible"? Wow.
On 5 July 2026, regarding the Canadian Centre for Cyber Security (part of NSA's Canadian partner CSE), Kevin Milner wrote that "whether there is an RFC for pure ML-KEM almost certainly has no bearing on their recommendations"; that was in response to an opponent explaining how an RFC would turn into "policy affecting millions of systems and people". Maybe you look at this and think, wow, opponents are exaggerating the damage that will be done by an RFC!
In fact, the stated rationale for the positive vote from CSE's Keegan Dasilva Barbosa was that "we do plan to include pure ML-KEM within our TLS guidance from the Cyber Centre". When an opponent commented that CSE "wrote on list they are relying on this document to be published so they can recommend solo ML-KEM", CSE's Jonathan Hammell responded "Yes" as part of casting his own positive vote. [20260706 edit: corrected copy-and-paste error in this paragraph.]
I've done quite a few updates of my chart of arguments and counterarguments, most recently on 25 June 2026. Proponents keep making flawed arguments, ignoring every important objection, and ignoring an IETF rule saying that disagreements "must be resolved by a process of open review and discussion". Proponents seem to understand that solo PQ can't survive the mandated consensus-building process, so they've replaced that with a political voting process, and they're blatantly packing the vote. For example, we've seen positive votes from
etc. [20260706 edit: added Lear.]
But maybe you've heard proponents claiming that, no, it's the other way around: that opponents are making flawed arguments, ignoring every important objection to those, and packing the vote.
Maybe you end up unsure which side is right in evaluating the merits of the spec. Is it reasonable to risk incorrectly casting a vote against this spec? Is it reasonable to risk incorrectly casting a vote for this spec? If you're not sure, isn't it better to stay silent?
Well, no, because risk analysis includes looking not just at what can go wrong and at how likely it is to go wrong but also at the consequences. The consequences in this case are radically different, in part because of a basic pro-endorsement bias that's built into IETF's procedures and in part because the impact of one type of error is vastly less severe than the impact of the other type. Let me explain.
There's no IETF rule limiting the number of "last calls" that a document can go through. This particular document has already had three "last calls": one in November 2025, one in February 2026, and the current one starting in June 2026.
If after a "last call" the WG chairs declare "rough consensus" on issuing an RFC, that's it. The WG is done with the document. The document is rubber-stamped by a small committee called IESG and then published as an RFC claiming "consensus of the IETF community", without the word "rough" and without any acknowledgment of dissent.
IESG goes through the motions of asking for community input, but even if the input is overwhelmingly negative there are no rules forcing IESG to reject the document. The majority of IESG consists of defense contractors (plus one NSA lifer, Deb Cooley), so it's not as if IESG is going to reject an NSA-driven document. Technically, there are various types of appeals possible, but those are handled by IESG and a similarly biased committee called IAB, not by a neutral tribunal.
If, on the other hand, the WG chairs don't declare "rough consensus" on issuing an RFC, then there's nothing in the rules stopping them from trying again. That's why we're already on the third "last call" for ietf-tls-mlkem.
See how unfair this is? See how it's biased towards the companies that want to push a draft forward and that can afford to flood IETF with participants?
IETF says the following rule is "fundamental": "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." It also says that disagreements "must be resolved by a process of open review and discussion", as I noted above. Obviously that isn't at all what's happening here. Instead of seeing people working together to engineer the best solution for the whole Internet, you're seeing a voting process with disagreements that still haven't been resolved. That's a familiar situation in politics but it's not how IETF is supposed to work.
With this in mind, let's think again about the risks when you're not sure which vote is right:
If you cast a vote against the spec, you're asking proponents to come to the negotiating table. If more discussion then convinces you to support the spec, the only damage done was a delay in issuing this spec as an RFC—an RFC that proponents keep saying they don't recommend using anyway, so they can't claim that a delay is damaging! For example, proponent Sophie Schmieg claims that this solo ML-KEM spec will be used only by NSA, "not impacting anyone else".
If you instead stay silent because you're not sure which vote is right, or if you cast a vote for the spec, then you're letting the proponents get away with non-consensually ramming a controversial document right now through the WG. If they're simply wrong in claiming that the spec is safe—and if NSA then succeeds in using the RFC to encourage widespread deployment—then the damage done is sabotaging security for millions of users.
If you click on statements from proponents and opponents then you again and again see this giant difference in impact. Opponents are typically talking about the damage that PQ screwups do to security for the general public. Meanwhile a typical proponent rationale says that it will be convenient to simplify ECC+PQ down to solo PQ "if and when quantum computers start really doing their thing and people lose their attachment to quantum-vulnerable cryptography"; um, ok, how exactly does this make it problematic to delay this document?
The most extreme-sounding statement from a proponent is a claim that having to deal with ECC+ML-KEM would "consume literal years of my life". Surely this "years" claim isn't meant to be taken seriously—surely he doesn't mean to declare that he's grossly incompetent at his job—but the bigger picture is that security people do invest effort in trying to protect many more people; that's the whole point.
Isn't it obvious how important the public interest is in avoiding security failures? Shouldn't this interest be fairly represented in IETF?
Let me go back to the procedural point about the pro-endorsement bias built into IETF procedures. It's easy to check that, yes, this really is the third "last call" for ietf-tls-mlkem. Look at the "last call": it claims that "significant developments" had addressed "the concerns raised in the last WGLC", and on this basis it concludes that a "third consensus call is warranted".
I went through my list of the 22 people who had filed objections during the previous "last call" for ietf-tls-mlkem:
The developments listed by the chairs addressed objections from only three of the people, namely #1, #2, and #3. Those three people have spoken up to say they're now neutral, neutral, and supporting respectively.
Meanwhile 15 of the 22 objections were explicitly regarding the security risks of ietf-tls-mlkem compared to ietf-tls-ecdhe-mlkem: #4, #5, #6 (me), #7, #8, #10, #12, #13, #15, #16, #17, #18, #19, #20, and #22. The chairs were flatly lying in claiming that these concerns were addressed.
Eight of us (and many more people) are already on record objecting again in this "last call". The real function of the third "last call" is to impose redundant work—which doesn't matter for companies such as Cisco that can afford to send 100 people to every IETF meeting, but matters much more for those of us representing the public interest.
The same message from the chairs claimed that if there isn't "rough consensus" then "we will stop discussing the draft and not progress it". This claim is a marketing trick, not something that can be enforced against the chairs or other document proponents under IETF rules.
I noted in my previous blog post that the chairs had promised in February 2025 to call for TLS adoption of ECC+PQ signatures but then never followed through. Of course I hope that drawing attention to this misbehavior will deter future misbehavior by the chairs, but nothing in IETF rules stops the chairs from saying that circumstances changed and that this wasn't a commitment. Similarly, if the third "last call" for solo ML-KEM fails then nothing in IETF rules stops the chairs from issuing a fourth "last call". Again, this is not symmetric between yes and no: if the third "last call" passes then it's final and you'll never have another chance to cast a vote on ietf-tls-mlkem.
Of course, if you're casting a negative vote on the basis of the fact that there are unresolved objections, then there's a clear risk that proponents will just wait and then call another vote while still not addressing the objections. But won't this evasion help you see what the right vote is? Also, think again about the impact of errors: if opponents are right, if what we're talking about here is sabotaging security for millions of users, then every delay in this sabotage is a big win.