Hi Sophie, Thank you for your helpful reply!
Nadim Kobeissi Symbolic Software • https://symbolic.software > On 7 Jul 2026, at 9:29 PM, Sophie Schmieg <[email protected]> wrote: > > Note that implementing something (whether it is in Chrome or in Microsoft's > libraries) does not mean including it in their set of options. As stated > before somewhere, any X25519MLKEM768 implementation by necessity includes an > implementation of ML-KEM. From there it is only a little bit of glue code to > have this key exchange algorithm implemented. However, the default > configuration would need to be overwritten for the algorithm to be included > in actual handshakes. At least for Chrome this requires an explicit flag to > be set. Again, it takes conscious action, by multiple parties, to > intentionally include pure ML-KEM 1024 in a handshake. It takes further > conscious action to prefer it over X25519MLKEM768. This will not happen by > accident, and a RECOMMENDED = N RFC is not going to make it happen. > > On Tue, Jul 7, 2026 at 12:17 PM Nadim Kobeissi <[email protected]> > wrote: >> Dear Sophie, >> >> I must admit that I was very surprised to see you write the following: >> >> > 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 >> >> Sophie, your own coworker at Google, David Adrian (a product manager on >> Google Chrome) has *repeatedly* expressed on this list that Google Chrome, >> the world’s most popular browser, has (presumably with his encouragement) >> already implemented draft-ietf-tls-mlkem, without even waiting for the >> results of this consensus call. >> >> He most recently expressed this here: >> >> https://mailarchive.ietf.org/arch/msg/tls/SnOQ0cEnlE591Ttwfgjyj4sAui0/ >> >> Sophie, David, am I missing something? >> >> Nadim Kobeissi >> Symbolic Software • https://symbolic.software <https://symbolic.software/> >> >>> On 7 Jul 2026, at 8:53 PM, Sophie Schmieg >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> >>> 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/> >>>> >>>> _______________________________________________ >>>> 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] <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]
