Last Call Review of draft-merkle-tls-brainpool-02
review-merkle-tls-brainpool-02-secdir-lc-josefsson-2013-07-12-00

Request Review of draft-merkle-tls-brainpool
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-07-16
Requested 2013-06-27
Draft last updated 2013-07-12
Completed reviews Genart Last Call review of -02 by Roni Even (diff)
Genart Telechat review of -04 by Roni Even
Secdir Last Call review of -02 by Simon Josefsson (diff)
Secdir Telechat review of -04 by Simon Josefsson
Assignment Reviewer Simon Josefsson
State Completed
Review review-merkle-tls-brainpool-02-secdir-lc-josefsson-2013-07-12
Reviewed rev. 02 (document currently at 04)
Review result Has Nits
Review completed: 2013-07-12

Review
review-merkle-tls-brainpool-02-secdir-lc-josefsson-2013-07-12

I have reviewed draft-merkle-tls-brainpool-03 and consider the document
to be "Ready with nits".  I support its publication.

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.

I haven't verified the test vectors, but as an implementer I'm happy
that they are present and they improve the credibility of the draft.

I believe the document would be improved by addressing the suggestions
below, but these comments are not critical.

1)

When I read the document, it seems to be missing its "gut".  There is
one section "Introduction" and then you would expect the actual
specification.  But instead comes the Security Considerations and the
rest of the usual IETF boiler plate.  The contribution of this document
is hidden in the IANA Considerations.

In particular, there is no TLS presentation language of the new fields.

Adding new TLS enum types is done by several other documents, and they
usually contain a bit more detail.  Compare how RFC5878 introduces new
enum types in section 2.  For an alternative approach, look at how
rfc6042 introduces new enum types.

Further, I feel it is more appropriate to put the comment about DTLS
compatibility in this new section rather than in the IANA
Considerations.

I would propose to add a new section after "Introduction":

--->>>
2. Brainpool NamedCurve Types

This document adds three new NamedCurve types as follows.

        enum {
	     brainpoolP256r1(TBD1),
	     brainpoolP384r1(TBD2),
	     brainpoolP512r1(TBD3)
        } NamedCurve;

These curves are suitable for use with DTLS [RFC6347].
<<<---

2)

In section 1, remove a whitespace after the RFC5480 citation.  It
causes a comma to appear standalone.

OLD:
   certificates according to [RFC3279] and [RFC5480] , their negotiation
NEW:
   certificates according to [RFC3279] and [RFC5480], their negotiation

/Simon