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

["Kemp, David P." <[e-mail]>]

The security considerations section already points out that collision
avoidance is not a requirement:

   Failure of a provided hash to correctly and uniquely
   identify the correct set of hashed parameters may at most lead to a
   failed TLS handshake followed by a new attempt without the cached
   information extension. No serious security threat requires selected
   hash algorithms to have strong collision resistance.

CRC32 would provide sufficient uniqueness for this application, but
since client libraries already include SHA-1, it is a convenient (albeit
slower and overqualified) substitute.  The interoperability benefit of
requiring support for a common algorithm:

   Compliant implementations MUST support "wxyz" as HashAlgorithm.

... far outweighs any conceivable benefit of not requiring support for a
common algorithm.   Algorithm agility, negotiation, and version
dependencies would be grotesque complexities in this context.

Dave



-----Original Message-----
From: Brian Smith

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.