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

[Brian Smith <[e-mail]>]

Stefan Santesson wrote:
> Well,
>
> I went through my change list and have now updated and reposted the draft as
> draft-03.
>
> Changes can be viewed from:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-03.txt
>    
I think it is especially important to have the SHA-1 requirement 
changed. It is a big hassle to require SHA-1 for compliance when now 
every use of SHA-1 has to be reviewed. Also, mandating SHA-1 would be in 
conflict with other requirements--especially requirements to follow NIST 
and NSA recommendations regarding algorithms. At a minimum, make SHA-1 
support mandatory only if/when the connection's negotiated version is 
less than TLS 1.2.

The client already has to calculate hashes of each certificate in the 
certificate chain, using algorithms fixed at the time each certificate 
was signed. The client and server implicitly trust all of these 
algorithms if they accept the certificate chains. X.509 libraries 
already provide efficient access to these hashes. Also, given the 
fingerprint of the sender's certificate, you can determine the entire 
certificate chain if all the certificates are available in the cache. 
Consequently, it would be much better if hash used for identifying a 
cached certificate was the same as the fingerprint of the sender's 
certificate, instead of a hash of the entire certificate chain using one 
or more other algorithms.

The server already told the client what hash algorithms it supports in 
CertificateRequest message from which the client extracted the cached 
certificate_authorities. The client can just pick *one* of those 
algorithms when hashing the certificate_authorities--most likely, the 
hash algorithm used by for the signature of its own certificate. I don't 
see why it's valuable for the client to be able to include multiple 
hashes in its ClientHello. In other words, I think CachedInformation 
should be removed and all uses of it replaced by CachedObject.

But, then you can go even farther and remove CachedObject and 
CachedInformationType:

enum { cached_certificate_chain(TBD), cached_trusted_cas(TBD), (65535) } 
ExtensionType;

The "extension_data" field of each of these extensions, when included in 
the client hello, SHALL contain CachedInformationHash according to the 
following structure:

struct {
     HashAlgorithm hash;
     opaque hash_value<1..255>;
} CachedInformationHash;

Then the server could indicate which items it supports by including 
empty extension(s) with the corresponding type(s), which is what most 
other extensions do.

Regards,
Brian