Skip to main content

Last Call Review of draft-ietf-tcpm-tcp-ao-crypto-
review-ietf-tcpm-tcp-ao-crypto-secdir-lc-nystrom-2010-03-15-00

Request Review of draft-ietf-tcpm-tcp-ao-crypto
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-03-09
Requested 2010-02-25
Authors Eric Rescorla , Gregory M. Lebovitz
I-D last updated 2010-03-15
Completed reviews Secdir Last Call review of -?? by Magnus Nyström
Assignment Reviewer Magnus Nyström
State Completed
Request Last Call review on draft-ietf-tcpm-tcp-ao-crypto by Security Area Directorate Assigned
Completed 2010-03-15
review-ietf-tcpm-tcp-ao-crypto-secdir-lc-nystrom-2010-03-15-00
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 specifies requirements on cryptographic algorithms to be
used in the TCP Authentication Option (TCP APO). It also specifies
some mandatory algorithms.

Comments:

Abstract:

- The abstract does not mention that the document also specifies
requirements on future algorithms. IMO, it should.

Section 1:
(- Last paragraph is what prompted my comment on the abstract.)

Section 2.2:

- Suggest moving the note explaining the need to mandate two MAC
algorithms to the Security Considerations section as it does not
contain normative text but does contain security considerations.

- Section 3.1.1.3:

- It is a little surprising to see that the SHA-1-based MAC algorithm
is selected as the default one, given that this is a new specification
and the industry is moving away from SHA-1. C.f. the work on XML
Encryption 1.1 and XML Signature 1.1 that specificallly recommends
against use of SHA-1 in new applications.

- Section 6 (Security Considerations):

In the fourth paragraph, there is a discussion around the fact that
the document does not force use of a 16 octet key. I think it would be
useful to at least clearly state a recommended minimum key size.

Editorial:

Section 1:

- "between to endpoints" - "between two endpoints"?

Section 3.1.1:

- "fixed-length output lengths" -> "fixed-length output"?

Section 3.2.1:

- "will be that has" -> "will be that"?

-- Magnus