Re: [TLS] New drafts: adding input to the TLS master secret

[Paul Hoffman <[e-mail]>]

At 7:50 PM -0600 2/2/10, Marsh Ray wrote:
>Paul Hoffman wrote:
>>
>> This proposed protocol change is only relevant to scenarios where
>> there is a cryptographic reason to mix inherently non-sensitive data
>> passed before the change_cipher_spec message into the master secret.
>
>I don't get it. (Sorry I am a little dense sometimes)
>
>You said the data is "not sensitive" and it is sent in plain text. So an
>attacker has it as soon as the endpoints do.

Of course.

>What does this accomplish over just hashing your extra data into the 28
>byte random field? (which would not require a new protocol structure)

You get more random bits mixed into the master secret. This gives you better cryptographic properties if your PRF has an output that is larger than 28 bytes, such as SHA-256 and SHA-384 (but not SHA-1, of course).

>224 bits of from each endpoint ... is 448 bits really not enough entropy
>somehow? 448 bits ought to be enough for anybody :-)

That's one opinion, maybe that of the people who wrote the current key mechanism. There is also an explicit assumption there that both users have good sources of randomness; if one doesn't, then it sure looks more like 224 bits total, which is not good enough for some people. This extension allows each party to introduce enough randomness to the master secret to overcome a complete failure of their peer's RNG.

>It looks to me (but IANAC) like the PRF maxes out at 672 bits of entropy
>doing key block expansion (master_secret[48]*8 + 128md5 + 160sha), so
>you can only effectively add 224 bits (only 50% more) from any source.

Adding 224 bits to your earlier 224 bits should, indeed, be enough for most people's security needs.

>How big were you planning to make those symmetric keys anyway?

48 bytes, as shown in the document.

--Paul Hoffman, Director
--VPN Consortium