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

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 02 October 2010 16:24 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: cfrg@core3.amsl.com
Delivered-To: cfrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1893A6C6E; Sat, 2 Oct 2010 09:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.389
X-Spam-Level:
X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epQx97yy5gYb; Sat, 2 Oct 2010 09:24:52 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 12D3E3A6C5B; Sat, 2 Oct 2010 09:24:52 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o92GPfjO098045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Oct 2010 09:25:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240808c8cd060efcb4@[10.20.30.158]>
In-Reply-To: <4CA65AD7.80300@ieca.com>
References: <4CA65AD7.80300@ieca.com>
Date: Sat, 02 Oct 2010 09:25:25 -0700
To: saag@ietf.org, cfrg@irtf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [Cfrg] [saag] [Fwd: I-D ACTION:draft-turner-sha0-sha1-seccon-00.txt]
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Oct 2010 16:24:53 -0000

At 6:04 PM -0400 10/1/10, Sean Turner wrote:
>While writing an update for the MD2, MD4, and MD5 security considerations, somebody pointed out that we should do the same for SHA-1.  We ended up doing SHA-0 too.  Below is a link to the draft. Please send comments to saag/cfrg.

4. Guidance

   SHA-1 no longer provides an acceptable security level when used in
   digital signature applications.  IETF protocol designers SHOULD NOT
   specify digital signature algorithms using SHA-1 as mandatory to
   implement.  IETF protocols that rely on SHA-1 based digital
   signatures MUST include countermeasures that mitigate SHA-1's reduced
   collision resistance by randomized hashing (e.g., as specified in
   [SP800-107]).

   HMAC-SHA-1 remains secure and is the preferred keyed hash algorithm
   for IETF protocol design.

   As noted above, any use of SHA-0 is strongly discouraged. Discussions
   regarding the strength of SHA-0 were included for completeness only.
   SHA-0 has no functional or performance advantage, and SHA-1 is
   considered significantly more secure.

There are many serious issues here. First the procedural ones.

- It is not "guidance" if you use "MUST": it is a mandate. In this case, it is not clear why the authors get to make a mandate on IETF protocol designers. If it is because two of the authors are Security ADs, the document should say so explicitly (although then you have to explain why you dragged Lily into it). If it is because two of the authors are from NIST, the document should say so explicitly (although then you have to explain why you dragged Sean into it).

- The "SHOULD NOT" in the first paragraph does not say when it is OK to do so anyway, so this goes against RFC 2119.

- There is no explanation of why an Informational RFC have any effect on IETF standards-track documents.

Next the security issues.

- The first sentence is obviously wrong unless you believe that >95% of all financial transaction in the world today are insecure. This type of hyperbole does not belong in IETF documents.

- The third sentence, on randomized hashing, is not based on reality. Few if any of the current IETF protocols show how to carry the random number used. This sentence essentially says "all IETF protocols must use an unspecified protocol".

- The third paragraph makes it sound like there is a security problem that needs to be solved, but there isn't. A quick search shows that exactly two RFCs even mention SHA-0, and neither RFC is a protocol.

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

=====
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