From: "Roni Even" <ron.even.tlv@gmail.com>
To: "'Sean Turner'" <sean@sn3rd.com>
References: <017a01d190ca$ace223b0$06a66b10$@gmail.com>
 <A8A038B3-E10F-4A94-99D3-2C4D23A6E065@sn3rd.com>
In-Reply-To: <A8A038B3-E10F-4A94-99D3-2C4D23A6E065@sn3rd.com>
Subject: RE: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend
Date: Fri, 8 Apr 2016 17:36:51 +0300
Message-ID: <00d901d191a4$185fa340$491ee9c0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQIM3GM2urfPwNWEbUqsemq3RkNvLQCQN/CbnwUH76A=
Content-Language: he
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/7cv9u5iYrHrdSBRfjZG_BlscSwk>
Cc: gen-art@ietf.org, draft-ietf-tls-chacha20-poly1305.all@ietf.org,
 ietf@ietf.org
Precedence: list

Hi Sean,
Inline
Roni

> -----Original Message-----
> From: Sean Turner [mailto:sean@sn3rd.com]
> Sent: Friday, April 08, 2016 3:27 PM
> To: Roni Even
> Cc: ietf@ietf.org list; gen-art@ietf.org; draft-ietf-tls-chacha20-
> poly1305.all@ietf.org
> Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 =
-
> resend
>=20
>=20
> > On Apr 07, 2016, at 09:40, Roni Even <ron.even.tlv@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=E2=80=933-28
> >
> > IETF LC End Date: 2016=E2=80=934-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)
>=20
> I=E2=80=99m not sure I agree that Specification Required implies =
informational track.
> Specification Required permits registrations from
> informational/experimental drafts, but it certainly doesn=E2=80=99t =
require
> informational/experimental.
>=20
> Also note, the registry rules are:
>=20
> 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.
>=20
> > 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 =E2=80=9CTherefore, a =
new stream
> cipher to replace RC4 and address all the  previous issues is needed. =
=E2=80=9C
> provides what may look as a normative recommendation.
>=20
> As far as the updates header:
>=20
> The RC4 stream cipher which was in TLS1.0-1.2 is now prohibited =
[RFC7465]
> (note not deprecated it=E2=80=99s 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.
>=20
> As far as splitting the registrations/updates:
>=20
> What you=E2=80=99re suggesting is certainly one way to do it, but the =
way we=E2=80=99ve 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):
>=20
> - (if needed) Informational RFC for algorithm
>=20
> - 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?




>=20
> 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=E2=80=99t anything to be scared of, but where we can avoid them I =
think we
> should.
>=20
> I guess I=E2=80=99d rather not devise new process and just keep on =
doing what we=E2=80=99ve
> been doing.
>=20
> spt
>=20
> PS we are currently in the process of discussing a change to make the =
entire
> range (minus the reserved) specification required, but that =
won=E2=80=99t complete
> for a while and the implementers want this now (technically =
yesterday).