I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-uta-tls-bcp-08 Reviewer: Robert Sparks Review Date: 2 Feb 2015 IETF LC End Date: 10 Feb 2015 IESG Telechat date: 19 Feb 2015 Summary: Basically Ready for publication as BCP, but with nits that should be considered before publication. This is a well structured and fairly easy to follow document. The intended status (BCP, as opposed to, say, AS) is exactly right. There are a few nits that should be considered: Larger nits: * Section 3.1.1 says "SHOULD NOT negotiate TLS version 1.1", but section 3.1.2 says "MAY negotiate DTLS 1.0", and goes on to say "Version 1.0 of DTLS corresponds to version 1.1 of TLS". This seems inconsistent. Should that MAY be a SHOULD NOT? * In section 4.1, you have requirements like "MUST NOT negotiate RC4". This formulation is good in that it doesn't say anything about implementing algorithms like RC4 or not. There will be natural pressure to stop implementing algorithms you must not use. But it feels problematic when you use the same structure at "MUST NOT negotiate the cipher suites with NULL encryption". Would it be worth pointing out here that this isn't a suggestion to push back on _implementing_ such cipher suites? * Since Pete's the sponsoring AD, I have to point at the MUST in section 5.1 as something that should be changed to not use a 2119 word. I suggest replacing the sentence with something like "If deployers deviate ... they are almost certainly giving up one of the foregoing..." Very small nits: * In the last paragraph of 3.1.1, "This BCP applies to TLS 1.2" could be misconstrued to mean it does not apply to the other protocols listed above it (like TLS 1.1). Its point is to say that the document doesn't consider _future_ versions. Perhaps something like "This BCP applies to the protocol listed above, ending with TLS 1.2" instead? * In the second bullet in 3.2 it's not clear whether you're saying _all_ Application clients SHOULD use TLS by default, or if you meant to constrain that recommendation to clients that have a configuration option to use TLS even if the server doesn't offer it. * In section 3.5's last sentence, "may be simplest" is not clear. Does simple mean "easy to code" or "less likely to make it less secure" or something else? Would "may be safest" (or safer) say what you want? * Section 4.1 first paragraph: The second sentence is convoluted. Can it be split into simple sentences? * Section 4.1 first paragraph: The third sentence feels like it's arguing for having the document - "much needed" was particularly catching. Could it be replaced with something more like "this document provides recommendations based on the the experience obtained over these decades"? * Section 4.2, last paragraph before entering 4.2.1: "This BCP does not cover such devices." is ambiguous. It's not clear if it was intended to only be talking about "devices that do not support public key cryptography at all" (which is what was intended, I believe), or if it includes "devices (that) have hardware support for AES-CCM but not AES-GCM. * Section 4.3: Is there a reference you can point to for the authority for "sufficient for at least the next 10 years", or is it the intent that this document become that authoritative statement? * The Applicability Statement (in section 5) says things like "web servers" where perhaps it should say "web services"?. There are a lot of client recommendations in the document. The section also seems to scope the audience firmly to operators, but you have some implementer and a little bit of user guidance in here as well. * There is a word missing near "allow to derive" in the second to last paragraph of 7.3 * The first paragraph of 7.5 has an unusual tone for a BCP (and for the rest of this document). It says (paraphrasing) "we can't recommend anything", but then goes on to recommend things. Perhaps it would work better reformulated as "The following recommendations represent the current state of the art, even though this is not a complete and efficient solution for..." * The discussion of OCSP stapling in the second to last paragraph of 7.5 has suffered some edit-itis? It seems to say SHOULD support OCSP stapling in both the first and third sentences. * The target of "foregoing considerations" in the last paragraph of 7.5 is ambiguous. Do you mean all of 7.5? * Some of the normative vs informative reference choices are puzzling. Why, for instance, is 6167 (prohibiting SSLv2) normative, while tls-prohibiting-rc4 is informative. Why are the references to things like TLS 1.0 informative while TLS 1.2 is normative?