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

[Martin Rex <[e-mail]>]

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