Last Call Review of draft-ietf-uta-tls-bcp-08

Request Review of draft-ietf-uta-tls-bcp
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-02-10
Requested 2015-01-29
Authors Yaron Sheffer, Ralph Holz, Peter Saint-Andre
Draft last updated 2015-02-12
Completed reviews Genart Last Call review of -08 by Robert Sparks (diff)
Genart Telechat review of -09 by Robert Sparks (diff)
Secdir Last Call review of -08 by David Waltermire (diff)
Assignment Reviewer David Waltermire
State Completed
Review review-ietf-uta-tls-bcp-08-secdir-lc-waltermire-2015-02-12
Reviewed rev. 08 (document currently at 11)
Review result Has Nits
Review completed: 2015-02-12


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.


Summary: This proposed BCP outlines a number of security issues related to use of various revisions of TLS and DTLS. It details a number of attacks against various versions of TLS, cipher suites, and modes of operation; and provides recommendations
 to avoid these attacks in a way that is applicable to the majority of use cases for these protocols.


This document is generally well-written and clear in its content. I find this document to be ready with nits.


My only nit is a minor ambiguity in the text in section 4.2.1. Two of the “SHOULD” statements seem to be in conflict (#2 and #3) by my read:


#1 Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the

   first proposal to any server, unless they have prior knowledge that

   the server cannot respond to a TLS 1.2 client_hello message


#2 Servers SHOULD prefer this cipher suite whenever it is proposed, even

   if it is not the first proposal.


#3 Clients are of course free to offer stronger cipher suites, e.g.,

   using AES-256; when they do, the server SHOULD prefer the stronger

   cipher suite unless there are compelling reasons (e.g., seriously

   degraded performance) to choose otherwise.


The way I read it, if statement #2 is honored, then statement #3 would not be honored, even if the stronger cipher suite is ordered before the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I don’t think this is the intent!


It would be better to qualify statement #2 with regards to weaker cipher suites to avoid weaker proposals, while allowing stronger proposals.



Dave Waltermire