Hi again, It looks like draft-ietf-tls-mlkem-07 has an expanded Motivation section, adding:
> Use cases include regulatory frameworks that require standalone post-quantum > key establishment, targeting smaller key sizes or less computation, and > simplicity. This is not a compelling or legitimate reason. The IETF should be publishing specifications that improve security, privacy and performance around the world, in line with the global public interest, and not to please arbitrary regulatory frameworks of specific countries, especially when those come at the expense of the studied and proven compositional security guarantees of hybrid constructions. I'm sure that different governments could have very different ideas regarding what constitutes a legitimate regulatory framework: In 2015, the government of Kazakhstan created a root certificate which could have enabled a man-in-the-middle attack on HTTPS traffic from Internet users in Kazakhstan. Kazakhstan tried to do this again in 2019, and once more in 2020. If the Kazakh government were to propose a regulatory framework that would be in line with such a weakening of TLS's security guarantees, should be formulate an IETF draft to accommodate it? If the answer is no, then why is a request from any other government that aims to allow for PQ-only key agreement constructions, which would reintroduce entire classes of attacks, or reduce key sizes, more legitimate? When we publish specifications, we should be doing so because they are good ideas, because they improve the security and privacy of people worldwide, or because they propose performance improvements while maintaining these proven security guarantees. We should not be publishing specifications because a big impressive authority would like us to, in spite of serious potential negative effects on our studied and proven compositional security guarantees. On Fri, Feb 20, 2026, at 9:32 AM, Nadim Kobeissi wrote: > 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 <[email protected]> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > -- > Nadim Kobeissi > Symbolic Software • https://symbolic.software -- Nadim Kobeissi Symbolic Software • https://symbolic.software _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
