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

[Robert Sparks <[e-mail]>]

On 2/2/15 1:55 PM, Peter Saint-Andre - &yet wrote:
> 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.
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.
>
> Peter
>