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

On Wed, Jul 08, 2026 at 11:22:54PM +0300, Markku-Juhani O. Saarinen wrote:
> On Wed, Jul 8, 2026 at 11:08 PM Tanja Lange <[email protected]> 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.
> 
> 
> Hi Tanja,
> 
> You know, this is a TLS draft. In a TLS 1.3 handshake the server responds to a
> ClientHello with a ServerHello.random which is 32 random bytes from the
> Server's RNG. ( Unless HelloRetryRequest is issued. )
> 
> Cheers,
> -markku
> 
Dear Markku,
Thank you. I'm aware of the context. 

In our Dual-EC paper (earlier TLS versions) we got the raw Dual-EC output from
"session ID" and "server random", see
	https://projectbullrun.org/dual-ec/index.html
for more details than you're asking for.

Protecting against such issues is why there is RFC 8937. 
	https://www.rfc-editor.org/rfc/rfc8937.html

If you implement your TLS 1.3 server with the best precautions you don't drop
raw randomness at the protocol level.  

All the best
	Tanja

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