Subject: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend

From: "Roni Even" <[email-masked]>
Date: Thu, 7 Apr 2016 15:40:30 +0300

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 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.

Minor issues:

Nits/editorial comments:

---

From: Sean Turner <[email-masked]>
Date: Fri, 8 Apr 2016 09:26:41 -0300

> 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.
> 
> 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).

---

From: "Roni Even" <[email-masked]>
Date: Fri, 8 Apr 2016 17:36:51 +0300

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
> 
> 
> > I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
> > 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.
> 
[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. “
> 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.
> 
> 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):
> 
> - 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.
> 
> 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).