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]
