No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors
Russell Dietz <rdietz@hifn.com> Thu, 18 July 2002 00:58 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 g6I0w1w06581; Wed, 17 Jul 2002 17:58:01 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA23390 Wed, 17 Jul 2002 20:18:55 -0400 (EDT)
Message-ID: <D7D145EB4903D311985E00A0C9FC76FE02873462@SJCXCH01.hifn.com>
From: Russell Dietz <rdietz@hifn.com>
To: IPSec Working Group <ipsec@lists.tislabs.com>, SAAG <saag@lists.tislabs.com>
Subject: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors
Date: Wed, 17 Jul 2002 17:35:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
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