* At the moment, no client or server library I am aware of even includes the key exchange algorithm, much less do any of them prefer them over hybrid. Windows TLS stack is about to ship pure ML-KEM KEX support (in addition to hybrid KEX). Pure ML-KEM will likely remain disabled by default for the foreseeable future, requiring administrator action to enable. And no, we’re not doing this under the influence of draft-mlkem, and we’re not guided by whether it becomes an RFC or not.
* I've now seen multiple references that this draft would make TLS less secure for everyone, if only some random server administrator got goaded into enabling it in their server config due to being mislead by an RECOMMENDED = N RFC. It would take more than some random server admin flipping settings. It would require some popular TLS implementations to enable ML-KEM by default. I’m not aware of any major TLS stack implementors who would take this lightly, nor any that would be guided by the presence or absence of an RFC in this decision. Cheers, Andrei From: Sophie Schmieg <[email protected]> Sent: Tuesday, July 7, 2026 11:50 AM To: [email protected] Subject: [EXTERNAL] [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) hi all, I've now seen multiple references that this draft would make TLS less secure for everyone, if only some random server administrator got goaded into enabling it in their server config due to being mislead by an RECOMMENDED = N RFC. I think it's important to state emphatically that this is not the case, due to the nature of how TLS works. I have gotten some offlist questions on why I do not consider that danger, and I'm happy to repeat them on list here: In particular, the key agreement algorithm (called NamedGroup in TLS, I presume in honor of the group ker(A^t, Id) of ML-KEM) is negotiated in TLS in a way that ensures a double opt-in. TLS is a "Client proposes, Server picks" protocol, which means that in order to negotiate any specific NamedGroup, the client first has to propose it, and then the server has to pick it from the list of client suggested groups. This means that in order for pure ML-KEM to be chosen over hybrid both server and client have to both include it in their set of supported options and the server has to prefer it over the hybrid. At the moment, no client or server library I am aware of even includes the key exchange algorithm, much less do any of them prefer them over hybrid. There is, as it currently stands and how it is poised to continue given the stances of the various library maintainers, no chance that any connection would accidentally negotiate pure ML-KEM. In order to get pure ML-KEM you need control over the configuration of both endpoints of a TLS connection, the mechanism is robust against a single misconfiguration. Importantly, this negotiation is robust against downgrade attacks, meaning that, since it is included in the KDF that produces the eventual session key, it cannot be modified by a third party without causing the handshake to fail. The only way pure ML-KEM can be chosen over a hybrid is because both client and server explicitly wanted this behavior to occur. This is what makes it secure for a TLS client to advertise less trusted key agreement algorithms, and for servers to pick such algorithms, knowing that they will not be forced into the less trusted algorithm if there is another choice. My blog post [1] has been referenced before on this list and goes into greater detail as to why things like comparisons with DUAL_EC_DRBG fall flat to begin with, but I think it is important to emphasize that, even if one assumes a total compromise of pure ML-KEM there exists no risk to the public internet from this draft. Sophie P.S.: The lack of mail headers due in the replies has made my inbox hopelessly fragmented, I added this reply to the next best thread I could find, apologizes if that makes the problem worse for anyone. P.P.S.: I am always happy to answer good faith question to ML-KEM, both in public and off list. This is a difficult technical topic, and unfortunately the minutia really matter here. P.P.P.S.: Apologies to the chairs for this messages being not only bound to support/not support. [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ On Tue, Jul 7, 2026 at 10:17 AM John Mattsson <[email protected]<mailto:[email protected]>> wrote: Agree with David I think this is a largely unsurprising implementation survey wrapped in an extremely exaggerated security narrative. The fact that a randomness compromise, an attacker-controlled RNG, or an attacker with code/build control break security is neither new nor surprising, nor is it specific to ML-KEM. The comparison with Dual_EC_DRBG is particularly misleading. The one genuinely useful point in the paper is that some libraries expose internal functions. However, in the case of ML-KEM, these interfaces do not appear to give an attacker any capability that they could not implement themselves. The main concern with exposing the internal ML-KEM interfaces is that developers may misuse them. NIST seems to have done everything right, they listened to feedback from the cryptographic community and followed current best practices for designing cryptographic interfaces including making the distinction explicit by naming the functions _internal() and _external(). Cheers, John Preuß Mattsson From: David Benjamin <[email protected]<mailto:[email protected]>> Date: Tuesday, 7 July 2026 at 18:36 To: Mark Tehrani <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) This paper seems to amount to being concerned about something that is standard practice in testing non-deterministic cryptographic processes: you should have a defined, deterministic process from explicitly-passed entropy, because that makes testing possible. https://words.filippo.io/avoid-the-randomness-from-the-sky/ As it's standard practice, this is not unique to ML-KEM. In X25519, the equivalent of the encapsulation coin in ML-KEM is the X25519 private key that each side generates. That too needs to come from a secure source of randomness. At the same time, you'll find that every implementation provides some deterministic version of this API. This is both for deterministic testing and because that's how you import a serialized private key. Indeed, because of the latter, you will not see any kind of testing guard on it. X25519 depends on the caller knowing the difference between importing and generating a key. For example, see this API where both computing the public key and the Diffie-Hellman operation itself just take the secret as an explicit parameter. Should one predictable entropy in there, the system would also break. https://cr.yp.to/ecdh.html This does not seem to be a reason to be concerned about ML-KEM over any other algorithm. Calling the correct functions in your TLS stack, and making sure an attacker cannot modify your TLS stack to call the wrong functions, is part of the baseline for everything here. On Tue, Jul 7, 2026 at 11:39 AM Mark Tehrani <[email protected]<mailto:[email protected]>> wrote: Dear all I do not support the publication of this document. Defense in depth is clearly needed, implementation of algorithms are in the standardization process and therefore they may have implementation immaturity. My example is here: https://eprint.iacr.org/2026/1117 Best, Mark Tehrani Founder & CEO CyberSeQ Ltd (UK) +44 7818 712279<tel:+44%207818%20712279> [email protected]<mailto:[email protected]> https://www.cyberseq.io<https://www.cyberseq.io/> [https://ci3.googleusercontent.com/mail-sig/AIorK4zkIQmBlgzaxDagMyEtBglGj0HehZ34kIOXcsTZ2ukkOl2kjKfX9wJprX0Bx2TwDuuz7DHQKa3y7c8N] _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ TLS mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]<mailto:[email protected]>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
