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

OK. Based on Sophie's and Jacob's comments I guess I need to update my 
list of "findings".

Here what I think the discussion has outlined so far:

* The MLKEM "decaps" function provides the TLS client with an exact copy 
of the "m" bits chosen by the TLS server.
* These bits are the direct output of the RNG used by the server in the 
MLKEM "encaps" function.
* If the RNG lacks prediction resistance or backtracking resistance 
these bits can be used to predict past or future outputs of the RNG, and 
this is bad.
* RNGs that are compromised by some kind of supply chain attack will not 
provide backward and forward protection.
* The same RNG may or may not be used to derive TLS elements such as the 
Server Random bytes (depending on how implementers understand the 
public/private split discussed in annex C1 of TLS 1.3)
* Key exchanges based on Diffie-Hellman operating on number fields with 
an associative multiply function do not expose the random bits used for 
generating the key, at least not before quantum computers are generally 
available.
* The secrets used by the client and the server for key exchanges based 
on Diffie-Hellman can be retrieved by operators of quantum computers, if 
those are available.

The last but one point is an important difference. An RNG that is "good 
enough" when using classic Diffie-Hellman for key exchange may not be 
adequate for MLKEM. It is definitely worth pointing that out to 
implementers. The reasonable solution is to build a resistant RNG by 
combining the standard RNG with an adequate DRBG [citation-needed]. We 
should however note that most existing cryptographic libraries do 
combine the operating system RNG with a robust DRBG, and thus meet this 
requirement.

The last point does have some impact on the design of hybrid solutions. 
If quantum computers become widely available, the "classic" part of the 
hybrid design really need to also use an RNG that provides prediction 
resistance and backtracking resistance. This is indeed an argument for 
having such RNG part of the cryptographic library, so that all key 
exchange algorithms used by the library benefits from this resistance.

I still suggest both a simple mention of the problem in the security 
section of both MLKEM based drafts, and a somewhat longer term work on 
an RFC discussing randomness requirement for TLS and maybe other 
security functions. The first point in case some developers want to roll 
their own implementation of MLKEM, rather than use an existing library. 
The second point because the IETF does need  a replacement for RFC 4086.

-- Christian Huitema


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