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

Andrey Jivsov <> Wed, 14 November 2012 23:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9887421F85B3 for <>; Wed, 14 Nov 2012 15:36:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2HrKxsk48+i5 for <>; Wed, 14 Nov 2012 15:36:53 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:44:76:96:27:243]) by (Postfix) with ESMTP id 32BF921F84EC for <>; Wed, 14 Nov 2012 15:36:53 -0800 (PST)
Received: from ([]) by with comcast id PZPp1k0040FhH24ADbct0q; Wed, 14 Nov 2012 23:36:53 +0000
Received: from [] ([]) by with comcast id Pbcr1k00G2g33ZR8UbcsQX; Wed, 14 Nov 2012 23:36:52 +0000
Message-ID: <>
Date: Wed, 14 Nov 2012 15:35:43 -0800
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: Paul Hoffman <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Security Area Advisory Group <>
Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2012 23:36:53 -0000

On 11/14/2012 02:33 PM, Paul Hoffman wrote:
> On Nov 14, 2012, at 1:40 PM, Andrey Jivsov <> 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).