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

Sean Turner <> Fri, 08 April 2016 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E512412D8B4 for <>; Fri, 8 Apr 2016 05:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W1UYJ8Gx1fqH for <>; Fri, 8 Apr 2016 05:26:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 359C812D837 for <>; Fri, 8 Apr 2016 05:26:48 -0700 (PDT)
Received: by with SMTP id c6so88586512qga.1 for <>; Fri, 08 Apr 2016 05:26:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d/GZrknrflgUFjPfkoWQVMH/hAUD9U9vwoDTsIFfa8I=; b=WrCEwpbHu7JUz653qrMuaa01rE5JDxpyTZvH7iarnJ09QwdiIJH2n1V73BLKlw2/R5 LRgvSA7J2sURHKG+fEj7mQ04RWNhzeZtJW33jz4f86VpF067kGjIOBCDN9TW/dbKNV/K 4JshlNGQ9JiCsz6RZTan8Ft9DIcXP8o+DvV94=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d/GZrknrflgUFjPfkoWQVMH/hAUD9U9vwoDTsIFfa8I=; b=f9jlf/HBLyjFwXK2PZC/jFjWE6jad+AS54afsNE2zNRV6gdnCtkia2ecdr8tZL2EnC PEjbEVDS2Q9+rB95FD6s61RV+5bCIwfMNl/AdWizj1gyUNXz+eWybXCMhI0FvvagBNKP 0FNQCDs8/ULAf9h6ge1canKQxIEPxqh2DOpkhx5OaqRfbKE8KudpHTP6mJavDe/EvohV KV+Zl0W7mwG+a30OY0injpANkYL0AamV9Zm5rsO3cIKgCDn+A8cxjOlgjDcy1knXGgpr JrYY3tgFSw7HERgW4f6APKrXFx9jE0HFpbU9cuudyHHhCydT3HqubzP6UctxH5IhY3V+ Q0lA==
X-Gm-Message-State: AD7BkJKwb6iOEd0pI9f2U2Wc5p1TU7VsjGaJHQhN7BxKmFT12femOB5VDRjtCAjTxfwlZw==
X-Received: by with SMTP id 136mr11346551qhs.30.1460118407260; Fri, 08 Apr 2016 05:26:47 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:136:d522:f12e:a98d:84bc? ([2001:67c:370:136:d522:f12e:a98d:84bc]) by with ESMTPSA id r132sm5338168qhc.41.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 05:26:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend
From: Sean Turner <>
In-Reply-To: <017a01d190ca$ace223b0$06a66b10$>
Date: Fri, 8 Apr 2016 09:26:41 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <017a01d190ca$ace223b0$06a66b10$>
To: Roni Even <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc:,, " list" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Apr 2016 12:26:52 -0000

> On Apr 07, 2016, at 09:40, Roni Even <> wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>.
> 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

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


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