[TLS] RNG state should not cascade across TLS connections

[Nick Sullivan <[e-mail]>]

Hi TLSWG,

Pulling this up from a deep subthread so it doesn't get lost. There are two
distinct attacks against a state-recoverable DRBG worth naming separately.
Both work the same way: one exposure of RNG output lets the attacker walk
state forward and predict every subsequent draw from the same DRBG.

Scenario 1: passive eavesdropper. Recovery vector is a wire nonce like
ServerHello.Random. Applies to both KEMs and DH.

Scenario 2: adversary client. Recovery vector is `m`, which the adversary
recovers by decapsulating the server's ciphertext. Applies to KEMs only,
not to DH.

Scenario 2 applies to KEMs but not DH because the FO transform requires the
decapsulator to recover the encapsulator's `m`. DH's peer sees only `a·G`
behind ECDLP. No raw randomness ever crosses. This is a KEM-abstraction
property, not ML-KEM-specific.

The attacker in Scenario 2 needs to make enough connections to your server
to accumulate the `m` values needed to recover DRBG state. For a
Dual_EC-shape DRBG a single 32-byte `m` is enough. Other state-recoverable
constructions may require more.

What both scenarios share: once DRBG state is recovered, the attacker
passively decrypts every subsequent connection to that server from just the
network flow. Every user, every session, decrypted from the wire without
touching the server again. This continues until the DRBG reseeds. For a
stack that does not explicitly reseed, that means for the life of the
process. Predicted `m` plus observed `ek` gives the KEM shared secret
directly. This is the mechanism behind the 2015 Juniper ScreenOS Dual_EC
incident, which put passive VPN decryption within reach of whoever held the
trapdoor to the substituted Q constant. Nothing about ML-KEM makes it
immune to the same mechanism. That cascade is the actual concern.

How the server arranges its DRBGs determines which scenario the attacker
would take. Under a shared DRBG (ServerHello.Random and `m` from the same
source), Scenario 1 is available to any passive observer without an active
connection. This is Ben Kaduk's point. Splitting the DRBGs closes Scenario
1 but leaves Scenario 2 as the primary path against the DRBG that feeds `m`.

David Benjamin has argued that the fix belongs at the RNG layer, not at
ML-KEM or inside TLS. That seems right. Use a DRBG whose output does not
reveal its state (duh), and which provides post-compromise recovery (via
reseeding from fresh entropy by design, or via per-connection
reinitialization at the caller). Either way, any state exposure is bounded
in time. This approach is KEM-generic and applies beyond ML-KEM.

Runnable PoCs for both scenarios are trivial to construct.

Let me know if I have this summary right.

Nick