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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]