Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

[Simon Josefsson <[e-mail]>]

Brian Smith <[e-mail]> writes:

> Simon Josefsson wrote:
>>
>> Here is a proposal: Say SHA-1 is a MUST when TLS<  1.2 is negotiated but
>> later TLS versions MUST use the same hash as the one used by the PRF?
>>
>>    
> This is what I was originally going to suggest. The problem is that
> the client doesn't necessarily know which PRF will be used until it
> receives the ServerHello because the server could be TLS 1.0/1.1-only,
> because the PRF depends on the ciphersuite chosen by the server, and
> because the PRF for the chosen ciphersuite might not be based on a
> HMAC.

Ouch.  Maybe we could do it on the TLS protocol version advertised by
the client then?  We'd get agility, but slower transition since older
versions are still advertised.  Thus, clients still advertising at
minimum TLS v1.0 or v1.1 would MUST support/use SHA-1, clients at
minimum advertising TLS v1.2 would MUST support/use SHA-256.  I'm not
sure what to do say about future versions though.  Can we say "use the
default PRF algorithm"?

> My first suggestion, a long time ago, was to just use the fingerprint
> of the end certificate as the key for certificate caching. This is
> something that both sides already have to calculate anyway. In fact,
> many implementations are already using the certificate fingerprint as
> a cache key for internal purposes. Then, have the client and server
> use the Client Certificate URL extension if they want to optimize the
> client certificate part, which potentially saves many many more bytes
> than the caching CertificateRequest.certificate_authorities
> would. Just give up defining a generic mechanism; the level of
> generality and complexity in the current draft is really unwarranted.

I don't think the X.509 certificate is a good idea here -- TLS can be
used without X.509 certificates.

> My second suggestion is to have the server calculate the hash, and
> give the calculated hash to the client along with the content. Then
> the client and the server don't have to agree on any algorithms at
> all, and the server can choose whatever algorithm it wants.

I like this approach.  The server gets to chose the hash, and the client
will have to comply.  It is easy to implement, and it is possible to
transition to other checksum algorithms over time.

One improvement may be for the client to send a list of hashes it
supports, though, and the server picking the best subset of it, as long
as it is compatible with what it supports?

/Simon