Skip to main content

Last Call Review of draft-ietf-uta-tls-bcp-08
review-ietf-uta-tls-bcp-08-secdir-lc-waltermire-2015-02-12-00

Request Review of draft-ietf-uta-tls-bcp
Requested revision 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
I-D 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
Request Last Call review on draft-ietf-uta-tls-bcp by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 11)
Result Has nits
Completed 2015-02-12
review-ietf-uta-tls-bcp-08-secdir-lc-waltermire-2015-02-12-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.



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.



Sincerely,

Dave Waltermire