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

Hi John and Markku,

On 7/12/26 10:06, John Mattsson wrote:
> 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.

Thank you. I agree that this text belongs in those drafts, at a
minimum. It is also _extremely_ obscure and not super helpful to an
implementer unless we can explain how to make it as safe as the original
Kyber design. We are in luck! We know how to make it as safe as the
original Kyber design!

> 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.

It is not fair to characterize as a recommendation John. It is raising
that NIST made a mistake in removing the hash from the original design
of Kyber and not accepting that mistake as well motivated is part of
what we should be doing in this working group. Why are you not skeptical
of the hash's removal?

We agree that a well-designed RNG/RBG/DRBG should already provide strong
forward and backward secrecy. We also agree that broader guidance for
all TLS random bits would be useful.

But that is not a reason to leave this specific problem in place.

Restoring Kyber's original `m <- H(m)` is safe, simple, and sufficient
to close this specific decapsulator-visible raw-randomness oracle. It is
not a complete RBG architecture, but it does not need to be one. It
destroys the hidden structure that this class of attack needs.

It is possible to make a single query to a server that has a
kleptographic backdoor of this kind and then that Adversary may be able 
to decrypt all other subsequent traffic passively until reseeding. There 
are some caveats but the hash blocks it.

Due to the lack of defense-in-depth in many security protocols, work is
needed to address this class of issues. So we do agree that _adding_
protections into the TLS spec is a good idea; we can observe ad-hoc
attempts to address these issues in many TLS libraries. Some 
implementations don't get it right. Some do a great job. Some don't even 
understand it is an area to consider.

Meanwhile coincidentally, TLS 1.3 just went out and I would observe that 
it isn't systematically addressing this class of issues.

So lets keep the focus on ML-KEM and people who are worried can also use 
a competent implementation that handles this class of issues. ML-KEM as 
promoted by IETF should not make those careful implementations weaker.

> 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.

An RFC4086bis effort would probably be useful, and I would likely 
support it. But it should not be a reason to move this discussion away 
from the tls working group or to delay the minimal fix in the TLS drafts 
currently under discussion. I agree with Nick here, we don't want to 
create a hard dependency on CFRG or frankly any other group. We're 
discussing this draft now, and if it isn't withdrawn, I surely hope that 
we can settle this completely obvious mistake by NIST.

The immediate TLS facts are simple:

- ML-KEM `m` is recoverable by the decapsulating peer.
- TLS uses ML-KEM in exactly that peer-facing context.
- Kyber had a hash over `m`; ML-KEM removed it.
- Restoring that hash closes this specific oracle without changing the
   wire format.

So yes, broader CSPRNG guidance belongs somewhere broader. But the
TLS-specific consequence belongs in the TLS drafts you named:
draft-ietf-tls-ecdhe-mlkem and draft-ietf-tls-mlkem, and likely future
IETF KEM specifications as well.

I would suggest text no weaker than:

   The internal ML-KEM value `m` is recoverable by the decapsulating
   peer. Implementations MUST NOT use raw primary random bit streams
   directly as `m` . The value used as `m` MUST be derived with suitable
   cryptographic hashing or an equivalently strong context-bound
   derivation before encapsulation to destroy any hidden structure as
   the original Kyber design: `m <- H(m)`.

That keeps the TLS guidance simple and does not require resolving the
entire RFC4086bis discussion first. It isn't perfect but it survived 
three rounds of NIST's PQC process until NIST incorrectly decided to 
remove it against many reasonable arguments.

Kind regards,
Jacob

> 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]