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

On Thu, Jul 09, 2026 at 08:17:36AM +0200, Tanja Lange wrote:
> 
> On Wed, Jul 08, 2026 at 01:25:50PM -0700, Benjamin Kaduk wrote:
> > 
> > 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://urldefense.com/v3/__https://github.com/randombit/botan/blob/master/src/lib/tls/tls_policy.h__;!!GjvTz_vk!SPz_kT_rGAVH4ZaUhKlgChenbkLtKaxRKPQ0r3qIIUjwNT6F6y6JlG_5QrFDNaPI0223gTgA3_av0b7BfA$ 
> 
>       /**
>        * 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://urldefense.com/v3/__https://github.com/randombit/botan/blob/master/src/lib/pubkey/kyber/ml_kem/ml_kem_impl.cpp__;!!GjvTz_vk!SPz_kT_rGAVH4ZaUhKlgChenbkLtKaxRKPQ0r3qIIUjwNT6F6y6JlG_5QrFDNaPI0223gTgA3_ZIxUHrkQ$ 

Ok, thanks for the reference!
I think I remember some discussion in the lead up to RFC 8446 about having
separate "public" and "private" RNGs as a possible option but that did not make
it into the final RFC (instead we have Appendix C's guidance to just use a good
RNG everywhere), so I guess I had internalized the result of that discussion as
"best practices".

-Ben

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]