Re: [TLS] New cached-info draft 09 posted

[Marsh Ray <[e-mail]>]

On 07/12/2010 04:45 PM, Stefan Santesson wrote:
> We had a very long debate about this and we finally reached an agreement.
> Can we stick with it or do we have to redesign this over and over again?

We're almost there!

> I don't see the benefit of using a hash that is stronger than the hash
> function used to generate the finished message.
>
> We only need an identifier.

Note that the Finished message was not designed to be used as an identifier.

> The only security requirement identified after a
> very long debate is that we want to make sure that we preserve the security
> properties of the Finished message. That we do if we use the same hash
> function.

One little wrinkle is that it's not just a simple hash function that 
generates the Finished message. It's from the PRF which is a redundant, 
recursive application of HMAC (itself redundant). In order to calculate 
his Finished verify_data, a TLS 1.0 server has to invoke hash functions 
a total of 16 times (AFAICT, might be off a factor of two there). IMHO 
it's the most robust part of TLS by far.

Since HMAC is dynamically keyed by the master secret it eliminates a lot 
of precomputation attacks. Perhaps this is why verify_data was not 
expected to need collision resistance and is only 12 bytes (96 bits) 
long. For some purposes the client and server's Finished messages may 
function as a longer 24 byte value.

So the Finished.verify_data has some very particular properties that are 
impossible to duplicate precisely for the cached_info identifier.

from -09:
>    The hash algorithm used to calculate hash values SHALL be the hash
>    algorithm that was used to generate the Finished message in the
>    handshake exchange from which the hashed information was cached. Hash

For TLS 1.0 and 1.1, would this amount to MD5(data)+SHA-1(data)? That's 
36 bytes.

I think the closest we can come is by using the PRF with a static 
secret. For collision resistance we could go with the total amount of 
verify_data, 24 bytes.

How about something like:

[...]

The hash values SHALL be generated using the same PRF that was used to 
generate the Finished messages in the handshake exchange from which the 
hashed information was cached. Although normally the PRF would be 
initialized from the master_secret, this usage requires a hashing 
algorithm which remains stable across multiple handshakes. To accomplish 
this the fixed label string is simply supplied again in place of the 
secret input for PRF initialization.

[...]

    opaque hash_value<hash_value_length>;

    hash_value
       PRF(fixed_value, cached_info_label, Hash(cached_object_data))
           [0..hash_value_length-1];

    hash_value_length
       Twice the length of a single Finished.verify_data message for
       the current handshake. For all current versions of TLS, this
       is 24 bytes.

    fixed_value and cached_info_label
       The string "cached info" for both.

- Marsh