Markku-Juhani O. Saarinen wrote: >I think a more appropriate general recommendation is to require strong forward >and backward secrecy for *all* random bits used in TLS, not just those in >ML-KEM. If the threat model is the leakage of an entropy source (or some >upstream random bit stream), then one should be consistent about blocking it >everywhere.
I agree with this. I welcome this discussion on improving CSPRNG guidance for IETF protocols. Weak random number generation used to be a major problem, and it probably still is, although it is much easier to get it right today thanks to robust operating-system RNGs such as Linux /dev/random. Regarding Jakob Appelbaum's suggested text, I agree that wording along the lines of "the m value is recoverable by the decapsulating peer" should be added to draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-mlkem, and likely to future IETF KEM specifications as well. I remain skeptical of the recommendation hash m ← H(m). A well-designed CSPRNG should already apply a one-way function as part of its output generation. And such hashing only protects against a relatively narrow class of attacker-controlled CSPRNGs. As MJOS put it, it is a gate without a fence. I think this discussion would be better held in a broader IETF context rather than within individual TLS KEM drafts. The best outcome would be for an IETF working group to produce an RFC4086bis that other RFCs could reference. Such an update should point implementers to existing standards, such as relevant NIST publications, and widely deployed implementations such as Linux /dev/random. RFC 4086 is a good document on the principles of randomness, but it is no longer a good implementation manual for someone writing a TLS stack in 2026. I also do not think the NIST specifications are perfectly suitable. They are focused on cryptographic modules and do not ephasize essential principles such as combining multiple entropy sources and continuously incorporating fresh entropy into the RNG state. Cheers, John Preuß Mattson From: Markku-Juhani O. Saarinen <[email protected]> Date: Sunday, 12 July 2026 at 09:09 To: Jacob Appelbaum <[email protected]> Cc: Tanja Lange <[email protected]>; [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08) On Sat, Jul 11, 2026 at 11:14 PM Jacob Appelbaum <[email protected]<mailto:[email protected]>> wrote: > I would suggest something along these lines: Hi Jacob, If something like this is added, I recommend using more precise technical language and adding appropriate references to clarify key concepts related to random bit generation. I also consider the recommendation as unnecessarily weak from a security perspective. I'd say this section is more or less compatible with what the "post-Snowden" NIST standards already require. > FIPS 203 requires that ML-KEM.KeyGen and ML-KEM.Encaps use fresh > randomness generated by a NIST-approved randomness source. Since it is an American standard, one has to dive into NIST terminology a bit to read FIPS 203 (recall that FIPS specs are primarily written for implementors of FIPS cryptographic modules, even though others use them as well.) FIPS 203 actually states that an approved *RBG* must be used. An RBG and a randomness source (a.k.a. an entropy source -- as defined in SP 800-90B https://doi.org/10.6028/NIST.SP.800-90B ) are different concepts. The standards are very clear that a randomness/entropy source alone is not an RBG. Basically, in the FIPS world, a randomness source is a necessary component of an RBG, but additional conditioning and processing steps are required to build an approved RBG out of it. (Well, in RBG1 is a special case where the randomness source can be a separate module.) For information about RBGs, see SP 800-90C: https://doi.org/10.6028/NIST.SP.800-90C So in the world of FIPS cryptographic modules, the hash of shame would always be hashing a SHA2 or AES-CTR output (with both forward and backward secrecy). Indeed, if someone were to use non-compliant random, additional steps may be required. > Implementations should not use raw primary RNG output directly as > the ML-KEM `m` value, because that value is recoverable by the > Decapsulating peer. Some confusion here seems to stem from the use of the term "RNG", which is much more vague. I would avoid this term altogether. It is true that the "RNG" term is used in European Common Criteria (AIS 20/31) schemes; there a relevant protection profile should require a DRG (deterministic generator) with strong backward secrecy and forward secrecy (DRG.2, DRG.3, DRG.4). But perhaps CC assurance terminology would be going a bit too far for an IETF spec. > Implementations should use a properly separated > RBG/DRBG and/or a context-bound derivation for ML-KEM encapsulation > randomness, and as the original design of Kyber did `m <- H(m)`, > the `m` value should be hashed by a suitable secure cryptographic > hash function. This is a defense-in-depth measure against > hidden-structure RNG failures, including Dual_EC_DRBG-shaped > kleptographic attacks. Just requiring the "hash of shame" (which is what we called it in 2023, in reference to NIST's Dual_EC_DRBG blunder) is like a gate without a fence around it. I think a more appropriate general recommendation is to require strong forward and backward secrecy for *all* random bits used in TLS, not just those in ML-KEM. If the threat model is the leakage of an entropy source (or some upstream random bit stream), then one should be consistent about blocking it everywhere. Chers, -markku
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
