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

[Stefan Santesson <[e-mail]>]

Marsh,

I would rather fix the issue with the following updated text:

"The hash algorithm used to calculate hash values SHALL be the Finished
message hash algorithm of the handshake exchange from which the hashed
information was cached. The Finished message hash algorithm in this context
is the hash algorithm used to hash handshake messages in the calculation of
verify_data (i.e. Hash(handshake_messages) as defined in section 7.4.9 of
RFC 5246)."

I see no reason to involve the PRF function here. It only adds unnecessary
complexity as far as I can see.

/Stefan



On 10-07-13 1:37 AM, "Marsh Ray" <[e-mail]> wrote:

> 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