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

[Tanja Lange <[e-mail]>]

On Wed, Jul 08, 2026 at 01:25:50PM -0700, Benjamin Kaduk wrote:
> On Wed, Jul 08, 2026 at 10:06:07PM +0200, Tanja Lange wrote:
> > 
> > Dear Nick,
> > In ECDH when you get aG from the server and compute the shared b(aG) you don't
> > learn anything about a.
> > 
> > In ML-KEM the server encapsulates to your ephemeral public key starting from
> > some seed m. Decapsulating recovers the seed (and needs to, due to FO).
> > 
> > In the scenario that the RNG is predictable there is no difference and an
> > outside attacker gets the shared key in either scenario. Hashing the RNG output
> > before using it is at best a band aid.
> > 
> > In the Dual-EC scenario there is a big difference because ML-KEM gives you raw
> > RNG output from the server any time you open a connection to it. 
> 
> I think it may be important to highlight the distinction between the safety
> of the TLS connection and the safety of a given endpoint, especially in light
> of Dual-EC type scenarios.  It seems like the question of whether 'm' is hashed
> is really about the latter and not the former.
> 
> That is to say, the construction of the TLS handshake, with both parties
> contributing randomness that's included into the handshake transcript, gives a
> strong key for the connection as long as at least one participant is honest and
> has a strong RNG.  However, in a scenario where one endpoint has a
> Dual-EC-style compromised RNG, where seeing enough of its output would allow an
> attacker to reconstruct RNG internal state and predict subsequent output,
> exposing a lot of RNG output either in plaintext on the wire or from server to
> client (since the client initiates connections, exposure from client to server
> is a less severe vector) can lead to risk to that endpoint's security, not just
> on this connection but on future connections as well.  In the scenario under
> discussion here, an unhashed 'm' would be exposed to the client, thus potentially
> exposing server RNG state to the client but not to a passive observer.
> 
> However ... is it really plausible that the ML-KEM 'm' would use a compromised
> RNG but not the (plaintext on the wire) ServerHello.Random?  If they use the
> same RNG then it seems the incremental risk to a server with compromised RNG
> from using ML-KEM is zero, because ServerHello.Random already leads to an
> equivalent exposure (of 32 bytes of RNG output).
> 
See, e.g., Botan
	https://github.com/randombit/botan/blob/master/src/lib/tls/tls_policy.h

      /**
       * Hash the RNG output for the client/server hello random. This is a
       * pre-caution
       * to avoid writing "raw" RNG output to the wire.
       *
       * There's not normally a reason to disable this, except when
       * deterministic output
       * is required for testing.
       *
       * Default: true
       */

their ML-KEM version, true to spec, does not hash the RNG
	https://github.com/randombit/botan/blob/master/src/lib/pubkey/kyber/ml_kem/ml_kem_impl.cpp

All the best
	Tanja