Hi Sean, Inline Roni > -----Original Message----- > From: Sean Turner [mailto:sean@xxxxxxxxx] > Sent: Friday, April 08, 2016 3:27 PM > To: Roni Even > Cc: ietf@xxxxxxxx list; gen-art@xxxxxxxx; draft-ietf-tls-chacha20- > poly1305.all@xxxxxxxx > Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - > resend > > > > On Apr 07, 2016, at 09:40, Roni Even <ron.even.tlv@xxxxxxxxx> 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 [Roni Even] So I would like to assume that there was a reason to have two different policies so why not follow it. > > > 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. [Roni Even] So this is the standard track RFC, I still do not get it >From RFC4346 a.5 "Cipher suite values with first byte decimal 192 (0xC0) through decimal 254 (0xFE) inclusive are reserved for assignment for non-Standards Track methods." So this is the reason to have the registration as non standard document. I looked at Camellia and it follows your explanation except for updating the TLS specification yet it uses the first byte from the range 0-191. So my question will be why did you use the first byte from 192 - range? > > 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).