[Gen-art] Gen-art review of draft-manral-ipsec-rfc4305-bis-errata-02.txt

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Please resolve these comments along with any other Last Call comments
you may receive.

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

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art