You are missing the fact that implementing an algorithm and having it offered at the session establishment are two very different things.
— Regards, Uri
Secure Resilient Systems and Technologies MIT Lincoln Laboratory
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
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
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:
Sophie, David, am I missing something? Nadim Kobeissi Symbolic Software • https://symbolic.software 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.
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
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.
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.
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.
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:
Best,
_______________________________________________
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]
|
smime.p7s