Hi Sean,
Inline
Roni
-----Original Message-----
From: Sean Turner [mailto:sean(_at_)sn3rd(_dot_)com]
Sent: Friday, April 08, 2016 3:27 PM
To: Roni Even
Cc: ietf(_at_)ietf(_dot_)org list; gen-art(_at_)ietf(_dot_)org;
draft-ietf-tls-chacha20-
poly1305(_dot_)all(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 -
resend
On Apr 07, 2016, at 09:40, Roni Even
<ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)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–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).