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

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:
> 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?
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 
> 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: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 02 Feb 2015 12:55:45 -0700

On 2/2/15 12:45 PM, Robert Sparks wrote:
>
> 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.

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

>> 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.

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/