[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

[Nadim Kobeissi <[e-mail]>]

Hi everyone,

I would like to register my objection to the publication of this draft.

My background in formal verification of TLS 1.3 (e.g. https://inria.hal.science/hal-01528752/file/RR-9040.pdf) makes me particularly attentive to compositional security properties. Hybrid constructions provide a clean guarantee: key establishment remains secure under compromise of either component. This is a property worth preserving, and the draft offers no justification for discarding it.

I am in all honesty completely baffled by the highly unusual insistence to adopt this draft. As I understand it:

- Hybrid constructions protect us from classes of attacks that pure-PQ constructions do not protect us against.
- Hybrid constructions have a negligible overhead compared to pure-PQ constructions.

Despite my attempts at good faith engagement with the text of draft-ietf-tls-mlkem-05, I struggle to determine any benefit that a pure-PQ construction can possibly have when compared to a hybrid construction aside from eliminating a negligible performance overhead. And yet, adopting a pure-PQ key establishment option for TLS 1.3 renders it vulnerable to an entire class of attacks that hybrid constructions were designed to eliminate.

The world's Internet has been happily running TLS 1.3 with hybrid constructions for years now, providing robust security guarantees against SNDL attacks (thanks to ML-KEM) as well as higher assurance against classical attacks in PQ constructions (thanks to ECC), since, as we know, these are relatively much less mathematically well-studied than their classical counterparts.

One would think that applying such an important change to such a happy and problem-free status quo would require exceptional motivation. And yet, the Motivation section of draft-ietf-tls-mlkem-05 is completely circular. Here it is, in its entirety:

> FIPS 203 (ML-KEM) [FIPS203] is a FIPS standard for post-quantum
> [RFC9794] key establishment via lattice-based key establishment
> mechanism (KEM).  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.

This motivation section contains zero bits of entropy. It's like saying "this green banana store exists for people who prefer green bananas to yellow ones." Okay? But why would anyone prefer that in the first place? The motivation remains completely unexplained aside from it being self-referential.

In all honesty, this draft is just completely inexplicable, even bizarre, to me. It would re-introduce an entire class of attacks to the TLS key establishment protocol and I have absolutely no idea what the tangible benefit is in that equation.

Please do not adopt this draft.

On Fri, Feb 20, 2026, at 8:58 AM, Thom Wiggers wrote:
> Hi all,
>
> I support the publication of this draft.
>
> Cheers,
>
> Thom 
>
>> Op 20 feb 2026, om 04:56 heeft Viktor Dukhovni <[e-mail]> het volgende geschreven:
>> 
>> On Fri, Feb 20, 2026 at 01:18:52AM +0000, Peter Gutmann wrote:
>> 
>>> Unless it's PQC, in which case the minute it's in the spec, in fact long
>>> before there's even a spec for it, everyone will be clamouring for it to
>>> appear.  Not arguing against publication, just pointing out that when it comes
>>> to post-magic crypto the only choices you have are "support it" or "support
>>> it".
>> 
>> OpenSSL 3.5 and later do indeed provide an implementation, but FWIW, the
>> non-hybrid ML-KEM groups are not enabled by default, both client and
>> server have to choose to enable them explicitly in their configurations.
>> 
>> Only X25519MLKEM768 is enabled by default, and in 4.0 we'll shortly add
>> a default fallback to the SecP256r1MLKEM768 hybrid (but without a
>> predicted client keyshare, so used only after a server HRR, if the
>> server for some reason supports the P-256, but not the X25519 hybrid).
>> 
>> Once a VIC-20, an abacus or a dog[1] can no longer beat demonstrated
>> implementations of Shor's algorithm, perhaps the pure ML-KEM variants
>> would also make sense to enable by default.
>> 
>> Before I take CRQCs as a credible looming issue, a milestone I'd want to
>> see crossed would be an honest Shor's algorithm factorisation of a
>> 32-bit RSA modulus[2], but perhaps I should first have asked for a
>> 16-bit RSA moduls instead, as that too appears to be currently well out
>> of reach.
>> 
>> -- 
>>    Viktor.  🇺🇦 Слава Україні!
>> 
>> [1] https://eprint.iacr.org/2025/1237.pdf
>> [2] https://scottaaronson.blog/?p=9564#comment-2025810
>> 
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Nadim Kobeissi
Symbolic Software • https://symbolic.software