Subject: Review of draft-manral-ipsec-rfc4305-bis-errata-02.txt

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Dec 2006 09:55:33 -0600

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document is an update to RFC4305 (Cryptographic Algorithm
Implementation Requirements for ESP and AH).  Its primary purpose appears
to be to change the requirement of the NULL AH algorithm from 'MUST
implement' to 'MAY implement'.  The rationale for this change is not
explained; it should be.

Summary of this review: this document has no significant problems and
could progress provided that a rationale for the primary change made to
RFC4305 is explained and that other comments below are addressed.  It's
possible that of my comments relating to the use of MUST-/SHOULD+ may
lead to further changes from RFC4305; this should be discussed on the
IETF mailing list.

Other changes:

 - Text has been added explaining that attacks on SHA-1's collision resistance
   are now known, but that these attacks do not affect the security of
   HMAC-SHA-1.

 - A section was added on application-specific ESP/AH algorithm
   implementation requirements.  The text allows application protocols
   to add algorithm implementation requirements or to upgrade MAY/SHOULD
   requirements in RFC4305/RFC4305bis to SHOULD/MUST, but it does not
   allow relaxing MUST implement algorithms.

   Nothing is said as to whether applications can relax SHOULD NOT
   implement requirements.  Specifically DES-CBC is a SHOULD NOT
   implement algorithm.  Perhaps text should be added forbidding the
   relaxation of SHOULD NOT requirements; certainly the issue should be
   clarified.

 - Informative references about collisions in MD5 and SHA-1 have been
   added.

The security considerations section appears to be unchanged, and by and
large the other changes made in this I-D should not require security
section changes.  However, I find it odd that the body of the RFC and
I-D says that the NULL algorithms MUST NOT be used in AH and ESP at once
but no text explains why (besides there may be security considerations
about using certain ESP algorithms with the NULL AH algorithm).  If this
is explained in some other RFC then a reference to it would be useful;
if not then please add security considerations text explaining the
matter.

Also, I'm not sure that the use of "MUST-" and "SHOULD+" is actually
useful.  In this update no algorithms previously classified as MUST-
have been downgraded, and no algorithms previously classified as SHOULD+
have been upgraded.  It seems likely to me some AES cipher mode will
eventually become a MUST, but it's not clear to me that AES-CBC, for
example, which is marked SHOULD+, will be it.  Therefore I would argue
that these designations should be changed to MUST and SHOULD,
respectively.  Or perhaps this I-D is a good opportunity to downgrade
TripleDES-CBC to SHOULD or MAY and upgrade either AES-CBC and/or AES-CTR
to MUST?

Editorial comments:

 - Non-ASCII codepoints appear in this document in several places.

 - Grammar problems, here and there, particularly in Appendix B.

 - The table of contents section numbering is incorrect.  At least one
   section reference from the text is incorrect.  I recommend use of
   nroff or xml2rfc.

 - Appendix A is not useful; it should be removed.

 - Appendix B should be integrated into the "Changes from RFC 2402 and
   2406" section (which should now be titled "Changes from RFCs 2402,
   2406 and 4305").

Cheers,

Nico
-- 

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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 11 Dec 2006 11:08:10 -0500

On Mon, 11 Dec 2006 09:55:33 -0600
Nicolas Williams <[email-masked]> wrote:

> have been downgraded, and no algorithms previously classified as
> SHOULD+ have been upgraded.  It seems likely to me some AES cipher
> mode will eventually become a MUST, but it's not clear to me that
> AES-CBC, for example, which is marked SHOULD+, will be it.  Therefore
> I would argue that these designations should be changed to MUST and
> SHOULD, respectively.  Or perhaps this I-D is a good opportunity to
> downgrade TripleDES-CBC to SHOULD or MAY and upgrade either AES-CBC
> and/or AES-CTR to MUST?
> 

I'm not sure it's feasible yet to make 3DES a SHOULD; it's quite clear
to me that AES-CBC should become a MUST.  We can't make AES-CTR the
only MUST unless we abolish manual keying.  I could probably deal with
AES-CTR and AES-CBC both being mandated, but I'm really not a fan of
counter mode; it's just too easy to make bad mistakes.

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Dec 2006 15:19:33 -0600

On Mon, Dec 11, 2006 at 12:38:58PM -0800, Vishwas Manral wrote:
> Hi Nicolas,
> 
> I agree with a lot of the comments. Some minor doubts are in-lined:
> Nicolas Williams wrote:
> Its an interesting note and I understand the concern. Would adding text 
> like "Similarly SHOULD-NOT and MUST-NOT cannot be made a MAY either" help?

Yes, something like that would be fine.  My suggestion:

   Similarly SHOULD-NOT implement algorithms cannot be recommended or
   required by applications.

There's no need to say anything about MUST-NOT algorithms since there
aren't any.

> I hope I understand what you are pointing to. Though the text has been 
> carried from RFC4305, I feel it is an obvious requirement for the use of 
> IPsec (at least one of the crypto algorithm needs to be enabled). Or are 
> you looking for the rationale of making the NULL Authentication 
> algorithm from a MUST to a MAY? I guess RFC4301 talks about that clearly.

I don't think it's entirely obvious, and I think I may be missing some
historical background.

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.

So it makes sense to recommend against use of the NULL AH algorithm
generally.

But I suspect that confidentiality without integrity protection was once
somewhat common, thus the NULL AH.  My guess is that the requirement
that NULL ESP and NULL AH not be used together comes from such a time.

But what really should be said is that NULL AH should not be used,
period.

This should be explained.  It's not your fault that RFC4305 didn't
explain it.

> I agree with Steven here, for CTR mode one of the security consideration 
> is that the same starting point should never be used twice. I am ok, 
> making the CBC as well as CTR mode a SHOULD+. The couple of IPsec 
> implementations I have worked on, we have got the requirement for 
> AES-CBC as well as AES-CTR modes.

Steven answered my concern.  Perhaps the MUST-/SHOULD+ isn't all that
useful in terms of predicing what those requirements/recommendations
will be in the future.  Oh well.  I withdraw my comment.

> I have this doubt. Should we check the changes from RFC2402 and RFC2406 
> to the new draft, or should we make the changes in two steps i.e. from 
> RFC2402 and RFC2406 to RFC4305 and then from RFC4305 to the new draft. I 
> thought the latter approach was better?

What I meant is that the changes made to RFC4305 should be listed in the
same section as (or sub-section of) the section that lists changes since
earlier RFCs.

I guess two tables, or multiple additional rows in the existing table in
that section, will do.  I don't care which it is.  And perhaps the
RFC-Editor would do that work anyways(?).

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Mon, 11 Dec 2006 17:30:26 -0500

>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.

Russ

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 11 Dec 2006 16:34:54 -0600

> 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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Dec 2006 17:50:20 -0500

On Monday, December 11, 2006 04:34:54 PM -0600 Nicolas Williams 
<[email-masked]> wrote:

>> > IPsec used to provide integrity or confidentiality+integrity
>> > protection, but not really just confidentiality protection.
>>

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

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 11 Dec 2006 12:38:58 -0800

Hi Nicolas,

Thanks,
Vishwas

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 12 Dec 2006 17:06:34 -0600

> be silly, having them for debugging can be terribly useful.

The RFC and I-D say:

|   (1) Since ESP encryption is optional, support for the "NULL"
|       algorithm is required to maintain consistency with the way
|       services are negotiated. Note that while authentication
|       and encryption can each be "NULL", they MUST NOT both be
|       "NULL".

Is this for implementors?  Doesn't this conflict with Russ' point about
debugging?  I suspect that the "MUST NOT" I quote above should really be
a lower-case "must not" or "should not, except for debugging, "...

Anyways, the rationale for downgrading NULL AH from MUST implement to
MAY implement should be given.  It's quite simple, I'm sure:

   The NULL AH algorithm has been downgraded to "MAY implement" because
   integrity protection should always be used where IPsec is used.  Thus
   an AH algorithm that does not, in fact, provide integrity protection,
   is not useful (except for debugging purposes), and is not needed for
   interoperability.

Finally, a bit of security considerations text:

   Except for debugging purposes, where IPsec is used it should be used
   to privde at least integrity protection.  Therefore the NULL AH
   algorithm is generally not useful, except for debugging.  Use of the
   NULL AH algorithm in conjunction with the NULL ESP algorithm results
   in no protection whatsoever, and so should be avoided except for
   debugging purposes.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 13 Dec 2006 07:01:59 -0600

On Tue, Dec 12, 2006 at 03:38:40PM -0800, Vishwas Manral wrote:
> Hi Nico,
> 
> I guess there is no denying the points that have been put forward about 
> the use of NULL both authentication and encryption algorithms for ESP in 
> debugging.
> 
> RFC4301 already clearly states:
> 
>   Note: A compliant implementation MUST NOT allow instantiation of an
>   ESP SA that employs both NULL encryption and no integrity algorithm.

Ah.  Then just add reference to RFC4301, section 4.2, in parenthesis.
That should sufifce.

Thanks,

Nico
--