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