I blogged last month about NSA and its partner GCHQ trying to have standards-development organizations endorse weakening ECC+PQ down to just PQ.
Today the PQ story is even more exciting, with a critical deadline just a few days from now. Read on!
I have three blog posts today on this topic: parts 2, 3, and 4 of the story. This blog post, part 2, focuses on corruption. Part 3 will focus on a "security area director" dodging every important topic at hand, most importantly security. Part 4 will give an example of how dissent on this topic has been censored, despite IETF's claims of openness.
A brief reintroduction to the villain. By 2013, NSA had a quarter-billion-dollar-a-year budget to "covertly influence and/or overtly leverage" systems to "make the systems in question exploitable"; in particular, to "influence policies, standards and specification for commercial public key technologies". NSA is quietly using stronger cryptography for the data it cares about, but meanwhile is spending money to promote a market for weakened cryptography, the same way that it successfully created decades of security failures by building up the market for, e.g., 40-bit RC4 and 512-bit RSA and Dual EC.
Recap of the previous episode. I looked concretely at what was happening in IETF's TLS working group, compared to the consensus requirements for standards-development organizations. I reviewed how a call for "adoption" of an NSA-driven specification produced a variety of objections that weren't handled properly. ("Adoption" is a preliminary step before IETF standardization.)
Ultimately there wasn't general agreement to adopt the document. But the TLS chairs falsely claimed that "we have consensus to adopt this draft". An IETF "security area director" 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".
The actual tallies were 20 people expressing unequivocal support for adoption, 2 people expressing conditional support for adoption, and 7 people expressing unequivocal opposition to adoption. Majority of voters supporting? Yes. Consensus? No.
I closed that blog post by citing a complaint that I had filed regarding the claim of consensus. I also had a blog post the next day about IETF's current and proposed censorship procedures, where I'll mention just one tidbit here: when IETF subsidiary IRTF refused back in 2014 to remove an NSA employee as a chair, it claimed that chairs "are little more than group secretaries".
A burst of corrupt public activity. On 1 November 2025, the "Internet Engineering Steering Group" (IESG) suddenly publicly instructed the "area director" to answer the following question: "Was rough consensus to adopt draft-connolly-tls-mlkem-key-agreement in the TLS Working Group appropriately called by the WG chairs?" This came after half a year of shameful stonewalling regarding that question.
The "area director" posted his 200-line response the same day. His summary: "I agree with the TLS WG Chairs that the Adoption Call result was that there was rough consensus to adopt the document". I'll look at the details in part 3.
On 5 November 2025, the chairs issued "last call" for objections to publication of the document. The deadline for input is "2025-11-26", this coming Wednesday.
What's fundamentally dishonest about issuing a "last call" for objections here is that it tells the reader that the previous objections had been resolved. People who already objected are forced to repeat themselves, or else the chairs will act as if the objections were never even raised. Even worse, when people do re-raise major objections, proponents simply register one positive vote after another, ignoring the content of the objections. Meanwhile IETF claims that it doesn't make decisions by voting.
Each of the following links is an example of a statement of unequivocal support in response to this "last call", a statement that's non-responsive to every major objection that has been raised to the document, a statement from an employee of an agency or company with an amply documented conflict of interest:
Rebecca Guthrie, an employee of NSA: "I support publication of the document."
Florence Driscoll, an employee of NSA's spying partner GCHQ: "I support publication of this document"; also some editorial nitpicks that "aren't blockers".
Keegan Dasilva Barbosa, an employee of another NSA spying partner, Communications Security Establishment Canada: "I support the publication of this document, as it aligns with the government of Canada's plans to include the use of pure ML-KEM within our guidance documentation."
Quynh Dang, an employee of NIST: "I support the publication of the document." (Also: "I am not a representative of NIST or any other organization in this message." Oh, okay, I guess the money flow doesn't matter then!)
David Adrian, an employee of a company receiving massive U.S. military funding, namely Google: "I support the publication of this document, and note that 0x0202 is implemented (behind a flag) in Chrome."
John Mattsson, an employee of U.S. military contractor Ericsson: "I support publication as long as the major comments below are addressed". Mattsson had expressed conditional support for adoption "as long as reuse of ephemeral keys is normatively forbidden" and raised the same concern again; but, when push comes to shove, Mattsson's vote is for the document.
Russ Housley, originally Air Force, now president of a small consulting firm called Akayla that has received $210000 in military contracts since 2023: "I support adoption." (Given the context, I think it's clear enough that "adoption" here was meant as "publication".)
There's also Uri Blumenthal from "MIT Lincoln Laboratory", which people often don't understand is a subsidiary of the U.S. military. Lincoln Laboratory is one of many "federally funded research and development centers" that the U.S. military created to "attract the best and the brightest people available using salary above the wage scale the federal government offers". MITRE is another example, as is NSA subsidiary IDA, which hired famed cryptanalyst Don Coppersmith away from IBM more than 20 years ago.
The only reason Blumenthal isn't in my bullet list above is that what he has written in response to last call (e.g., "Based on what's been posted and presented at various forums, US Government explicitly wants (a) pure ML-KEM, and (b) nothing less than ML-KEM-1024") isn't clear enough for me to say that it's an unequivocal statement of support. But Blumenthal is already on record pushing repeatedly for non-hybrids, so I presume that before the end of the last-call period he'll make a more clear statement in favor of standardizing this document.
Balance of interests. From a security perspective, it's dangerous to equate "known to be funded by an attacker" with "wrong". What if the attacker publicly throws money at something that the attacker secretly knows is right? What should be happening instead is standardization decisions made on the basis of the public interest, so that attackers can't manipulate the process in any direction.
Standards-development organizations are required by law to have "openness, balance of interests, due process, an appeals process, and consensus". The "balance of interests" part is spoiled when attackers and their pawns can flood IETF with votes.
For comparison, let's look at ANSI, which has a century of experience and millions of participants. The central ANSI rules include the following requirements:
"Participants from diverse interest categories shall be sought with the objective of achieving balance."
"In determining the interest categories appropriate to a standards development activity" a group "shall give consideration to at least the following three categories: producer; user; general interest."
"Where appropriate, additional interest categories should be considered. However, interest categories shall not be created for the purpose of avoiding balance requirements."
"Interest categories shall be discretely defined, cover directly and materially interested parties and differentiate each category from the other categories. Such definitions shall be available upon request."
"Appropriate, representative user views shall be actively sought and fully considered in standards activities."
As another example, let's look at the rules for ASME, which also has a century of experience: "In order to establish balanced representation for developing evidence of consensus on standards, consensus committee members shall be classified in accordance with the business interests of their primary source of support for committee participation. ... No single category shall have a majority on consensus committees dealing with product standards except with the recorded approval of the other classifications and the approval of the cognizant board." For "safety codes", each category is limited to 1/3.
Where are IETF's rules ensuring that each decision is made by a group with a balance of interests? Answer: IETF has no such rules.
What IETF says about balance of interests is as follows: "A wide range of perspectives is represented, reflecting interests from multiple industry sectors, academia, government and non-governmental organizations (NGOs), from around the globe." This does a spectacular job of missing the point.
The reason for requiring a balance of interests is to protect each decision against being corrupted. IETF procedures allow any particular decision to made by a tiny, biased group of people inside a WG, as long as the decision is approved by IESG—which is another tiny, biased group, the same group that appoints WG chairs in the first place. Saying that a much wider range of people participate in IETF does nothing to protect any particular decision.
In theory, "IETF participation is free and open to all interested individuals"; each "Working Group (WG) has its own mailing list with most of its interaction, and all of it official work, conducted on this list"; "anyone from the Internet community who has the time and interest is urged to participate"; "IETF activities are conducted with extreme transparency, in public forums"; and "decision-making requires achieving broad consensus via these public processes".
In reality, IETF standardization is a denial-of-service attack. The only people who can keep up are people paid to participate. Instead of acknowledging the resulting bias and taking appropriate countermeasures, IETF pretends the problem doesn't exist.
I've been focusing on one incident of corruption of the IETF standardization process, but this isn't an isolated example. Look at Peter Gutmann's October 2025 slides blasting IETF as a "pay-to-play" standards organization and giving many concrete examples. Corruption is a money-maker; it's not some sort of surprise.
In those slides, the top advice for "how to spot a pay-to-play standard" is "No obvious purpose". The prototype stated in the slides is "This standard for storing key bits upside down exists to provide a standard for storing key bits upside down". For comparison, here's the rationale stated in Section 1.1 of the NSA-driven document at issue: "Having a purely post-quantum (not hybrid) key establishment option for TLS 1.3 is necessary for migrating beyond hybrids and for users that want or need post-quantum security without hybrids."
Engineering vs. bribery. IETF claims 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".
Given how many post-quantum proposals have been broken and the continuing flood of side-channel attacks, any competent engineering evaluation will conclude that the best way to deploy post-quantum encryption for TLS, and for the Internet more broadly, is as double encryption: post-quantum cryptography on top of ECC.
Part of the public NSA/GCHQ anti-hybrid messaging is unquantified fearmongering about cryptographic costs, trying to make readers imagine that weakening ECC+PQ to just PQ is the only way to fit inside an Internet application's cost constraints. The reason they aren't presenting the numbers is that the numbers don't support their case. The main cost of ECC+PQ is PQ network traffic, not ECC network traffic or ECC computation. The cost difference between ECC+PQ and PQ is even less noticeable in the context of overall application costs: for example, in 2024, Meta reported spending only 1 out of every 2000 CPU cycles on X25519, which is the ECC choice used in the "vast majority" of TLS connections.
Within IETF, the companies pushing this document seem to understand that they can't make an engineering case for the document. Presumably that's why they aren't even trying. Instead they have been saying: NSA is asking us for this, so we're implementing it and we want IETF to endorse it.
My previous blog post already traced through how this document was introduced in pursuit of "CNSA 2.0 compliance"; how Cisco wrote "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, more broadly, how NSA says it has been buying support: "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."
Do these quotes sound like IETF participants using "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"? Or do they sound like NSA buying standardization?
Video of a small TLS WG meeting on 3 November 2025 (with many presentations, and only a few participants looking like they were paying attention to each presentation) did include a brief statement of a rationale for standardization, namely that the document was implemented in OpenSSL, two OpenSSL forks, and Rustls. This isn't applying engineering judgment to find the best solution for the whole Internet: it's simply another reflection of the fact that NSA asked for this.