Re: [secdir] Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt

Jeffrey Hutzelman <jhutz@cmu.edu> Mon, 11 December 2006 22:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gttyd-0002ht-C4; Mon, 11 Dec 2006 17:50:27 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gttyb-0002hk-Hr; Mon, 11 Dec 2006 17:50:25 -0500
Received: from currant.srv.cs.cmu.edu ([128.2.194.193]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gttya-0000lh-8v; Mon, 11 Dec 2006 17:50:25 -0500
Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id kBBMoMU7024088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Dec 2006 17:50:23 -0500 (EST)
Date: Mon, 11 Dec 2006 17:50:20 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>, Russ Housley <housley@vigilsec.com>
Message-ID: <3964E240930ED1BB542312EA@sirius.fac.cs.cmu.edu>
In-Reply-To: <20061211223453.GE26175@binky.Central.Sun.COM>
References: <20061211155532.GB26832@binky.Central.Sun.COM> <457DC1E2.30206@ipinfusion.com> <20061211211932.GA26175@binky.Central.Sun.COM> <7.0.0.16.2.20061211172844.042844d8@vigilsec.com> <20061211223453.GE26175@binky.Central.Sun.COM>
Originator-Info: login-token=Mulberry:0150O6x1GrLzszjjJIGsHqNn618fJudzNUuOgsHcM=; token_authority=postmaster@andrew.cmu.edu
X-Mailer: Mulberry/3.1.6 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: secdir@mit.edu, Jeffrey Hutzelman <jhutz@cmu.edu>, iesg@ietf.org, Vishwas Manral <vishwas@ipinfusion.com>, ietf@ietf.org
Subject: Re: [secdir] Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org


On Monday, December 11, 2006 04:34:54 PM -0600 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> On Mon, Dec 11, 2006 at 05:30:26PM -0500, Russ Housley wrote:
>> Nico:
>>
>> > Use of the NULL ESP algorithm implies no confidentiality protection,
>> > while use of the NULL AH algorithm implies no integrity protection
>> > (unless combined mode ESP algorithms are used).  And in general we want
>> > IPsec used to provide integrity or confidentiality+integrity
>> > protection, but not really just confidentiality protection.
>>
>> I generally agree with your point.  Integrity protection is
>> important, but I am not sure that this is the document to drive this
>> point.  We have seen NULL encryption and NULL integrity algorithms
>> are very useful for debugging.
>
> Right.  I am not suggesting a change of policy here, but rather an
> explanation for the MUST NOT use NULL ESP and NULL AH together.

So, "MUST is for implementors".  It's about requirements on the 
implementation, not on how it is used.  If you say that the NULL algorithms 
"MUST NOT be used", you are requiring the implementation not to permit 
their use under any circumstances.  That seems excessively strong.

I agree with Russ - while deploying the NULL algorithms in production would 
be silly, having them for debugging can be terribly useful.

-- Jeff

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf