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

[Brian Smith <[e-mail]>]

Martin Rex wrote:
> The original purpose of this extension/proposal is to save network
> bandwith on repeated _full_ TLS handshakes between peers and
> where TLS session caching is not available for whatever reason.
>    
Even when session caching is available, this extension is useful, 
because it saves bandwidth when a session ID/ticket expires.
> In order to make clear that collision resistance of SHA-1 is
> perfectly sufficient, I think the hash value should be
> unconditionally truncated to, say, 128-bit (16 octets),
> independent of which hash algorithm is used.  This would
> also answer any question about whether SHA-1 is sufficient. It is.
>    
Nobody ever said SHA-1 is insufficient. My first argument is that some 
implementations don't have to implement SHA-1 for any reason, so forcing 
them to implement SHA-1 just for this extension is unreasonable. My 
second argument is that having the client and server both calculate the 
hashes using some agreed-to algorithm is unnecessarily complex.
> Btw. the certificate fingerprinting and public key fingerprinting
> algorithms currently also still use SHA-1 (e.g. rfc-5280 4.2.1.2).
>    
RFC-5280 4.2.1.2 just says that SHA-1 is a "common method" for 
generating the subject key identifier and "Other methods of generating 
unique numbers are also acceptable." In other words, it is an opaque 
unique identifier like I am advocating to simplify this extension. (But, 
to be clear, the subject key identifier would not be an acceptable 
identifier to use for caching certificates, because it only identifies a 
public key, not the entire certificate chain.)

Regards,
Brian