Re: [TLS] Kill Finished (and other tricks for hardware)

[Henrick Hellström <[e-mail]>]

On 2014-04-18 17:39, Watson Ladd wrote:
> On Fri, Apr 18, 2014 at 8:16 AM, Henrick Hellström <[e-mail]> wrote:
>> On 2014-04-18 07:59, Michael D'Errico wrote:
>>>
>>> This is a much weaker failure indication than checking the Finished
>>> messages, so I'd prefer to keep them.  Can you think of an alternate
>>> construction for the Finished message that doesn't use the PRF?
>>
>>
>> Indeed. The client (being the last peer of the connection to send a random
>> handshake message, and being in a position to pick the pre_master_secret)
>> will have a quadratically improved chance of picking a specific
>> master_secret

Please note that this relevant in the context of removing the Finished 
messages and including the handshake hash in the KDF step, because of 
the following questions:

   #1. How easy is it for an attacker to pick one specific master_secret 
as the output of a handshake?
   #2. How easy is it for an attacker to pick any master_secret, that 
happens to produce the correct finished messages and a partially chosen 
key block (e.g. with only one write key chosen) when the handshake hash 
is not included in the KDF step?
   #3. How easy is it for an attacker to pick any master_secret, that 
happens to produce a partially chosen key block (e.g. with only one 
write key chosen) when the handshake hash is included in the KDF step?

(I am not elaborating on exactly what kind of practical attacks would 
become possible if the attacker picks a partially correct master_secret. 
It suffice to say that it doesn't seem to be something that should be 
easy to do.)

It seems reasonable to assume that case #1 and case #2 are equivalent, 
i.e. since the PRF is invoked three times with the same key material 
(master_secret) and different labels and seeds, picking a partially 
correct master_secret is not easier than picking the exactly correct 
master_secret.

However, if the PRF is only invoked once with the master_secret as key 
material and the handshake hash as seed, it is not self-evident that 
case #3 is as hard as case #1. In particular, #3 might be significantly 
easier for some PRF algorithms than other.

Generally speaking, though, irregardless of the security properties of 
the PRF, the case of collision attacks ought to be considered.

Suppose an attacker is trying to get two different connections to have 
the same client_write_encryption key. With a 128 bit security cipher 
suite, this key will be 128 bits, and getting a collision in 128 bits 
only require an 2^64 effort, even if the PRF is completely perfect.


> Care to expand on this? For noncontributory exchanges you may be
> correct, but ECDHE is contributory.

I am comparing the chances the server has to choose the master_secret, 
to the chances the client has.
   - When the server_key_exchange is sent, the server doesn't know what 
the client will send, so the server has no better chance than random to 
pick the master_secret.
   - When the client_key_exchange is generated, the client will in 
principle be able to predict the master_secret before sending the 
client_key_exchange message.

In particular, if e.g. ECDHE-P256 is used, then presuming the TLS PRF 
preserves entropy up to at least 256 bits, the server will have on 
average a one in 2^255 chance of picking the "right" master_secret, 
because the server is gambling on what 256 bit ephemeral private key the 
client will pick. The client will however be able to pick the pre_master 
secret with a 2*2^128 effort (based solely on the DLP strength of EC-P256).

Now, for the same reason, if someone proposes a cipher suite that 
significantly weakens the PRF/KDF (e.g. by basing it solely on AES 
without ensuring the function is one way), eliminating the finished 
messages will potentially enable a man-in-the-middle to have 
significantly better chance than 1 on 2^256 to pick a master secret that 
is "almost" right and at least results in a chosen client_write_key.