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

[Peter Saint-Andre - &yet <[e-mail]>]

On 2/2/15 12:45 PM, Robert Sparks wrote:
>
> On 2/2/15 1:27 PM, Peter Saint-Andre - &yet wrote:
>> 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?
> (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.

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