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

Andrey Jivsov <> Thu, 15 November 2012 00:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B069B21F86E4 for <>; Wed, 14 Nov 2012 16:35:01 -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 EQS9nsekbEd3 for <>; Wed, 14 Nov 2012 16:35:01 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:32]) by (Postfix) with ESMTP id 4144221F85EB for <>; Wed, 14 Nov 2012 16:35:01 -0800 (PST)
Received: from ([]) by with comcast id PRgp1k0031zF43QA3cb10Q; Thu, 15 Nov 2012 00:35:01 +0000
Received: from [] ([]) by with comcast id Pcaz1k00U2g33ZR8kcb0cw; Thu, 15 Nov 2012 00:35:00 +0000
Message-ID: <>
Date: Wed, 14 Nov 2012 16:33:52 -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: Thu, 15 Nov 2012 00:35:01 -0000

On 11/14/2012 03:42 PM, Paul Hoffman wrote:
> On Nov 14, 2012, at 3:35 PM, Andrey Jivsov <> wrote:
>> 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.
> If we have suggested that in the draft, we should change the text. Can you say where you got that feeling?

"However, the authors do not believe that any push to start using SHA-3 
is warranted at any time soon."

Suppose I am an Internet browser company. I read this as "OK, I will 
revisit the SHA-3 support in 5 year".

In 5 years the Keccak "read" support is added, hopefully without bugs.

X.509 CAs cannot enable the Keccak because they will want wide browser 
support. This means they are waiting for all the browser vendors to make 
the support available.

OK, the other browser vendors added the support in the following few 

Then the CA will need to wait for the wide deployment of said browsers. 
Count the browsers in the TVs too. This will be another half of a decade.

So, we are looking at more than a decade, perhaps two, when the SHA-3 
can actually happen without significant disruptions.

For this to happen a decade from now some of the players should start 
making plans today. I think the statement I quoted above is only true 
for an environment where we can upgrade every participant fairy easily.

Hopefully NIST will force some timeline that will put the process in 
motion, because if I am in minority regarding how painful the new hash 
adoption is, I don't see it happening smoothly without a bit more 
proactive plan.