[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

[John Mattsson <[e-mail]>]

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 <[e-mail]>
Date: Tuesday, 7 July 2026 at 18:36
To: Mark Tehrani <[e-mail]>
Cc: [e-mail] <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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)
[phone]<tel:+44%207818%20712279>
[e-mail]
https://www.cyberseq.io<https://www.cyberseq.io/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4zkIQmBlgzaxDagMyEtBglGj0HehZ34kIOXcsTZ2ukkOl2kjKfX9wJprX0Bx2TwDuuz7DHQKa3y7c8N]
_______________________________________________
TLS mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>