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

[Yaron Sheffer <[e-mail]>]

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

On 02/02/2015 09: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?
>>
>> * 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
>