Document: draft-manral-ipsec-rfc4305-bis-errata-02.txt Reviewer: Elwyn Davies Review Date: 12 December 2006 IETF LC End Date: 4 January 2007 IESG Telechat date: (if known) - Summary: My comments are significantly longer than the actual changes made to this document since RFC 4305. Doh! The document states that it updates RFC4305 but I believe that it it obsoletes it - the substantive content either duplicates or replaces RFC4305, and there is additional material. It would be better to provide a separate section detailing the changes relative to RFC4305 rather than conflating them with the changes between RFCs 2402/2406 and RFC 4305 (and it partially duplicates Appendix B). I will leave the discussion of the rights and wrongs of downgrading the NULL algorithm for AH to a 'MAY' to the security experts. The whole new section entitled 'Application Support' seems problematic. The document also needs some editorial cleanup before going to the IESG. Also there is an item called out in Appendix A which may indicate that there is something missing but I suspect that this represents a problem with the appendix rather than a real missing item. Issues: Section 4: Reading this section naively I was thinking this is about what an application can use - the first paragraph seems to support this view but the second paragraph goes off into the weeds and seems to be talking about what happens in real implementations of the IPsec layer. I think this is poor wording and maybe a misleading title. Would 'Application Expectations' be more appropriate? The second paragraph certainly needs more work. It states: Any application using ESP or AH should use the algorithm supported in this document. However an application can mandate the support of a more stringent set of algorithm support as well as add support for new algorithms, however the application cannot make the requirements more lenient(i.e. MUST cannot be made a MAY or a SHOULD though a SHOULD and a MAY can be made to a MUST). Comments: Sentence 1: 'the algorithm'? There is more than one. Is this trying to say 'An application will be most likely to have its requirements from the IPsec layer if it requests one of the MUST algorithms'? Well it should be motherhood and apple pie. Sentence 2, clause 1: Reword to make it clear that the mandate is about what the application will accept rather than mandating changes to the IPsec layer. The phrase 'a more stringent set of algorithm support' is unclear - is this just saying the application can be written to accept only a subset of the potentially supported algorithms? An application cannot 'add support' for new algorithms (one reading would be that this was adding new algorithms to those implemented in the IPsec layer). It could 'require support' or 'prefer support' of new (presumably cryptographically stronger) algorithms. Sentence 2, clause 2: I am at a loss to see how an application can affect the algorithm requirements in any way. Are we just saying that an application cannot expect to have its requirements met in all cases if it exclusively mandates the use of 'MAY' algorithms? Assuming we need to say it at all, I *think* (but am not exactly sure) that the second para could be redrafted as: An application SHOULD (MUST?) expect to be able to express preferences about the ESP and AH algorithms to be used for its messages. An application SHOULD be able to constrain the choices of algorithms used for its messages and MAY request the use of alternative (generally cryptographically stronger) algorithm(s) that might be supported by an implementation of IPsec. An application that does not include any of the mandatory to implement algorithms in its set of allowed algorithms cannot expect to communicate successfully on all IPsec implementations. Is Appendix A correct? It states: Appendix A. To be done o Support for any new algorithms and updating state for existing algorithms. I think that this has been done, so either remove it or action it if I am wrong! A number of editorial fixes are needed - Sort out the section numbering in the table of contents (two Section 4's currently!) - Sort out the references as noted in the warnings from idnits (copied below). Also, the document (US Government Federal Register (Docket No. 040602169-4169-01)) referred to in Section 7 probably ought to be a reference. (although this is a hangover from RFC4305 so I won't press this one). - Sort out the formatting and remove non-ASCII characters as per idnits plus checking the page end flag characters from the end of page 5 onwards (they aren't formfeeds). - Add (null) IANA requirements section - Reduce the length of the abbreviated title (it doesn't fit on the header line) - Add RFC Editor note instructing removal of appendices before publication. - Integrating the changes made in this document and RFC 4305 is confusing - and duplicates Appendix B. * Change the title of Section 7 - 'Changes from RFC 2402 and 2406 to RFC 4305' and return it to the text of RFC4305. * Replace Appendix B with a main body section recording the changes from RFC4305. - The comment in Section 7 (duplicated from RFC4305) is factually incorrect in this document: 'But this document represents the first standards-track recognition of that deprecation'. Replace 'this document represents' by 'RFC 4305 represented'. - Section 5 title should now be 'Acknowledgments' (plural) idnits 1.121 tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt: tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(10): Found control character TAB in position 1. tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(80): Line is too long: the offending characters are '0' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(81): Line is too long: the offending characters are '0' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(271): Line is too long: the offending characters are 're' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(274): Line is too long: the offending characters are 'LD' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(309): Line is too long: the offending characters are 'ent' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(310): Line is too long: the offending characters are 'raphic' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(317): Found non-ascii character ( ) in position 54. tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(493): Line is too long: the offending characters are ',' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(493): Found non-ascii character ( ) in position 50. tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(536): Line is too long: the offending characters are 'lgorithms.' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(546): Line is too long: the offending characters are 'sion' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(551): Line is too long: the offending characters are 'NULL' tmp/draft-manral-ipsec-rfc4305-bis-errata-02.txt(554): Line is too long: the offending characters are 'or SHA-1' Checking nits according to http://www.ietf.org/ID-Checklist.html: * The document seems to lack an IANA Considerations section. Checking conformance with RFC 3978/3979 boilerplate... - This document has ISOC Copyright according to RFC 3978, instead of the newer IETF Trust Copyright according to RFC 4748. You should consider updating it; the new Copyright statement will be required from February 1st, 2007 - This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. You should consider updating it; the new disclaimer will be required from February 1st, 2007 Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 60 lines Miscellaneous warnings: - The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 paragraph 2 text: "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119." (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). Experimental warnings: [Added by Elwyn Davies: The warnings about IKEv2 and RFC2409 are spurious.] - Missing Reference: 'RFC2451' is mentioned on line 161, but not defined 'MUST- TripleDES-CBC [RFC2451]...' - Unused Reference: 'IPsec' is defined on line 322, but not referenced '[IPsec] Kent, S., "Security Architecture for the Internet Proto...' - Unused Reference: 'JIS' is defined on line 356, but not referenced '[JIS] Schiller, J., "Cryptographic Algorithms for Use in the...' - Unused Reference: 'IKEv2' is defined on line 366, but not referenced '[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protoc...' - Unused Reference: 'RFC791' is defined on line 369, but not referenced '[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, Septem...' - Unused Reference: 'RFC2409' is defined on line 381, but not referenced '[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (...'