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]
