2026.08.14: NSA and IETF, part 9: An update. #pqcrypto #hybrids #nsa #ietf #procedures

Back in June, I saw that NSA and its minions had called and were packing an IETF vote on standardizing a specification of how to remove the ECC seatbelt from hybrid ECC+ML-KEM in TLS. For example, one vote for the spec was from NSA's Mike Jenkins, who had never sent email to the TLS mailing list before. I responded by calling for volunteers to speak up on the public-interest side.

I'm happy to report that 82 people spoke up on the TLS mailing list in unambiguous opposition to this spec during the voting period. There were also some additional people (Izzy Grosof, for example, and Ivan Visconti) who had already registered opposition before the voting period; I've heard credible reports of further opposition messages being blocked by the chairs; and, even though this wasn't filed as opposition, it was good to see the following statement from Roberto Avanzi: "as a codesigner of ML-KEM myself I would not trust using it exclusively: what if it gets broken mathematically and in the classical computational model (I.e. non-quantum)? Hybrid is better, and the additional time used by ECC is not significant."

(In the opposite direction, I've been pointed to the following claim from Thomas Ptacek: "The more cryptography-literate you are, the more likely it is you think hybrids are silly." Oh, well, I guess that settles it then.)

For 75 of the 82 people with opposition statements on the list during this voting period, I see no way that anyone can even try arguing that anything in their messages suggests the possibility of spec modifications removing the objections. I've taken quotes from those 75 people and forwarded them to "IESG", the Internet Engineering Steering Group, along with my replies to talking points from spec proponents. Copies of my messages to IESG: 1, 2, 3, 4.

The rest of this blog post says what's supposed to happen, what has happened so far, and what's likely to happen next.

What's supposed to happen?

Here's what IETF says: "IETF participation is free and open to all interested individuals. ... IETF activities are conducted with extreme transparency, in public forums. Decision-making requires achieving broad consensus via these public processes. ... Fundamentally, '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 work is divided across "working groups" (WGs). Here's what IETF says about WG decisions: "The general rule on how Working Groups make decisions is that the Working Group has to come to 'rough consensus', meaning that a very large majority of those who care must agree, and that those in the minority have had a chance to explain why and their points have been addressed, even if they were not agreed with."

There's a further rule that "51% of the working group does not qualify as 'rough consensus' ". This rule doesn't say "51% of a quorum". Also, there's a rule that disagreements "must be resolved by a process of open review and discussion".

If a WG "last call" shows "rough consensus" to issue an RFC, the WG chair still can't issue the RFC directly. Instead the WG chair forwards the spec to IESG, which issues its own "last call". The rules say that "Comments on a Last-Call shall be accepted from anyone". If IESG decides to issue an RFC, the RFC says that it "represents the consensus of the IETF community".

If there isn't "rough consensus" in the WG in the first place—for example, if the spec hasn't reached agreement of "a very large majority of those who care"—then the spec isn't supposed to be sent to IESG; it's supposed to be rejected by the WG chairs.

For this particular spec, even after the vote-packing by NSA and its "vendors", proponents certainly don't have 51% of the working group—and 51% still wouldn't qualify. Proponents certainly don't have "a very large majority" of the people who cared enough to speak up; they weren't even half of the people who spoke up. Furthermore, the most important points from opponents remain unaddressed.

To summarize, "rough consensus" includes a bunch of requirements that the spec doesn't meet. So the WG chairs were supposed to say: sorry, there isn't "rough consensus" to issue this spec as an RFC.

What has actually happened?

The chairs ignored the rules and declared "rough consensus" to issue this spec as an RFC. Here are some of the shifting rationales they've presented for this so far:

• Story 1: "if we look at pre-existing WG participants or people with demonstrated expertise, roughly 7/10 WG participants favor advancing the document, which shows rough consensus to move the document forward". (Where's the list of people that the chairs declare haven't "demonstrated expertise"? What happened to "IETF participation is free and open to all interested individuals"? What happened to "Decision-making requires achieving broad consensus via these public processes"? What happened to reaching agreement of "a very large majority of those who care"?)

• Story 2: the chairs "focused their consensus judgement on people that participated in TLS prior to the last WGLC". (Wait, so new participants with "demonstrated expertise" suddenly don't count any more? And what gives chairs the right to disenfranchise new participants in favor of pre-existing participants?)

• Story 3: "Consensus is determined by assessing the quality and resolution of technical arguments rather than by simple counts". (Wait, what happened to "roughly 7/10 WG participants favor advancing the document, which shows rough consensus to move the document forward"? Sounds like the chairs were using counts a moment ago!)

When the chairs called their vote in the first place, they asked WG participants to say "whether you support publishing a document specifying a stand alone ML-KEM"—and to "refrain from further discussion on this topic". When some people engaged in discussion anyway, the chairs sent messages such as the following: "AGAIN!!!! Let's stick to the consensus call, 'I support' or do 'I do not support' as was requested in the email that began this thread." So it's amazing to see the chairs retroactively claiming that "a consensus call is not a vote" and that people were instead supposed to provide technical arguments for quality evaluation by the chairs.

Despite the chairs saying just shut up and vote, many opposition statements did lay out technical arguments against this spec. The chairs didn't post an evaluation of those arguments. Instead the chairs dodged the arguments by claiming that "a recommended status of 'N' in the IANA registry ... clearly indicates that hybrid approach is recommended over the pure approach by the working group" and that "Fundamentally whether or not to use pure ML-KEM is a judgement call people have to make for themselves". Notice that this violates "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".

More to the point, the chairs aren't supposed to be taking action based on their own view that the spec is okay. They're supposed to be evaluating whether there's "rough consensus".

The chairs, purportedly "on behalf of the TLS working group", forwarded the spec to IESG by email dated 28 Jul 2026 15:10:40 -0700 to request issuance of an RFC. IESG sent email on 30 Jul 2026 13:38:00 -0700 issuing "last call" on this spec, based on supposedly having "received a request from the Transport Layer Security WG".

At no moment have the chairs admitted how many people spoke up to object. People looking at what the chairs reported up the ladder won't see most of the objections—and might not even realize how controversial this spec is.

The chairs paint a picture of the opposition disintegrating. That simply isn't true. The number of opponents has increased in each round of voting. Three narrow-issue opponents (Stephen Farrell, John Mattsson, Muhammad Usama Sardar) dropped their objections, but many more people found out what was going on and spoke up in opposition.

What's likely to happen next?

I'd like to think that IESG will look at the opposition statements from 75 people and say: okay, there's no consensus here, we have to reject this. I'd also like to think that IESG will grasp that this spec is contrary to the security goal in the TLS WG charter and doesn't serve any of the other goals in the charter, so it has to be rejected as a charter violation.

But the reality is that people tend to do what they're paid to do. So let's take a moment to look at the money flow.

I've previously posted quotes showing how NSA is pressuring its "vendors". For example, a Cisco employee wrote "that's what they're willing to buy. Hence, Cisco will implement it"; and an NSA employee wrote "Our interactions with vendors suggests that this won't be a problem in most cases". Here are some of the IESG members:

• Cisco employee Charles Eckel.
• Cisco employee Eric Vyncke.
• Cisco employee Ketan Talaulikar.

As another example, consider SEI. The SEI web page says "Sponsored by the Department of War, the SEI is a federally funded research and development center"; Congress's Office of Technology Assessment explained many years ago that FFRDCs are shell companies created by the U.S. government "to attract the best and the brightest people available using salary above the wage scale the federal government offers". SEI is hosted at a university, but it's a U.S. defense subsidiary, not an independent academic lab. Here are another two IESG members:

• SEI employee Roman Danyliw, IESG chair.
• SEI employee Christopher Inacio.

Let's try some more examples. Akamai is the sole provider of the Global Content Delivery Service to the Defense Information Systems Agency. Cloudflare and Nokia announced in March 2026 their participation in the "Missile Defense Agency Scalable Homeland Innovative Enterprise Layered Defense (SHIELD) indefinite-delivery/indefinite-quantity (IDIQ) contract with a ceiling of $151B". Each of these companies employs an IESG member:

• Akamai employee Mike Bishop.
• Cloudflare employee Tommy Jensen.
• Nokia employee Gunter Van de Velde.

Then there's NSA itself:

Cooley says she retired to join IESG in 2024. She was accurately listing NSA on a conflict-of-interest form after joining IESG. But then she switched to claiming that retirement removed the conflict of interest. No, it doesn't. That's the whole point of what are called "revolving door" prohibitions.

There are only 14 IESG members, and I've just listed 9 of them. So, okay, let's assume IESG makes up some excuse to approve the spec. What happens then?

There are procedures to appeal the decision by the WG chairs, first to NSA's Deb Cooley, then to the full IESG, then to another committee called the "Internet Architecture Board" (IAB), where defense-contractor employees (SEI employee Roman Danyliw, Cisco employee Suresh Krishnan, Cloudflare employee Mark Nottingham, Nokia employee Matthew Bocci, Google employee Warren Kumari, Comcast employee Jason Livingood, Zscaler employee Yaroslav Rosomakho) are again a majority.

There are also procedures to appeal the IESG decision, first to SEI's Roman Danyliw, then to the full IESG, then to IAB.

Anti-corruption organization Transparency International has a reference guide for procedures that organizations should set up to handle complaints. IETF doesn't follow any of that. IETF has no procedural constraints on how appeals are handled.

It also won't be surprising to see an RFC issued before appeals are resolved. Even without tons of money being thrown around, this would produce yet another incentive to deny the appeals, simply to avoid the paperwork of withdrawing an RFC.

There's one last level of appeal possible within the IETF procedures: complaining to the Board of Trustees of the Internet Society, IETF's parent organization, that IETF's procedures are "inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process". I already complained to ISOC in December 2025. ISOC said that the "timing and process" of handling the complaint would be discussed during ISOC's 25–26 July 2026 meeting and then the board would "designate someone to get in touch with you".

Maybe they'll designate board member Russ Housley. He's already familiar with what's going on:

• He has voted three times to issue this spec as an RFC. So he's familiar with the particular topic at hand.

• He was originally Air Force, and is now president of a small consulting firm called Akayla that has received $210000 in military contracts since 2023, as my regular readers might recall. So he's familiar with the influence of defense contracting.

• The six NSA employees who showed up in the latest round to vote for the spec—Mark Motley, Mike Jenkins, Morgan Stern, Nicholas Gajcowski, Peter Yee, and William Layton—include one, Peter Yee, who works not just for NSA but also for the same small firm Akayla. So Housley is familiar with NSA's interests.

• Sean Turner, one of the TLS WG chairs, is the "Treasurer, Secretary, and Security Officer" of Akayla (along with having various redacted affiliations). So Housley is familiar with the interests of the WG chairs. (Another TLS WG chair, the spec's author, is an employee of CIA-funded Sandbox AQ.)

• Housley served as IETF's Security Area Director 2003–2007, as IETF Chair 2007–2013, and as an IAB member 2007–2017. So he's familiar with how IETF works.

Sounds like he's the perfect man in the perfect position to make sure that the IETF procedures do what they're supposed to do. Let's see what happens!