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

Hi Paul,

On 7/13/26 15:03, Paul Wouters wrote:
> On Sun, 12 Jul 2026, Stephen Farrell wrote:
> 
>> The above seems sensible. IIRC 4086 was AD sponsored, which'd have 
>> been my initial take on how to process a successor, but it's quite 
>> arguable that a WG could be better now, esp since we have new
>> fancy crypto here and there (e.g. ppm) where some new issues might
>> arise. A WG is probably more likely to result in such issues being
>> thought through.
> 
> A year (or two?) ago, the SEC ADs looked at having some people
> create a 4086bis, as we kept running into drafts that would
> reference 4086 but it was so outdated it was better not to reference
> that but instead say "use your OS secure random source". Only the
> SSHM WG purposefully did not include a reference to it (and I
> believe they wrote a few lines of text in their RFCs basically
> saying "just use your OS RNG, these are better that your homegrown
> stuff". The SEC ADs at the time didn't feel we got a good segment of
> volunteers with modern OS knowledge together for them to write a
> 4086bis, so yes perhaps a WG would be a better approach.

I agree that a 4086bis effort would be useful, and I would support it.

> That said, a 4086bis would mostly target people who are not very 
> familiar with cryptographic requirements. I feel any algorithm
> document specification would be implemented by people who should
> know enough on cryptographically strong random sources to not need
> such sentences, and I'm perfectly fine not adding anything to either
> mlkem drafts.

I disagree. This is not ordinary "use a good random source" guidance.

The issue is specific and concrete: ML-KEM's internal `m` is recoverable
by the decapsulating peer. Kyber hashed `m`. FIPS 203 removed that hash.
In TLS, that change means a peer can receive a decapsulator-visible
sample derived directly from the other side's randomness.

That belongs in the TLS drafts.

> I do think this discussion is more a red herring against pure mlkem
> than a real argument for text being really needed into these drafts.
> But provided both drafts get equal treatment getting the same
> sentence(s) added on randomness to avoid conspiracy theories and bad
> faith citations of the differences, I think this is okay to do.
> Which does means we would have to do this quickly as the hybrid
> mlkem is now in the RFC Editor queue.

It is not a red herring against pure ML-KEM. ML-KEM is not broken. The
issue is the removal of Kyber's defense-in-depth hash over `m`.

I also do not accept the "conspiracy theories" framing. The relevant
history is documented: Dual_EC_DRBG, Extended Random, Juniper/ScreenOS,
and BULLRUN are part of the public record. That history is why this
class of concern is taken seriously. The technical point stands on its
own: hashing `m` destroys structure that raw `m` may preserve.

Dual_EC_DRBG is the obvious historical example of exploitable hidden
structure. Juniper's ScreenOS/IKE nonce history is a reminder that this
class of issue is not confined to ML-KEM. It can arise whenever
protocol-visible or peer-recoverable values carry structured
random-generator output.

So yes, we should systematically look for this pattern in TLS and other
IETF security protocols. But that broader review is not a reason to
leave the ML-KEM case unfixed.

I agree that both ML-KEM drafts should get equal treatment. The equal
treatment should be to restore the Kyber hash in both drafts. If someone
wants to resist restoring the hash, the question should be technical:
what is the concrete security reason to keep the NIST change rather than
restore Kyber's original defense-in-depth step?

A direct fix would be:

   For ML-KEM in TLS, the encapsulation input `m` MUST be derived as
   `m <- H(m)` as in Kyber, or by an equivalent context-bound hash
   derivation that destroys structure in raw RBG output before
   encapsulation. Dual_EC_DRBG is an example of the hidden-structure
   failure mode this is intended to mitigate. Similar issues should be
   reviewed systematically for other TLS and IETF protocol values that
   are protocol-visible or peer-recoverable.

That should be applied at least to draft-ietf-tls-ecdhe-mlkem and
draft-ietf-tls-mlkem.

Kind regards,
Jacob


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

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