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

[Stefan Santesson <[e-mail]>]

How about MUST use SHA-1 for TLS <1.2 and the proposed solution for =< 1.2?

/Stefan


On 10-07-13 5:44 PM, "Martin Rex" <[e-mail]> wrote:

> Marsh Ray wrote:
>> 
>> On 07/13/2010 09:27 AM, Stefan Santesson wrote:
>>> 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.
>> 
>> Is this intended to be a TLS 1.2-only feature?
> 
> I do not see a convincing argument to cripple this extension to TLSv1.2,
> The idea of TLS extensions is that they can be added to an existing
> implementation of TLS, and the installed base of pre-TLSv1.2 is huge.
> 
>> 
>> If not, how is it to be interpreted for 1.0 and 1.1? They don't use this
>> "Hash(handshake_messages)" definition because the unified hash mechanism
>> was introduced in 1.2.
> 
> Spelling it out for all three existing TLS protocol versions might
> avoid confusions and incorrect conclusions.
> for TLSv1.0 & TLSv1.1 use SHA-1, for TLSv1.2 use SHA-256.
> 
> 
>> 
>> To me, the PRF seems simpler because it's consistently defined in each
>> TLS version.
> 
> How come?
> 
> From the TLS spec:
> 
>        P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
>                               HMAC_hash(secret, A(2) + seed) +
>                               HMAC_hash(secret, A(3) + seed) + ...
>        A(0) = seed
>        A(i) = HMAC_hash(secret, A(i-1))
> 
> 
> There is neither a secret nor a seed involved in the cache identifier,
> and we also do not need an arbitrary length output, so the PRF() looks
> like a square peg to a round hole.
> 
> What we wanted is a hash over the omitted handshake data, not unlike
> what the certificate URL extension does.
> 
> The original idea is about caching data from a previous handshake
> (which shares some characteristics with TLS session caching) and
> caching on one side only (which shares some characteristics
> with the TLS session ticket extension).  When used for caching
> it is sufficient when the client learns the hash algorithm to use
> on receipt of the ServerHello handshake message that creates
> the cache entry.
> 
> 
> -Martin