Subject: MUST implement AES-CBC for IPsec ESP

From: Russ Housley <[email-masked]>
Date: Wed, 17 Jan 2007 10:02:14 -0500

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 [email-masked] or [email-masked] mailing 
lists by 2007-01-24.

Russ Housley
Security AD

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 20 Jan 2007 13:34:54 -0800

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:
> 
> 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 
> this proposed change to the [email-masked] or [email-masked] mailing lists 
> by 2007-01-24.
> 
> Russ Housley
> Security AD
> 
>

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sat, 20 Jan 2007 14:45:26 -0800

> >       Requirement    Encryption Algorithm (notes)

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:[email-masked]]
> Sent: Saturday, January 20, 2007 1:35 PM
> To: Russ Housley
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: MUST implement AES-CBC for IPsec ESP
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 20 Jan 2007 14:54:21 -0800

At 1:34 PM -0800 1/20/07, Lakshminath Dondeti wrote:
>What are the export implications due to this?

Two answers:

- None. TripleDES is already a MUST in RFC 4305, and thus it already 
has a strong crypto requirement.

- Export from which country? To which country? Who knows? Why are you 
asking the IETF's armchair lawyers to start firing up their 
keyboards? :-)

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 20 Jan 2007 18:28:10 -0500

On Sat, 20 Jan 2007 14:45:26 -0800

> Are any of these encryption algorithms patented?

Almost certainly not.  DES was patented, but the patent was never
enforced; it has long since expired.  (Trivia: IBM filed a statement
saying that DES was royalty-free *if* used in one of the NIST-approvedd
modes of operation.  But they never went after anyone who used it in
other ways.)  To my knowledge, 3DES was never patented; even if it had
been, it was first publicly described in 1979, so I doubt that any
patent would still be valid.

AES itself had to be unencumbered; see
http://csrc.nist.gov/CryptoToolkit/aes/pre-round1/aes_9709.htm#sec2d .
The designers of Rijndael never even attempted to patent it; see the
text quoted in RFC 3602 or the old Rijndael home page.

CBC dates from at least 1980 -- I seem to recall 1978, but I don't have
a citation handy.

That leaves CTR mode.  I doubt very much that it's patented, since it's
been very well known for many years and NIST rarely standardizes
patented algorithms in this space (which I know you appreciate...).
However, I don't have any citations to prove this negative.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 20 Jan 2007 18:30:06 -0500

On Sat, 20 Jan 2007 13:34:54 -0800

> protection alone with NULL encryption.

I don't understand your question.  Apart from the Danvers doctrine --
the IETF makes technically sound decisions without regard to politics
-- how do you conclude that DES MUST be included?  The new document
says SHOULD NOT.  

> 
> Russ Housley wrote:
> > During the IETF Last Call for
> > draft-manral-ipsec-rfc4305-bis-errata, we > received a comment that
> > deserves wide exposure.
> > > Last > Call contains the following table: Requirement
> > > Encryption Algorithm (notes)
> > > 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 [email-masked] or [email-masked] mailing lists > by
> > > 2007-01-24. Russ Housley
> > Security AD

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 20 Jan 2007 17:48:30 -0800

Thanks Steve.

Oddly enough I have never heard of 3365 until now.  Apologies to all for 
my posting earlier.

regards,
Lakshminath

---

From: "Contreras, Jorge" <[email-masked]>
Date: Sun, 21 Jan 2007 08:23:01 -0500

Larry,

Please note that any responses to your question "Are any of these encryption algorithms patented?" are being provided by individuals in the spirit of helpfulness and open sharing of information.  Neither IETF nor the IETF Trust provide assurances or advice as to whether or not technology covered by IETF standards are covered by patent claims.  The exclusive mechanism for soliciting and disclosing patent claims within the context of IETF activity is specified in RFC 3979, as we have discussed before.  Please do not take anyone's efforts to respond to your questions as "official" IETF positions, as they are not and may not be relied upon as such.

Regards,
Jorge

> From: Steven M. Bellovin [mailto:[email-masked]]
> Sent: Saturday, January 20, 2007 6:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > > to "MUST."

---

From: "Lawrence Rosen" <[email-masked]>
Date: Sun, 21 Jan 2007 08:01:24 -0800

Jorge Contreras wrote:
> Please note that any responses to your question "Are any of these
> encryption algorithms patented?" are being provided by individuals in the
> spirit of helpfulness and open sharing of information.  Neither IETF nor
> the IETF Trust provide assurances or advice as to whether or not
> technology covered by IETF standards are covered by patent claims.  The
> exclusive mechanism for soliciting and disclosing patent claims within the
> context of IETF activity is specified in RFC 3979, as we have discussed
> before.  Please do not take anyone's efforts to respond to your questions
> as "official" IETF positions, as they are not and may not be relied upon
> as such.

I didn't take anyone's comments on this list as any reassurance of anything
other than their own understanding of the situation. I just asked about
patent coverage because I wondered if anyone knew. This kind of question
comes up at other organizations I work with too. Asking a patent question on
an IETF list should not conflict with the "exclusive mechanism" you
describe.

You should realize that I, perhaps more so than others on this list, would
never rely on helpful and open emails on a public IETF list--no matter how
expert the writers are--for official reassurances about patents,
particularly third party patents. The people here don't read patent claims,
nor should they have to for this purpose. That is in part why I am in favor
of mandatory licensing by contributors in addition to disclosures.

/Larry

> From: Contreras, Jorge [mailto:[email-masked]]
> Sent: Sunday, January 21, 2007 5:23 AM
> To: Steven M. Bellovin; [email-masked]
> Subject: RE: MUST implement AES-CBC for IPsec ESP
> 
> Larry,
> 
> Please note that any responses to your question "Are any of these
> encryption algorithms patented?" are being provided by individuals in the
> spirit of helpfulness and open sharing of information.  Neither IETF nor
> the IETF Trust provide assurances or advice as to whether or not
> technology covered by IETF standards are covered by patent claims.  The
> exclusive mechanism for soliciting and disclosing patent claims within the
> context of IETF activity is specified in RFC 3979, as we have discussed
> before.  Please do not take anyone's efforts to respond to your questions
> as "official" IETF positions, as they are not and may not be relied upon
> as such.
> 
> Regards,
> Jorge
> 
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 22 Jan 2007 13:26:19 +0200

>       Requirement    Encryption Algorithm (notes)

Strangely missing is AES/GCM [RFC4106].

SHOULDn't this be a SHOULD ?

Y(J)S

---

From: Bart Preneel <[email-masked]>
Date: Sun, 21 Jan 2007 00:40:19 +0100 (CET)

Steven,

Counter mode is described in:

W. Diffie and M. E. Hellman, "Privacy and Authentication: An
Introduction to Cryptography," Proceedings of the IEEE,
Vol. 67, March 1979, pp. 397-427.

See Figure 18 on page 417.
http://www-ee.stanford.edu/%7Ehellman/publications/32.pdf

-- Bart Preneel
-------------------------------------------------------------------------------
Katholieke Universiteit Leuven                       tel. +32 16 32 11 48
Dept. Electrical Engineering-ESAT / COSIC            fax. +32 16 32 19 69
Kasteelpark Arenberg 10, B-3001 Leuven-Heverlee, BELGIUM

                             [email-masked]
                          http://www.esat.kuleuven.be/~preneel
-------------------------------------------------------------------------------

> > Are any of these encryption algorithms patented?
[...]
> Ipsec mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipsec
>

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

---

From: Russ Housley <[email-masked]>
Date: Mon, 22 Jan 2007 17:45:45 -0500

>SHOULDn't this be a SHOULD ?

None of the MUST/SHOULD algorithms are authenticated-encryption 
algorithms.  This has not been proposed in the past, and it is very 
late in the processing of this document to propose it now.

I'm pleased to entertain adding it the next time this document is updated.

Russ

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Jan 2007 12:12:20 -0600

On Mon, Jan 22, 2007 at 03:39:38AM -0800, todd glassey wrote:
> Which is why Jorge that the current IP Disclosure model is a joke.
> 
> Ask the simple and rudimentary question as to "What are the implications of 
> not disclosing known IP constraints?" - nothing... are they that the IESG 
> wont let you participate with the IETF any more? Are they that the IP that 
> is underway in a standards process is to be stopped?
> 
> The point is that there is in the real world a consequence to everything - 
> except in the IETF where the consequences have been omitted or eliminated in 
> anything but telling the IETF how screwed up it is.

I don't agree.  The IETF, as an open, non-member, consensus-driven
organization cannot shield the Internet from the vaguaries of patent,
inport, export, and other laws around the world.  It can only apply its
stamp of approval (in the form of Standards Tack labels on
specifications published by the RFC-Editor), or else withhold its
approval.  And it can demand disclosure of specification author's
knowledge of IPR claims.

That's about it, that's about all the IETF can do.  Get over it.

Why are we having this discussion here, now?

What does this have to do with this particular I-D?

And the irony is that the risk of future IPR claims w.r.t. the
technologies promoted in this I-D is as near zero as we could get to.

Nico
--

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 22 Jan 2007 16:58:10 -0800

Hi Yaakov,

The following new text has been added to the draft.
http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-03.txt

Although there are no suggested or required combined algorithms at
this time,   AES-CCM [RFC4309] and AES-GCM [RFC4106] are of interest.
AES-CCM has been adopted as the preferred mode in IEEE 802.11
[802.11i], and AES-   GCM has been adopted as the preferred mode in
IEEE 802.1ae [802.1ae].

Actually till version02 of the draft, I had a todo list(Appendix A.)
which contained updating the status of new algorithms as one of the
points in the agenda. However as I got no feedback on the same from
the list, I did not go ahead and add any nenw algorithm status.

Thanks,
Vishwas