GoKawiilThe cr.yp.to blog
2026.07.06: NSA and IETF, part 8: Fairness. #pqcrypto #hybrids #nsa #ietf #riskmanagement
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
... continue reading