Last Call Review of draft-iab-crypto-alg-agility-06
review-iab-crypto-alg-agility-06-secdir-lc-johansson-2015-08-06-00

Request Review of draft-iab-crypto-alg-agility
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-08-17
Requested 2015-07-23
Draft last updated 2015-08-06
Completed reviews Genart Last Call review of -06 by Suresh Krishnan (diff)
Genart Telechat review of -07 by Suresh Krishnan (diff)
Secdir Last Call review of -06 by Leif Johansson (diff)
Assignment Reviewer Leif Johansson
State Completed
Review review-iab-crypto-alg-agility-06-secdir-lc-johansson-2015-08-06
Reviewed rev. 06 (document currently at 08)
Review result Has Issues
Review completed: 2015-08-06

Review
review-iab-crypto-alg-agility-06-secdir-lc-johansson-2015-08-06

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 with the intent of improving
security requirements and considerations in IETF drafts.  Comments
not addressed in last call may be included in AD reviews during the
IESG review.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document is almost ready to go. I have a couple of issues:

1. Section 3.1 has a certain poetic quality to it but the use of
the word "ought" ought perhaps be replaced with normative language
unless this is a novel attempt to avoid RFC2119 terms :-)

2. Sections 3.2 and 3.3 should in some way relate back to the
recommendation to specify algorithm choices separately from base
protocol specifications (esp. since 3.2 suggests that this practice
can drive added complexity in the form of algorithm/suite overload)


I also have some stylistic comments below, feel free to use or
ignore as you see fit:

-- minor nits --

1. Introduction, second paragraph, second sentence

current text:

As new cryptanalysis techniques are developed and computing capabilities
improve, the work factor to break a particular cryptographic
algorithm will reduce, becoming more feasible for more attackers.

suggested:

As new cryptanalysis techniques are developed and computing capabilities
improve, the work required to break a particular cryptographic
algorithm (aka the work factor) will reduce, making an attack on
the algorithm feasible for more attackers.

2.1 Algorithm Identifiers, first paragraph, first sentence

current text:

IETF protocols that make use of cryptographic algorithms MUST support
one or more algorithm or suite identifier.

suggested:

IETF protocols that make use of cryptographic algorithms MUST support
one or more identifier denoting an algorithm or suite of algorithms.

2.2 Mandatory-to-Implement Algorithm, second paragraph, second sentence

current text:

To achieve this goal, the base protocol specification includes a
reference to a companion algorithms document, allowing the update of
one document without necessarily requiring an update to the other.

suggested:

To achieve this goal, it is suggested that the base protocol
specification include a reference to a companion algorithms
document, allowing the update of one document without necessarily
requiring an update to the other.

2.6 Preserving Interoperability, first paragraph

s/is very hard/is very difficult/
s/an long support/on long support/

second paragraph

s/but preserving/but preserve/

2.7 Balance Security Strength, first paragraph

s/considered in making the selection/considered when making the selection/

s/that are deploying and configuring/who are deploying and configuring/

This section uses "deployment and configuration" (etc) a lot. It may be
equally clear to just write "deployment"

final paragraph: s/which is in turn/which in turn is/