Subject: RE: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend
From: "Roni Even" <[email-masked]>
To: "'Sean Turner'" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 8 Apr 2016 17:36:51 +0300
List-Id: IETF-Discussion <ietf.ietf.org>

Hi Sean,
Inline
Roni

> -----Original Message-----
> From: Sean Turner [mailto:[email-masked]]
> Sent: Friday, April 08, 2016 3:27 PM
> To: Roni Even
> Cc: [email-masked] list; [email-masked]; draft-ietf-tls-chacha20-
> [email-masked]
> Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 -
> resend
> 
> 
> > On Apr 07, 2016, at 09:40, Roni Even <[email-masked]> 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).