> On Apr 07, 2016, at 09:40, Roni Even <ron.even....@gmail.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). _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
