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 *accidentall*y 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 <john.mattsson= [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]> > *Date: *Tuesday, 7 July 2026 at 18:36 > *To: *Mark Tehrani <[email protected]> > *Cc: *[email protected] <[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]> > 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 <+44%207818%20712279> > [email protected] > https://www.cyberseq.io > _______________________________________________ > 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] > -- Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected]
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
