Gen-Art LC review: draft-ietf-uta-tls-bcp-08

[Robert Sparks <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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?