Subject: [Gen-art] Gen-Art LC review: draft-ietf-uta-tls-bcp-08

From: Robert Sparks <[email-masked]>
Date: Mon, 02 Feb 2015 13:03:42 -0600

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?

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 02 Feb 2015 12:27:55 -0700

Hi Robert, thanks for the review. Comments inline.

On 2/2/15 12:03 PM, Robert Sparks wrote:
> * 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?
Your suggestion seems reasonable to me. I have a vague recollection that 
we had talked about making just that change (and apparently neglected to 
do so), but I will double-check with my co-authors to verify.
> 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?
Are you (a) noting that we might want to be explicit about the fact that 
we're not talking about implementation of such suites, or (b) suggesting 
that we might want to say something stronger by actively discouraging 
implementation of such 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..."
Yes, something along those lines would be better.
> Very small nits:
The authors will work to improve the text on the points you have raised. 
If you would like us to propose text for each of these points in this 
email thread rather than through a revised I-D, let us know.

Thanks again,

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 02 Feb 2015 21:42:30 +0200

Hi Robert, Peter,

I don't recall a previous discussion of DTLS 1.0. But after looking at 
http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security#Implementations, 
I agree that we should mandate DTLS 1.2 and make DTLS 1.0 a SHOULD NOT, 
similarly to older versions of TLS.

Thanks,
	Yaron

---

From: Robert Sparks <[email-masked]>
Date: Mon, 02 Feb 2015 13:45:08 -0600

On 2/2/15 1:27 PM, Peter Saint-Andre - &yet wrote:
> Your suggestion seems reasonable to me. I have a vague recollection 
> that we had talked about making just that change (and apparently 
> neglected to do so), but I will double-check with my co-authors to 
> verify.
>>
>> * In section 4.1, you have requirements like "MUST NOT negotiate 
>> RC4". This formulation is good in that it doesn't say anything about 
> Are you (a) noting that we might want to be explicit about the fact 
> that we're not talking about implementation of such suites, or (b) 
> suggesting that we might want to say something stronger by actively 
> discouraging implementation of such suites?
(a).
In particular, I don't think you _want_ to discourage implementation of 
those suites. You may want the code out there for debugging purposes. 
You just want to be sure the deployed code is configured to not 
negotiate them.
> The authors will work to improve the text on the points you have 
> raised. If you would like us to propose text for each of these points 
> in this email thread rather than through a revised I-D, let us know.
I think a revised I-D is the better way to go.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 02 Feb 2015 12:55:45 -0700

> You just want to be sure the deployed code is configured to not

Agreed, I just wanted to make sure we're on the same page.

> I think a revised I-D is the better way to go.

A revised I-D is always a good idea - I was curious to know whether in 
addition you wanted to see proposed text before then.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Robert Sparks <[email-masked]>
Date: Mon, 02 Feb 2015 13:59:37 -0600

> addition you wanted to see proposed text before then.
I don't think it's necessary, and am happy to wait for an iteration of 
the draft.
Of course, if you want earlier feedback on something specific, I'm ready 
to help.