RE: MUST implement AES-CBC for IPsec ESP

"Lawrence Rosen" <lrosen@rosenlaw.com> Sat, 20 January 2007 22:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8P0I-0003jq-7Z; Sat, 20 Jan 2007 17:48:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8P0G-0003jg-TU for ietf@ietf.org; Sat, 20 Jan 2007 17:48:05 -0500
Received: from mail26a.sbc-webhosting.com ([216.173.237.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H8P0E-0002XW-Bw for ietf@ietf.org; Sat, 20 Jan 2007 17:48:04 -0500
Received: from mx85.stngva01.us.mxservers.net (198.173.112.2) by mail26a.sbc-webhosting.com (RS ver 1.0.95vs) with SMTP id 4-0140153279 for <ietf@ietf.org>; Sat, 20 Jan 2007 17:47:59 -0500 (EST)
Received: from www.rosenlaw.com [216.173.242.124] (HELO mx85.stngva01.us.mxservers.net) by mx85.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with SMTP id 00b92b54.11962.161.mx85.stngva01.us.mxservers.net; Sat, 20 Jan 2007 17:43:12 -0500 (EST)
Received: from www.rosenlaw.com [216.173.242.124] (EHLO LROSENTOSHIBA) by mx85.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id efa92b54.15784.084.mx85.stngva01.us.mxservers.net; Sat, 20 Jan 2007 17:43:10 -0500 (EST)
From: Lawrence Rosen <lrosen@rosenlaw.com>
To: 'Lakshminath Dondeti' <ldondeti@qualcomm.com>, 'Russ Housley' <housley@vigilsec.com>
References: <7.0.0.16.2.20070117095212.04035c38@vigilsec.com> <45B28AFE.6090204@qualcomm.com>
Date: Sat, 20 Jan 2007 14:45:26 -0800
Organization: Rosenlaw & Einschlag
Message-ID: <021901c73ce4$b2907490$0202fea9@LROSENTOSHIBA>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <45B28AFE.6090204@qualcomm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: Acc824WVVJLaWwVnQS6cyKgn7FIgkwACQfKQ
X-Spam: [F=0.0046677147; heur=0.500(-20100); stat=0.010; spamtraq-heur=0.317(2007010918)]
X-MAIL-FROM: <lrosen@rosenlaw.com>
X-SOURCE-IP: [216.173.242.124]
X-Loop-Detect: 1
X-DistLoop-Detect: 1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Cc: ipsec@ietf.org, saag@mit.edu, ietf@ietf.org
Subject: RE: MUST implement AES-CBC for IPsec ESP
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: lrosen@rosenlaw.com
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

> > For ESP encryption algorithms, the document that was sent out for Last
> > Call contains the following table:
> >
> >       Requirement    Encryption Algorithm (notes)
> >       -----------    --------------------
> >       MUST           NULL (1)
> >       MUST-          TripleDES-CBC [RFC2451]
> >       SHOULD+        AES-CBC with 128-bit keys [RFC3602]
> >       SHOULD         AES-CTR [RFC3686]
> >       SHOULD NOT     DES-CBC [RFC2405] (3)
> >
> > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to
> > "MUST."

Are any of these encryption algorithms patented?

/Larry Rosen

Lawrence Rosen
Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com)
Stanford University, Lecturer in Law
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243
Skype: LawrenceRosen
Author of "Open Source Licensing: Software Freedom and 
                Intellectual Property Law" (Prentice Hall 2004)

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]
> Sent: Saturday, January 20, 2007 1:35 PM
> To: Russ Housley
> Cc: ipsec@ietf.org; saag@mit.edu; ietf@ietf.org
> Subject: Re: MUST implement AES-CBC for IPsec ESP
> 
> What are the export implications due to this?  A compliant ESP
> implementation MUST include the DES cipher due to this change.   With
> status quo, a compliant ESP implementation can be used for integrity
> protection alone with NULL encryption.
> 
> regards,
> Lakshminath
> 
> Russ Housley wrote:
> > During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, we
> > received a comment that deserves wide exposure.
> >
> > For ESP encryption algorithms, the document that was sent out for Last
> > Call contains the following table:
> >
> >       Requirement    Encryption Algorithm (notes)
> >       -----------    --------------------
> >       MUST           NULL (1)
> >       MUST-          TripleDES-CBC [RFC2451]
> >       SHOULD+        AES-CBC with 128-bit keys [RFC3602]
> >       SHOULD         AES-CTR [RFC3686]
> >       SHOULD NOT     DES-CBC [RFC2405] (3)
> >
> > The Last Call comment suggests changing the "SHOULD+" for AES-CBC to
> > "MUST."
> >
> > I support this proposed change, and I have asked the author to make this
> > change in the document that will be submitted to the IESG for
> > consideration on the Telechat on January 25th.  If anyone has an
> > objection to this change, please speak now.  Please send comments on
> > this proposed change to the iesg@ietf.org or ietf@ietf.org mailing lists
> > by 2007-01-24.
> >
> > Russ Housley
> > Security AD
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


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