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

[Paul Hoffman <[e-mail]>]

At 9:26 PM -0600 2/2/10, Marsh Ray wrote:
>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?

Wrong. The master secret (the only one that matters for channel security) gets the advantage of all the randomness added by the client *and* the server. Without this extension, that is still probably acceptable for some uses; with the extension (if the server contributes more randomness), for all uses. Look again at section 8.1 in RFC 5246.

>I think similar effects apply with DHE key exchange.

Indeed. You will get half the expected randomness in the master secret.

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

Yes.

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

Or the server can contribute all that is needed, if you are using the proposed extension.

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

The complexity overhead is only paid for in systems that want to use these kinds of extensions. (Did I already say that?)

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

So does the sentence that follows it: "Hash-based PRFs like the one used in TLS master secret calculations are designed to be fairly indifferent to the input size."

>Some kinds of hash attacks
>let the attacker mess with the bytes earlier in the handshake by placing
>colliding blocks in the Hello Extensions.

Are you saying that that affects the HMAC-based PRF calculation in TLS 1.2? If so, this is a pretty significant flaw in TLS that no one else has noticed. Note that there have been papers by well-known cryptographers saying that the HMAC construction does not have the weakness you ascribe to it here.

>It also requires clients and servers to buffer the stuff and later
>implement a sorting algorithm based on type order.

By "later" you mean "still within the same handshake sequence" and by "sorting algorithm" you mean "ascending order of two-byte numbers", yes?

>Lots could go wrong
>with that. Pathological sort order DoS attacks, etc.

Please explain further. The TLS spec says that you can only have one instance of an extension in a handshake. Thus, all TLS implementations today already should be looking for multiple instances of the same extension. What is left is a relatively small number of extension values, each of which has a unique two-byte number associated with it. Where does "pathological sort order DoS attacks" or "etc" come in?

--Paul Hoffman, Director
--VPN Consortium