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?