NSA and IETF, part 8

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

• NSA’s Mark Motley,
• NSA’s Mike Jenkins,
• NSA’s Nicholas Gajcowski,
• GCHQ’s “Flo D”,
• GCHQ’s “Michael P”,
• GCHQ’s “Peter C”,
• Cisco’s David McGrew,
• Cisco’s Eliot Lear,
• Cisco’s Scott Fluhrer,
• Google’s David Adrian,
• Google’s David Benjamin,
• Google’s Sophie Schmieg,

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.

Version:
This is version 2026.07.06 of the 20260706-fairness.html web page.