Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"

[Andrey Jivsov <[e-mail]>]

On 11/14/2012 02:33 PM, Paul Hoffman wrote:
> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov <[e-mail]> wrote:
>
>> SHA-2 is well-supported today, but there are no solid reasons why SHA-3 will not be supported equally well in the future.
>
> In that future, we can re-look at support for it in IETF protocols. For now, algorithm agility might be sufficient.

I would agree, but the document such as RFC 4270 influence the future. 
If the message it sends is that the SHA-3 is an odd bifurcation in the 
SHA line, SHA-3 won't gain critical mass.

>> Let's say there is a protocols that is hardwired to SHA1 or MD5. Are we telling people thinking about its improvement to go with the SHA-2?
>
> Yes.
>
>> What about newly designed protocols?
>
> The same.
>
>> If you are a maintainer, what would you prefer: worry about explaining to others that "my SHA-2 use doesn't depend on collision resistance and is not vulnerable to extension attacks", v.s. I "use SHA-3".
>
> Nowhere did we say that you should not use SHA-3. In fact, we said the opposite. We said there was no need to push that.
>
>> I suggest that the document at least softens the statements on SHA-2 v.s. SHA-3. Ideally, I would like to see a path on which we move to the universally supported SHA-3 and, hopefully, the hardware manufacturers are comfortable to jump in.
>
> That's one view; we took a different one. So far, we have had good support in the IETF community for our view, but at some point that might change.
>

It would be useful for me and others to see more details behind the 
arguments that the SHA-2 is preferred to SHA-3 at IETF. I suspect there 
are a lot of assumptions here that may not apply to every particular case.

One of the parameters is the timeline. The transition to a new hash 
algorithm may take years in protocols and formats without algorithm 
agility, while the plans for which route to take are being made today.

For example, in OpenPGP there is a hardwired SHA1 fingerprint. It still 
seems wrong to me to move to SHA-2 and not SHA-3. I am leaning toward 
non-agile solution here because of space constrains and the fact that 
the agility will only be a benefit if Keccak is broken (so instead of 
adding SHA-2 + agility, add hardwired SHA-3 which is good for a few 
decades, at least).