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