Hi Sean,
Inline
Roni
> -----Original Message-----
> From: Sean Turner [mailto:[email protected]]
> Sent: Friday, April 08, 2016 3:27 PM
> To: Roni Even
> Cc: [email protected] list; [email protected]; draft-ietf-tls-chacha20-
> [email protected]
> Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 -
> resend
>
>
> > On Apr 07, 2016, at 09:40, Roni Even <[email protected]> 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).
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
