On Apr 07, 2016, at 09:40, Roni Even
<ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com> 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-tls-chacha20-poly1305-04
Reviewer: Roni Even
Review Date:2016–3-28
IETF LC End Date: 2016–4-9
IESG Telechat date:
Summary: This draft is almost ready for publication as a standard track RFC.
Major issues:
I am wondering why this is a standard track document and not informational
since the registration requirements are specification required. (RFC5246)
I’m not sure I agree that Specification Required implies informational track.
Specification Required permits registrations from informational/experimental
drafts, but it certainly doesn’t require informational/experimental.
Also note, the registry rules are:
0-191 Standards Action Refers to value of first byte
192-254 Specification Required Refers to value of first byte
255 Reserved for Private Use Refers to value of first byte
I am also wondering why this document updates RFC5246 and RFC6347. Reading
the document it looked to me that the registration document is used also to
endorse this cypher suite by the IETF and if this is the case my view is that
there should be two documents, one Informational for registration and the
will be standard track and update RFC5246 and RFC6347
For Example the following text from section 1 “Therefore, a new stream cipher
to replace RC4 and address all the previous issues is needed. “ provides
what may look as a normative recommendation.
As far as the updates header:
The RC4 stream cipher which was in TLS1.0-1.2 is now prohibited [RFC7465] (note
not deprecated it’s prohibited) and ChaCha20-Poly1305-based ciphers are the
replacement. So, we do in fact want folks who were using RC4 to switch to
ChaCha20-Poly1305, hence the updates header.
As far as splitting the registrations/updates:
What you’re suggesting is certainly one way to do it, but the way we’ve been
doing it for years in the security area (e.g., TLS, IPSec, S/MIME, PKIX) is as
follows (there have, of course, been exceptions):
- (if needed) Informational RFC for algorithm
- Standards track RFC for how to use algorithm with security protocol. This is
how AES, Camellia, etc. were documented for TLS.
Also in play here is the need to avoid a bunch of DOWNREFs because two of the
ChaCha20-Poly1305 suites are SHOULDs in the draft TLS1.3. DOWNREFs aren’t
anything to be scared of, but where we can avoid them I think we should.
I guess I’d rather not devise new process and just keep on doing what we’ve
been doing.
spt
PS we are currently in the process of discussing a change to make the entire
range (minus the reserved) specification required, but that won’t complete for
a while and the implementers want this now (technically yesterday).