Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Colm MacCárthaigh <[e-mail]>]

On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell <[e-mail]>
wrote:

> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>

I think the fix for this is really at the application level; if you want
defense-in-depth against PRNG problems, it's probably best to use separate
RNG instances for public data (e.g. client_random, server_random,
explicit_IV) and for secret data (keys) so that a leak in the public data
doesn't compromise the private one. We do this in s2n, and I think
BouncyCastle does it too.

A protocol level fix probably isn't as helpful because the attacker can
make more connections and collect more data to derive more and more
information about the RNG state anyway.

-- 
Colm