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

[Robert Sparks <[e-mail]>]

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.
>>
>> * 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.
>
> Thanks again,
>
> Peter
>