Re: [TLS] Extended random is NSA backdoor

[Nico Williams <[e-mail]>]

On Mon, Mar 31, 2014 at 9:02 PM, Watson Ladd <[e-mail]> wrote:
> On Mon, Mar 31, 2014 at 5:46 PM, Nico Williams <[e-mail]> wrote:
>> On Mon, Mar 31, 2014 at 2:12 PM, Russ Housley <[e-mail]> wrote:
>>> [...]
>>
>> Under no circumstance does sending more nonce bits help palliate a
>> weak RNG.  On the contrary, doing so can only make the sender more
>> susceptible to attack.  In 2006 we would all have understood this.
>
> That's why these remained I-Ds.

I didn't do the necessary list archive-ology.  Good to know that my
supposition was right.

>> Now, the I-D in question are very explicit as to motivation:
>>
>>    The United States Department of Defense has requested a TLS mode
>>    which allows the use of longer public randomness values for use with
>>    high security level cipher suites like those specified in Suite B
>>    [I-D.rescorla-tls-suiteb].  The rationale for this as stated by DoD
>>    is that the public randomness for each side should be at least twice
>>    as long as the security level for cryptographic parity, which makes
>>    the 224 bits of randomness provided by the current TLS random values
>>    insufficient.
>>
>> That's not likely to have raised eyebrows much in 2006 -- that is
>> true.  Even with knowledge of backdoored RNG designs it might not now
>> (because that's a local problem now as ever).
>
> Huh? Even if the RNG is perfectly fine, I don't see what adding more
> random information in to the master secret derivation does. That
> motivation was questioned in 2006 because it doesn't make any sense.
> The reason server random and client random exist is to avoid replay
> attacks, and 32 bytes is wildly overkill for this. They don't add
> anything to the difficulty for an attacker. It's a completely
> meaningless rationale.

For me the main problem with sending more nonce bytes is that it
increases the bandwidth of a covert channel -- a more general case of
making weak RNGs more susceptible to attack.  But it seems reasonable
_at first glance_ (which is what I meant above) to say that to get X
bits of security you need a cipher with X bits of key, PK algorithms
with X bits equivalent security, and X bits of nonce from each party.

> The RFC permitting adding extra data into master secret derivation was
> actually motivated: one would ideally hash identities in, as was
> discovered very recently. But it doesn't take the extra step of
> actually fixing the issues, which we still have to do.

Or channel binding.  But one need not send the channel binding data
when doing channel binding!

Nico
--