Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors

"Housley, Russ" <rhousley@rsasecurity.com> Wed, 24 July 2002 21:00 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 g6OL0Iw28947; Wed, 24 Jul 2002 14:00:18 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08602 Wed, 24 Jul 2002 16:04:31 -0400 (EDT)
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: RJ Atkinson <rja@extremenetworks.com>
Cc: ipsec@lists.tislabs.com, saag@lists.tislabs.com
Message-Id: <5.1.0.14.2.20020724140348.0212dd78@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Jul 2002 14:13:03 -0400
Subject: Re: No need for SHA-2 Packet Authentication - Open Letter to the WG and Area Directors
In-Reply-To: <A3AF1CA0-9A08-11D6-8338-00039357A82A@extremenetworks.com>
References: <D7D145EB4903D311985E00A0C9FC76FE02873462@SJCXCH01.hifn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

Ran:

We are not trying to stifle innovation, nor are we trying to suppress SHA-256.

SHA-256 has an important place, but this is not it.  SHA-256 was developed 
to support applications that need a longer output value.  SHA-1 generates a 
160-bit output value.  In our view, SHA-1 should be used unless a longer 
output value is needed.  In the proposal, the hash value is truncated to 
128 bits, so there is no benefit from the more complicated hash function.

I would support the use of SHA-256 if the final output were longer than 160 
bits.

Russ

At 12:41 AM 7/18/2002 -0400, RJ Atkinson wrote:

>On Wednesday, July 17, 2002, at 08:35 PM, Russell Dietz wrote:
>
>>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.
>
>Russell,
>
>I'm pretty indifferent to the topic of what ought or ought not be
>mandatory-to-implement or maybe even standards-track RFC versus
>informational RFC.  I am remarkably indifferent to any of the
>mathematical parts of your note or Uri's followup.
>
>I do feel pretty strongly that the above referenced draft ought to be
>permitted to be published, at least as an Informational RFC, so that
>those folks who choose to implement/deploy it can do so in an
>interoperable manner.
>
>Trying to prevent people from publishing open specifications for
>entirely optional-to-implement technology is NOT consistent with
>the Internet tradition.  I would hope that the RFC Editor would
>apply their own good judgement to an individual request to publish
>such a document as an Informational RFC if the situation should arise.
>
>Yours,
>
>Ran
>rja@extremenetworks.com
>
>
>_______________________________________________
>saag mailing list
>saag@mit.edu
>http://jis.mit.edu/mailman/listinfo/saag