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

Thu Jul 2 20:36:34 EDT 2026

The TLS WG in the IETF is not debating whether MLKEM only shall be 
preferred to the hybrid ECC + MLKEM. That debate already happened, and 
the IETF consensus is clearly for hybrid approach. The hybrid X25519+ 
MLKEM (X25519MLKEM768) has been approved by the working group already, 
is being published on the standard track, and is marked a 
"recommended=Y" in the IANA registry of TLS supported groups 
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). 
The "naked" MLKEM specification is proposed to be published as an 
informational RFC (i.e., not standard), and is marked a "recommended=N". 
The IETF is not proposing to discard hybrids and use pure PQ algorithms 
now, quite the contrary. Stating that is either being misinformed, or 
perhaps using extreme debating tactics to make a point.

The way I understand Dan Bernstein's argument, he asserts that 
publishing the MLKEM draft as an RFC, even if clearly marked as "not 
standard", will be used as the NSA as a PR boost. I do not think that's 
a strong argument. There are all kinds of documents in the RFC series, 
reflecting a general preference for publishing over hiding that goes 
back all the way to the roots of the RFC series. See for example RFC 
1796, published 31 years ago (https://www.rfc-editor.org/info/rfc1796/).

-- Christian Huitema

On 7/2/2026 3:40 PM, D. Hugh Redelmeier wrote:
> 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
>>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> https://www.metzdowd.com/mailman/listinfo/cryptography