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