[TLS] Re: RNG state should not cascade across TLS connection s

Simon Josefsson <[email protected]> Mon, 13 Jul 2026 17:54:16 +0200

Newsgroups	gmane.ietf.tls
Message-ID	<[email protected]>

John Mattsson <[email protected]> writes:

>>Redirecting to talk about entropy is unhelpful.
>
> I don't think I mentioned entropy, but entropy is very useful. As
> noted, m = H(m, independent entropy), where the entropy comes from any
> source other than the attacker-controlled RNG, thwarts a much larger
> class of attacks than m = H(m).
>
> I don't think it is helpful to focus on Dual_EC_DRBG except as a
> historical example. I think the discussion should focus on
> attacker-controlled RNGs in general.

This is a good point -- and we could design a TLS-specific RNG
recommendation that recommends using a per-session randomness source as:

rng = SHAKE(OS-rng, session-specific-symmetric-key ||
                    full-transcript-of-session)

It is easy to dismiss this class of problem by saying "go fix your PRNG"
but I believe that is naive and suggest people aren't familiar with the
history of compromised RNGs and what kind of attacks they enable.

This aspect isn't visible on the wire, so maybe IETF isn't the best
place to develop this in.

Cryptography isn't the only reasonable method to obtain security:
defense-in-depth is another strategy.  It is one motivation behind
hybrid KEMs, which we fortunately have deployed for good reasons.

One way to mitigate this entire class of problems is to do covert
channel analysis.  If your protocol enables a covert channel, it has a
problem.  The IETF historically haven't worried a lot about covert
channels as a protocol vulnerability, but perhaps it is time to change.

I believe TLS has some concerns in this area (e.g., the 32-byte
client/server 'random' fields), but ML-KEM increases the attack surface.

/Simon

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

signature.asc (application/pgp-signature, 1.2 KB)