RE: No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors

[Christina Helbig <cbh@zyfer.com>]

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
>