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

[Martin Rex <[e-mail]>]

Marsh Ray wrote:
> 
> > so if everyone thinks sha256 will be cryptographically
> > viable for the foreseeable future and SHA-1 will soon be impossible
> > to get "approved", then sha256 truncated to 64 bits could be a
> > reasonable MUST-support algorithm.
> 
> Now you'll have to explain why you're taking the output of an
> industrial-strength hash function and throwing away 3/4 of it. :-) Plus,
> it's wasted effort since collisions will be possible to find in any
> 64-bit hash function.


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.

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.

Btw. the certificate fingerprinting and public key fingerprinting
algorithms currently also still use SHA-1 (e.g. rfc-5280 4.2.1.2).


I firmly believe that "MUST support SHA-1" is perfectly fine for
this proposal and more than just "good enough" to ship it, provided
that both peers can reliably determine (negotiate) through the
Hello extension whether they support or prefer a newer/different
common hash algorithm before the client starts populating his cache.


-Martin