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

["Salz, Rich" <[e-mail]>]

On 7/16/26, 9:57 AM, "Salz, Rich" <rsalz=[e-mail]> wrote:

  *
think it would be better as a separate RFC.  Perhaps collaborate with Don Eastlake


  *
Changing the current drafts is a mistake.

I received a couple of emails that made me realize I was over-zealous in trimming down.  It was in response to Nadim’s message below.

The draft is about using ML-KEM, not about using something based on Kyber. If you want to write about RNG, Don is looking at drafting a successor to 4086 so contact him. If you want to write a draft about how to use Kyber, that’s a separate document.

On 7/16/26, 6:41 AM, "Nadim Kobeissi" <[e-mail]> wrote:
Fair enough. Here is a start on a minimal list I think the text needs to
cover:

- cite the third-round Kyber submission;
- cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
- state the FIPS 203 approved-RBG requirement;
- state that `m` is recovered by the decapsulating peer;
- recommend restoring Kyber's hashing of `m` as defense in depth against
 hidden-structure RBG failures;
- cite Dual_EC_DRBG as the public standardized example.
- quote the relevant part(s) of FIPS 203 C.1

I can turn that into concrete PR text. Before doing that, I would like
to understand whether the WG is open to text at this level of
specificity, or whether the only text people are willing to consider is
a generic RNG sentence. If the generic sentence is the only thing on
offer, I would request someone else draft it and I am happy to give
feedback.

This is incredibly unreasonable to the point of being disruptive. You are basically demanding that the IETF undermine the entire point of NIST standardization, on top of all your baseless insinuations about personal motivations of those who disagree with you and your unreasonable threat modeling when thinking about the entire question of `m` in ML-KEM and sources of randomness.

At what point does this become pure concern trolling? I regret even making the effort to catch up on these discussions.

Nadim Kobeissi
Symbolic Software • https://symbolic.software

On 15 Jul 2026, at 5:25 AM, Jacob Appelbaum <[e-mail]> wrote:

Hi Paul,

On 7/14/26 03:17, Paul Wouters wrote:
The draft does not define crypto, it normatively references some crypto. It cannot both normatively reference it and modify it to make its own.

I do not think that follows and while it does not define the code point,
it does define how the cryptography is used in TLS including Security
Considerations. A TLS draft can normatively reference FIPS
203 and still explain the relevant assumptions and tradeoffs in Security
Considerations.

FIPS 203 Appendix C itself documents that Kyber originally hashed `m`
and that NIST removed that step because ML-KEM requires approved
randomness generation. The TLS draft should say that plainly.

Namely, quote the entirety of C.1:
```
C.1 Differences Between CRYSTALS-Kyber and FIPS 203 Initial Pub-
lic Draft
• In the third-round specification [4], the shared secret key was
treated as a variable-length
value whose length depended on how it would be used in the relevant
application. In this
specification, the length of the shared secret key is fixed to 256 bits.
It can be used directly
in applications as a symmetric key, or symmetric keys can be derived
from it, as specified
in Section 3.3.
• The ML-KEM.Encaps and ML-KEM.Decaps algorithms in this specification
use a different
variant of the Fujisaki-Okamoto transform (see [24, 25]) than the third-
round specifica-
tion [4]. Specifically, ML-KEM.Encaps no longer includes a hash of the
ciphertext in the
derivation of the shared secret, and ML-KEM.Decaps has been adjusted to
match this
change.
• In the third-round specification [4], the initial randomness 𝑚 in the
ML-KEM.Encaps algo-
rithm was first hashed before being used. Specifically, between lines 1
and 2 in Algorithm
20, there was an additional step that performed the operation 𝑚 ← 𝐻(𝑚).
The purpose
of this step was to safeguard against the use of flawed randomness
generation processes.
As this standard requires the use of NIST-approved randomness
generation, this step is
unnecessary and is not performed in ML-KEM.
• This specification includes explicit input checking steps that were
not part of the third-round
specification [4]. For example, ML-KEM.Encaps requires that the byte
array containing the
encapsulation key correctly decodes to an array of integers modulo 𝑞
without any modular
reductions.
```

Alternatively highlight this part of C.1 from FIPS 203:
```
• In the third-round specification [4], the initial randomness 𝑚 in the
ML-KEM.Encaps algorithm was first hashed before being used.
Specifically, between lines 1 and 2 in Algorithm 20, there was an
additional step that performed the operation 𝑚 ← 𝐻(𝑚).
The purpose of this step was to safeguard against the use of flawed
randomness generation processes.
As this standard requires the use of NIST-approved randomness
generation, this step is unnecessary and is not performed in ML-KEM.
```

Then I would suggest describing the total set of requirements from
FIPS203 or giving advice that `𝑚 ← 𝐻(𝑚)` should be used if the NIST-
approved randomness generation requirement is not met. I would also
probably want to say that this change by NIST is not robust against a
failure of their DRBG, nor is it robust against providing an oracle, the
m-oracle, I suppose which may be queries over TLS and/or used to sample
the DRBG outputs directly.

The IETF cannot modify things that are an external normative reference. MLKEM is what NIST defined, not what you are trying to build now.

I am not asking the draft to pretend that NIST defined something else. I
am asking the draft to document the consequence of what NIST defined:
without the approved-RBG assumption, the rationale for removing Kyber's
hash over `m` no longer holds.

If the draft does not restore `m <- H(m)`, then it should at least state
the FIPS 203 approved-RBG requirement and the fact that `m` is recovered
by the decapsulating peer.

This matters in practice. Many implementations will use `os.urandom`,
`/dev/urandom`, `/dev/random`, `/dev/hwrng`, `getentropy()`,
`getrandom()`, or another platform or library interface. Those may be
excellent choices in a well-designed system, but they are not
automatically the same thing as a NIST-approved RBG satisfying the FIPS
203 condition used to justify removing the hash.

One way to make the dependency clear is to think of the real requirement
as something closer to:

- ML-KEM-512-Hash_DRBG
- ML-KEM-512-HMAC_DRBG
- ML-KEM-512-CTR_DRBG
- ML-KEM-768-Hash_DRBG
- ML-KEM-768-HMAC_DRBG
- ML-KEM-768-CTR_DRBG
- ML-KEM-1024-Hash_DRBG
- ML-KEM-1024-HMAC_DRBG
- ML-KEM-1024-CTR_DRBG

Listing that is a concrete suggestion for the text but I do not feel
strongly about where it goes in the text.

These are shorthand examples names and I am not suggesting new algorithm
names. The point is that FIPS 203 relies on an approved RBG of
appropriate strength. If an implementation omits that part, the reason
NIST gave for removing Kyber's hash over `m` no longer applies.

This answer circles the answer by not distinguishing between the RNG issue and any other issues. You still did not answer the question.

My answer is: not as-is.

I am open to text that is applied consistently to both ML-KEM drafts.
But a generic sentence about "use a good RNG" does not address the
specific FIPS 203 requirement, nor the protocol consequence that `m` is
recovered by the decapsulating peer.

This does answer it better, it seems your answer is "no".

No. My answer is not "no no matter what." My answer is "not as-is"
because your suggestion is not even a full suggestion where I could just
say yes.

Which is the same issue as the "m concern".

Related, not identical. The approved-RBG dependency is the assumption
and a requirement. The `m` concern is the protocol consequence when that
assumption is not met, or when it is hidden from implementers.

For one, this is not different between pure and hybrid, yet you have no issue with the hybrid Security Considerations?

I do have an issue with the hybrid draft on this point. The same
Appendix C tradeoff and the same `m` issue apply there too. Hybrid helps
against some failures, but it does not automatically help if the same
recoverable RBG lineage later feeds the classical ephemeral scalar. The
removal of the hash leads to some fun issues and not only with
Dual_EC_DRBG but also.

Second, it seems as people said, TLS already provides a huge amount of options and parameters to use as a covert channel.

Agreed. That is why broader covert-channel work is also needed. But that
does not justify leaving this specific ML-KEM issue unexplained in these
drafts. It is a bit annoying to go back and forth between each layer
where a different layer is used as a reason to ignore the issues in the
layer under discussion.

What would a TLS implementer need to know when it uses a cryptographic library to support a new cipher, whether hybrid or pure?

They need to know at least:

1. FIPS 203 requires ML-KEM randomness from a NIST-approved RBG.
2. `m` is recovered by the decapsulating peer.
3. Kyber originally hashed `m` to protect against flawed randomness.
4. Dual_EC_DRBG is the public standardized example of a
  hidden-structure RBG failure.
5. Hybrid does not automatically help if the same recovered RBG lineage
  later feeds the classical ephemeral scalar.
6. This change was an intentional choice by NIST and the IETF does not
agree with this change as it cannot mandiate the use of a specific DRBG.

First, it seems most of the items you just listed are the same item, and basically you want it to say "don't use pure, use hybrid instead",

That is not my position. The `m` issue applies to ML-KEM in both the
standalone and hybrid drafts. My concern is that the drafts do not
clearly state the FIPS 203 randomness requirement, the Appendix C
tradeoff, or the peer-recoverability of `m`.

Second, if you want this document to proceed with some newly added text, it is up to you to propose such text to the WG.

Fair enough. Here is a start on a minimal list I think the text needs to
cover:

- cite the third-round Kyber submission;
- cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)`;
- state the FIPS 203 approved-RBG requirement;
- state that `m` is recovered by the decapsulating peer;
- recommend restoring Kyber's hashing of `m` as defense in depth against
 hidden-structure RBG failures;
- cite Dual_EC_DRBG as the public standardized example.
- quote the relevant part(s) of FIPS 203 C.1

I can turn that into concrete PR text. Before doing that, I would like
to understand whether the WG is open to text at this level of
specificity, or whether the only text people are willing to consider is
a generic RNG sentence. If the generic sentence is the only thing on
offer, I would request someone else draft it and I am happy to give
feedback.

So "pure" is what the IETF is using now for consistency.

Point of clarification: did you mean ML-KEM or ML-KEM-WITH-A-DRBG when
you said pure in that context?

The current text is the consensus proposal of two years of talk within the TLS WG.

The WGLC for draft-ietf-tls-mlkem-08 has ended, but I have not seen a
declaration of consensus. We also do not yet have agreed text that
addresses the FIPS 203 randomness requirement or Appendix C tradeoff.

I am not aware of any technical concerns.

Then let us test that with concrete text. The concern is not merely a
different risk preference. It is that NIST's rationale for removing
Kyber's hash depends on an approved-RBG requirement that the TLS draft
does not clearly carry forward.

So to me that makes it clear that in practise, your answer will remain "no".

No. If the drafts clearly document the FIPS 203 approved-RBG assumption,
the peer-recoverability of `m`, and the reason Kyber hashed `m`, I am
open to changing my view. If the text is only "use a good RNG", then no,
that is not enough.

As I explained above, you providing concrete text additions/ modifications will help determine consensus of your suggestions

I take that point. I can provide concrete text. My concern is that the
Last Call has already closed, so I am asking how the chairs intend to
handle new text if there is support for it.

Rough consensus is achieved when all issues are addressed, but not necessarily accommodated.

Agreed. My position is that the issue has not yet been addressed. It has
mostly been reframed as a generic RNG problem, which misses the specific
Appendix C tradeoff and the `m` oracle.

The one thing that is clear to me is that what you are asking for is basically changing the normative reference.

I reject that framing. Security Considerations routinely explain
assumptions, risks, and implementation guidance around normative
references. That is what I am asking for here.

The normative reference itself discusses Kyber and ML-KEM together in
Appendix C. Quoting and explaining that text is not changing the
normative reference. It is making the reference intelligible to TLS
implementers.

Adding a generic statement about RNG is the only compromise possible.

I do not agree. A meaningful compromise would state the actual FIPS 203
approved-RBG requirement, state that `m` is recovered by the
decapsulating peer, and explain that Kyber originally hashed `m` to
protect against flawed randomness.

If that is not good enough for you, your only option is to voice that you are against publication -

That is not my only option. I am currently against publication as-is,
but I am also trying to find text that could resolve the issue.

and to be consistent, I would expect you to be against publication of both the pure and hybrid mlkem drafts, as they are identical in that part, using the same normative reference of NIST.

I am against omitting the relevant FIPS 203 Appendix C details in both
drafts. I am against omitting advice to implementers who are not running
a FIPS-validated stack. I am against omitting the fact that `m` is
available to the decapsulating peer. And I am against omitting the
historical example of Dual_EC_DRBG when discussing hidden-structure RBG
failures.

A suggestion of generic RNG sentence that is not a concrete suggestion
is not enough, no. Text that states the FIPS 203 approved-RBG
requirement, the peer-recoverability of `m`, and the reason Kyber hashed
`m` would be meaningful.

Kind regards,
Jacob Appelbaum

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