Re: [Cfrg] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]

[Simon Josefsson <[e-mail]>]

Paul Hoffman <[e-mail]> writes:

> If the authors really did mean to give useful guidance, I propose the
> following replacement for this section:

Re-reading the original text and Paul's proposed text below, I strongly
prefer the latter one.  The situation is not as simple as the original
text implies, and this needs to be conveyed by the document somehow.
Avoiding RFC 2119 language, which doesn't make sense for an
Informational document anyway, is a good way to achieve this.

/Simon

> =====
> SHA-1 provides less collision resistance than was originally
> expected, and collision resistance has been shown to affect some (but
> not all) applications that use digital signatures. Even if SHA-1's
> collision resistance was as good as was expected, SHA-256's collision
> resistance and resistance to finding pre-images are much higher by
> design.
>
> Because of this, designers of IETF protocols should put a strong
> preference for signature algorithms with SHA-256 in their protocols.
> The typical way to give such a preference is to make the algorithm
> that uses SHA-256 mandatory, while the algorithm using SHA-1 being
> optional. Of course, SHA-0 should continue to not be used in any IETF
> protocol.
>
> Nearly all IETF protocols that use signatures assume existing public
> key infrastructures, and SHA-1 is still used in signatures nearly
> everywhere. Therefore, it is unwise to prohibit the use of SHA-1 in
> signature algorithms. However, it is certainly useful to point out in
> the security considerations for those protocols that SHA-1 is not as
> strong as SHA-256.
>
> A protocol designer might want to consider the use of SHA-1 with
> randomized hashing such as is specified in [SP800-107]. However, such
> use will still not be stronger than the normal use of SHA-256, and it
> expands the size of signatures and requires them to carry material
> that is not needed today.
>
> HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
> for IETF protocol design.
> =====
>
> You can then remove the reference to RFC 2119.
>
> --Paul Hoffman, Director
> --VPN Consortium