[Cryptography] NSA voting on TLS encryption at the IETF TLS WG

[D. Hugh Redelmeier]

I'm really not up to speed on this, but the little bit that I've read 
makes this draft look bad.  I've joined the mailing list but I'd like to 
be confident before posting my position.

What do others on this list think?

The key points that I've absorbed are:

- ECC + MLKEM is belt-and-suspenders and that is needed since MLKEM has 
  not stood the test of time.

- the extra cost of ECC is minor (how minor?)

- the proponents of the draft deflect by saying that bare MLKEM isn't 
  recommended.  That's a heck of a defence since the simplest and most 
  effective form of not recommending is not standardizing it.  The draft's 
  approach looks fishy and designed to fail.  50% + 1 isn't consensus.

- several people I've trusted are against it.  This makes me think that 
  a reasonable standard for consensus is not being met.

- the new draft fixes some objections, but not the fundamental one.

- room packing seems to be happening.  I would like to counter that 
  (admitting that I'm really part of packing too)

I often find DJB convincing but sometimes when I actually hear the other 
side, the issues seem less black-and-white.  I haven't yet read anything 
that plausibly counters his points in this case.

Why was/is DJB moderated?  The announcement of moderation really doesn't 
make that clear.

> From: Andrew Lee <andrew at joseon.com>
> To: cryptography at metzdowd.com
> Date: Thu, 2 Jul 2026 11:54:33 -0700
> Subject: [Cryptography] NSA voting on TLS encryption at the IETF TLS WG
> 
> Dear Cypherpunks,
> 
> The IETF TLS WG is running a Working Group Last Call on draft-ietf-tls-mlkem-08, solo ML-KEM key exchange for TLS 1.3 without the classical crypto fallback. Hybrid is already standardized and widely deployed [1]. This draft adds the single-lock option with a RECOMMENDED=N flag buried in the IANA considerations, but env vars aren't for people.
> 
> The vote closes July 8.
> 
> 
> Arguments against:
> 
> - Hybrid costs 32 bytes and sub-millisecond cpu time. Solo is strictly worse by every measure.
> - Dr. Nadim Kobeissi's formal analysis of these exact algorithms in TLS 1.3 concluded that hybrid neutralizes every weakness solo carries [2].
> - The Canadian Centre for Cyber Security said on-list they plan to use this RFC to recommend solo KEM in their government guidance [3].
> - SIKE, a NIST PQC finalist, was completely broken in 2022. Post-quantum assumptions can and do fail. The hybrid exists as a safety net.
> 
> Arguments for:
> 
> - Solo implementations already exist in OpenSSL, BoringSSL, Rustls, and others. Some argue the IETF should provide guidance rather than let ad hoc implementations proliferate.
> - CNSA 2.0 calls for standalone PQ, so government vendors want a spec to reference.
> - Having an RFC gives the WG the ability to attach security considerations and update guidance over time.
> 
> Dr. Daniel Bernstein has been placed under moderation during this vote [4]. His posts require chair approval with up to a two business day delay. The stated reason is a copyright footnote. Two days after the moderation, the IAB told him WGLC is the proper venue for his technical objections [5], but he's been gagged.
> 
> This is actually the third vote now to give you an idea. The second went 22-21 against publication. The chairs never published the count and subsequently called for another vote [6]. NSA employee Mike Jenkins [7] voted in support from his cyber.nsa.gov email, the first time he had ever appeared on the list. A formal appeal challenging the moderation has been filed and accepted by the IESG.
> 
> Instructions for participating are at https://nsa.2026.action.cr.yp.to/ and the deadline is July 8.
> 
> Cypherpunks write code, but we also have a duty to ensure the right code is being written.
> 
> Sincerely,
> Andrew
> 
> [1] https://blog.cloudflare.com/post-quantum-to-origins/
> 
> [2] https://github.com/symbolicsoft/reftls/blob/master/paper/tls-hybrid.pdf
> 
> [3] https://mailarchive.ietf.org/arch/msg/tls/uOeM5IRcYYjpNFlRyxEfo91q29c/
> 
> [4] https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1DbxqoWrRA/
> 
> [5] https://mailarchive.ietf.org/arch/msg/tls/h8cauWdDyMdtGEOB1Nc5OT0yOQo/
> 
> [6] https://blog.cr.yp.to/20260405-votes.html
> 
> [7] https://mailarchive.ietf.org/arch/msg/tls/XIckyKVIEgKNus-koXOLooFpU54/  (Not to be confused with Leeroy Jenkins, despite the similarity in their actions and causing of aggro.)
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography
>