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

Hi Nick,

On 7/14/26 09:36, Nick Sullivan wrote:
> Can we wrap this conversation up?

Yes, but the consensus call has ended and we do not yet have agreed text
that actually wraps up this issue.

> There are tons of potential covert channels embedded in TLS, any
> one of which could be used to extract RNG state. That's the issue
> here. The solution to this issue is at the RNG layer.

Agreed that the RNG layer matters and that TLS has more than one
possible channel. But ML-KEM adds a specific peer-recoverable value,
`m`, and FIPS 203 Appendix C documents that Kyber originally hashed `m`
to protect against flawed randomness [0].

> Adding a single hash to one element of a protocol that already has 
> multiple RNG leaks is the wrong shape for a solution to the problem 
> at hand.

It is not the whole solution. It is the right local mitigation for this
specific value and it survived three rounds of NIST PQC review only to
be removed for a reason unrelated to the hash causing a security issue. 
the removal _created_ the issue and IETF is the last stopgap against 
NIST's decision. Broader RNG/covert-channel work should also happen, but 
that does not justify leaving this draft silent when we already see that 
organizations will cite it in ways that are not even intended.

The text needed to wrap this up is small:

- cite the third-round Kyber submission [1];
- cite FIPS 203 Appendix C, where NIST documents removing `m <- H(m)` [0];
- state the FIPS 203 approved-RBG requirement [0][15][16][17];
- 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 especially when a NIST-approved DRBG and
NIST-approved entropy source are not available;
- cite Dual_EC_DRBG as the public standardized example [3][4].

That would document the assumption, explain the risk, and give
implementers useful guidance without pretending it solves every TLS RNG
issue.

There are TLS stacks that appear to be safe against this hidden
structure until ML-KEM's `m` oracle is introduced. Are you suggesting
that you want the responsibility for introducing that because the TLS
spec does not cover the issue systematically? I do not.

Kind regards,
Jacob

[0] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf
[1] https://pq-crystals.org/kyber/data/kyber-specification-
round3-20210804.pdf
[3] https://csrc.nist.gov/csrc/media/projects/crypto-standards-
development-process/documents/dualec_in_x982_and_sp800-90.pdf
[4] https://csrc.nist.gov/CSRC/media/Projects/Crypto-Standards-
Development-Process/documents/
Email_Oct%2027%202004%20Don%20Johnson%20to%20John%20Kelsey.pdf
[15] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90Ar1.pdf
[16] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90B.pdf
[17] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-90C.pdf

On 7/14/26 09:36, Nick Sullivan wrote:
> Hi all,
> 
> Can we wrap this conversation up?
> 
> There are tons of potential covert channels embedded in TLS, any
> one of which could be used to extract RNG state. That’s the issue
> here. The solution to this issue is at the RNG layer. Requiring a 
> mandatory non-keyed hash for the input of one of these potential 
> covert channels does not solve the issue overall, and it imposes an 
> unnecessary burden on applications who already implement RNG 
> discipline. Every mandated step in a protocol has a cost, and the 
> cost should be well-justified within the potential solution space
> of the problem it is intended to solve.
> 
> Adding a single hash to one element of a protocol that already has 
> multiple RNG leaks is the wrong shape for a solution to the problem 
> at hand. There have been no scenarios presented in which this 
> additional hash makes a meaningful difference without TLS also 
> having solved the overall covert channel problem already. Part of 
> building in safety systematically is understanding where the risk 
> really is, not applying band-aids to where a future risk could 
> potentially be. This proposal in particular has been debated ad 
> nauseam in multiple forums for years and the community seems to 
> agree. We should move on to solving the actual issue.
> 
> Nick
> 
> On Mon, Jul 13, 2026 at 10:54 PM Jacob Appelbaum 
> <[email protected]> wrote:
> 
>> Hi Simon,
>> 
>> On 7/13/26 17:54, Simon Josefsson wrote:
>>> 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)
>> 
>> This over complicates the solution. Your design needs additional 
>> analysis whereas simply restoring Kyber's hash requires 
>> effectively none as it already had three rounds of NIST PQC 
>> review. The removal was poorly motivated, and the modified 
>> requirements aren't going to be met for many deployments.
>> 
>>> 
>>> 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.
>>> 
>> 
>> I strongly agree with your perspective here.
>> 
>>> This aspect isn't visible on the wire, so maybe IETF isn't the 
>>> best place to develop this in.
>>> 
>> 
>> Part of the story here is that indeed, maybe the IETF isn't the 
>> best place for this topic.
>> 
>>> 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.
>>> 
>> 
>> It is unfortunate that this `m` oracle issue can actually harm 
>> hybrid constructions.
>> 
>>> 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 agree. I have a draft analysis if you are interested in 
>> discussing this topic.
>> 
>>> 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.
>> 
>> There are many but you're on the right track. My `dualec demo 
>> matrix --view scenarios` tool has ~11 at the moment. Happy to 
>> discuss those scenarios if that is of interest to you.
>> 
>> Kind regards, Jacob Appelbaum
>> 
>> 
>> 
> 

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