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]
