Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors

RJ Atkinson <rja@extremenetworks.com> Thu, 18 July 2002 19:14 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 g6IJEYw21171; Thu, 18 Jul 2002 12:14:34 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA25453 Thu, 18 Jul 2002 14:26:24 -0400 (EDT)
Date: Thu, 18 Jul 2002 00:41:35 -0400
Mime-Version: 1.0 (Apple Message framework v482)
Cc: IPSec Working Group <ipsec@lists.tislabs.com>, SAAG <saag@lists.tislabs.com>
Message-Id: <A3AF1CA0-9A08-11D6-8338-00039357A82A@extremenetworks.com>
In-Reply-To: <D7D145EB4903D311985E00A0C9FC76FE02873462@SJCXCH01.hifn.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Subject: Re: [saag] No need for SHA-2 Packet Authentication - Open Letter to the WG a nd Area Directors
From: RJ Atkinson <rja@extremenetworks.com>
Content-Transfer-Encoding: 7bit
To: Russell Dietz <rdietz@hifn.com>
X-Mailer: Apple Mail (2.482)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

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