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

[Paul Hoffman <[e-mail]>]

At 10:19 AM -0500 2/3/10, Marsh Ray wrote:
>Paul Hoffman wrote:
>> 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.
>
>Sure but MitM knows all that because it's sent in the clear. The only
>thing MitM doesn't know in this scenario is the private key to the
>server's cert. So if the premaster secret is predictable (only 32k
>possibilities or so), it doesn't matter if it's well encrypted to the
>server's cert. A passive attacker can work out the master secret.

Boy, did I misinterpret your "Game over" question. I assumed you were talking about the amount of randomness in the master secret, not the amount of secrecy. OF COURSE adding public randomness to a value with low secrecy and low randomness only adds randomness, not secrecy. You can't magically generate cryptographic secrecy with public values.

If by "game over", you meant for secrecy, yes of course. The SSL world already discovered that with the Netscape SSLv2 debacle.

Let me try again: the proposal in draft-hoffman-tls-additional-random-ext is to add *randomness* to the master secret, not more secrecy. If I have said anything in the draft that makes that unclear, by all means let me know and I will fix it.


--Paul Hoffman, Director
--VPN Consortium