RE: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors
Christina Helbig <cbh@zyfer.com> Thu, 18 July 2002 16:52 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6IGq4w14876; Thu, 18 Jul 2002 09:52:04 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA25231 Thu, 18 Jul 2002 11:59:19 -0400 (EDT)
Message-ID: <6F0AA176DA68704884B7507AE6907E180818D7@snake012.odetics.com>
From: Christina Helbig <cbh@zyfer.com>
To: 'Russell Dietz' <rdietz@hifn.com>, IPSec Working Group <ipsec@lists.tislabs.com>, SAAG <saag@lists.tislabs.com>
Subject: RE: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors
Date: Thu, 18 Jul 2002 09:12:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Russell, I have looked to the available I-Ds and found only <draft-ietf-ipsec-ciph-sha-256-01.txt>. In this draft a lot of your points is covered, e.g. the claim about re-keying is not more part of this draft, truncation is to 128 bit, comparison to SHA-1 is only about speed... Greetings Christina > -----Original Message----- > From: Russell Dietz [mailto:rdietz@hifn.com] > Sent: Wednesday, July 17, 2002 5:36 PM > To: IPSec Working Group; SAAG > Subject: No need for SHA-2 Packet Authentication - Open > Letter to the WG > a nd Area Directors > > > To the IPSec Working Group and Security Area Directors: > > The purpose of this letter is to comment on an existing > Internet Draft, > draft-ietf-ipsec-ciph-sha-256-00.txt, dated Nov 2001, > co-authored by S. > Frankel and S. Kelley. This draft, hereafter referred to as > DRAFT-SHA-256 > for brevity, defines how to use the new SHA-256 algorithm > from NIST (FIPS > 180-2) for packet authentication within the ESP and AH > mechanisms of IPSec. > > Our basic argument here is that, while the new SHA-256 algorithm is > definitely useful in other contexts, in fact there is no evidence that > DRAFT-SHA-256 provides any meaningful additional > cryptographic security over > the HMAC-SHA-1-96 algorithm defined in RFC2406 and already in > widespread use > for packet authentication in IPSec. For all we know, quite > the contrary may > be true, as SHA-256 is a new transform and thus has seen > considerably less > public review so far than SHA1 has already received. In any > case, it is > extremely unlikely that HMAC-SHA1 will be the weak point in > any system using > IPSec. Hence, it is not clear that trying to improve its > security makes any > sense, given the costs and instability associated with such a change. > > Unfortunately, the current draft is misleading in this regard: > "Using the SHA-256 block cipher, with its increased block > size (512 bits) > and increased hash length (256 bits), provides the new > algorithm with the > ability to withstand continuing advances in crypto-analytic > techniques and > computational capability. It also allows less frequent > re-keying, which is > useful for high-speed networks and high-volume applications." > It is our belief that, as currently defined in DRAFT-SHA-256, > the use of > SHA-256 does not achieve any of these stated goals. > > First of all, the block size of SHA-256 (512 bits) is > identical to that of > SHA-1, so the first assertion in the quote above is simply > false, although > frankly it would have no relevance if true. Second, there is no known > reason why DRAFT-SHA-256 would in fact allow less frequent > rekeying, using > either 32-bit or 64-bit sequence numbers. Finally, and most > importantly, > while it is true that SHA-256 can output 256 bits, in the > current draft the > HMAC-SHA-256 output is in fact truncated to 96 bits, as is > HMAC-SHA-1 in > RFC2406. For the HMAC-SHA-1-96 and DRAFT-SHA-256 algorithms, > there is every > reason to believe that the limiting factor in security is the > number of bits > of hash included in the packet, not the length before > truncation. The best > attacks known on HMAC-SHA-1-96 and DRAFT-SHA-256 depend only > on the length > after truncation, not the length before truncation. Hence, > the HMAC-SHA-1-96 > and DRAFT-SHA-256 have equivalent security against known > attacks, and there > seems to be little reason to prefer either one over the other, from a > cryptographic perspective. For any given number of output > bits, up to the > SHA-1 limit of 160 bits, this would continue to be the case. If it was > desired to have a MAC value longer than 160 bits, then the > use of SHA-256 > would likely be appropriate, but there is no apparent need > for such a MAC > tag length, according to current knowledge. > > It is possible that the draft was initiated from a fundamental > misunderstanding of Figure 1 (page 3) of the NIST draft FIPS > 180-2. This > figure states that the "security" of SHA-1 is 80 bits, while > the "security" > of SHA-256 is 128 bits. A naive reading of this figure would > thus lead one > to conclude that only SHA-256 is appropriate for use with > AES-128. However, > the figure in question deals with the strength of the hash > functions against > collisions as part of a digital signature scheme. It is > likely that the use > of SHA-256 is very appropriate for the digital signatures used in the > certificates of the IKE exchange used to generate AES-128 and > HMAC-SHA-1-96 > keys for ESP and AH. This is in fact the application for > which SHA-256 was > designed. > > However, while Figure 1 in FIPS 180-2 is correct for digital > signatures, it > has no direct relevance to the issue of packet authentication > in ESP and AH > as addressed in DRAFT-SHA-256. Packet authentication has a completely > different attack model. In particular, there is no known > feasible "birthday > attack" problem in the packet authentication context, as has > been shown by > Krawczyk and others (e.g., "Keying Hash Functions for Message > Authentication" by Bellare, Canetti, and Krawczyk, Crypto '96). > > Since HMAC-SHA1-96 (RFC2406) is already a "MUST" for IPSec > compliance, all > IPSec implementations, hardware or software, already have it and must > continue to support it for many years to come. Any possible > argument that > somehow SHA-256 can replace SHA-1 to save hardware cost is > thus extremely > ill-founded. In fact, quite the opposite is true: adding > DRAFT-SHA-256 as an > IPSec option will only increase hardware cost, with no > accompanying security > benefit. > > We expect that if the WG approved DRAFT-SHA-256, it would be > optional rather > than mandatory. However, there would be a strong risk that > vendors and > their customers might feel compelled to use it out of a > misunderstanding of > the cryptographic issues. Already we have heard potential > customers asking > for support for DRAFT-SHA-256, with the rationale being, "if > IETF approves > it, it must be good". > > Our purpose in submitting this letter is to make sure that > the IPSec working > group has a reasonable understanding of the issues involved in > DRAFT-SHA-256. If the WG decides to approve the draft, we > strongly suggest > that, at a bare minimum, > > a) the inaccurate claims discussed above should be corrected > or removed, > b) the document should be re-worked to clarify the fact that SHA1 is > perfectly adequate, according to current knowledge, > c) the resulting transform should be qualified as > optional-to-implement, not > mandatory, and > d) the draft should make clear under what circumstances the > transform is an > option worth pursuing (e.g. if SHA-1 is broken by advances in > cryptanalysis, > but SHA-256 is not) > > However, given that there is no known cryptographic benefit > to implementing > this proposed standard, we respectfully submit that the IPSec > WG should not > approve this draft. > > Doug Whiting, dwhiting@hifn.com, Hifn > David McGrew, mcgrew@cisco.com, Cisco > Dave Wagner, daw@cs.berkeley.edu, UC Berkeley > Russ Housely, rhousley@rsdsecurity.com, RSA Labs > Niels Ferguson, niels@ferguson.net, MacFergus BV > Thomas Hardjono, thomas.hardjono@verisign.com, Verisign > Scott Fluhrer, fluhrer@cisco.com, Cisco > Jesse Walker, jesse.walker@intel.com, Intel > Mike Sabin, mike.sadin@worldnet.att.net, Independent Consultant > John Kelsey, kelsey.j@ix.netcom.com, Certicom > Russell Dietz, rdietz@hifn.com, Hifn > > Russell Dietz > Hifn, Inc. > pgp-fingerprint: CEE3 58B0 DD09 4EA5 7266 BF1E B5F6 4D1A 4AD1 65B4 >
- No need for SHA-2 Packet Authentication - Open Le… Russell Dietz
- Re: [saag] No need for SHA-2 Packet Authenticatio… Uri Blumenthal
- RE: [saag] No need for SHA-2 Packet Authenticatio… Russell Dietz
- RE: No need for SHA-2 Packet Authentication - Ope… Christina Helbig
- Re: [saag] No need for SHA-2 Packet Authenticatio… Mats Näslund
- Re: [saag] No need for SHA-2 Packet Authenticatio… RJ Atkinson
- Re: [saag] No need for SHA-2 Packet Authenticatio… RJ Atkinson
- Re: No need for SHA-2 Packet Authentication - Ope… Housley, Russ
- Re: No need for SHA-2 Packet Authentication - Ope… Bart Preneel
- Re: [saag] Re: No need for SHA-2 Packet Authentic… Uri Blumenthal