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

[Marsh Ray <[e-mail]>]

Kemp, David P. wrote:
> I’d be happier with MUST.  I don’t buy the argument that all code that
> makes up an application must come from a certified crypto library;
> certainly XML parsers, GUI toolkits, and a million other things are
> available to developers, and I find it hard to believe that 20 years
> from now nobody will be able to find some C code somewhere to do SHA-1. 
> If it is impossible to get consensus without a SHOULD, then so be it,
> but that is a cop-out.

The problem with specifying SHA-1 is that it's a recognized as a crypto
algorithm. It's showing its age and various parties are starting to
forbid its use.

It will not be so fun to convince reviewers that "yes we're using SHA-1
but not in a way that really matters."

> I agree with Martin and Brian that all hashes including SHA-1 should be
> truncated.  To make it impossible for developers to miss (and to save a
> few bits of bandwidth) it should be truncated to less than 20 octets. 
> I’d suggest 8 octets, but pick your favorite number (8, 12, 16) less
> than 20.

If all you need is a 64-bit checksum for data-structure-style hashing
and indexing, use any old old-fashioned checksum algorithm.

This would be simple for everyone to implement and it clearly
communicates your design intent (that the security of the design does
not depend on any properties of this value's calculation).

Using a weakened form of a partially-broken and deprecated cryptographic
algorithm seems like it could provoke a lot of useless discussion.

- Marsh