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

[Marsh Ray <[e-mail]>]

Paul Hoffman wrote:
> At 7:50 PM -0600 2/2/10, Marsh Ray wrote:
>> 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.

Let's say the server has a perfect RNG and the client is broken Debian Etch.

The client provides 15 bits of usable entropy in the Client Hello, the
server provides 224.

RSA key exchange is negotiated.

The client generates the 48-byte premaster secret with an effective
entropy of less than 15 bits (his first handshake since power on).

Game over, right?

I think similar effects apply with DHE key exchange.

>> 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.

So at best there are 384 bits of entropy in play?

Assuming the server supplies his expected 224, our Debian Etch client
only has to pull together 160 usable BoE for them to hit that limit.

I do appreciate a healthy safety margin, but there is some complexity
overhead and potential security risk.

Your point about "potentially would allow an attacker who had partially
compromised the inputs to the master secret calculation greater scope
for influencing the output" is significant. Some kinds of hash attacks
let the attacker mess with the bytes earlier in the handshake by placing
colliding blocks in the Hello Extensions.

It also requires clients and servers to buffer the stuff and later
implement a sorting algorithm based on type order. Lots could go wrong
with that. Pathological sort order DoS attacks, etc.

I like the idea of increasing the available entropy on principle, but it
also looks like other internal limits are too close for an whole
extension framework to be worth the additional complexity. Hate to say
it, but it sounds like a core engineering change for a future version of
TLS to widen the path end-to-end.

- Marsh