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

Yoav Nir <> Thu, 05 May 2016 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAFA212B059; Thu, 5 May 2016 05:41:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y5a79ErOtJB3; Thu, 5 May 2016 05:41:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4018412B056; Thu, 5 May 2016 05:41:23 -0700 (PDT)
Received: by with SMTP id g17so25661541wme.1; Thu, 05 May 2016 05:41:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BtSrpB9XienHLORxWAArp4sD11u2hCwSH8EpKuZV+vI=; b=DYvxCz4GgYzp8ZG/gQ+Hn1zbjtX5TOp5HYbqTDGOEZIaxi2IJr31IWXqjPxRHTxZId zwabPzLgSXfpclCd8UrSP3bL8wqVmeW3eZEPXuRZtnkZyOzKVQ351/wnJjC97wGPWnGh /K7bfhsLhjYIjFhq8rUVyjVahIDUBi640fJijucsEAJyvUDltfux7Blpy5t2coOkW9Jz aYSDZuKVLSDwLneQ3wD8cCLPjoE42IxDPLtSPCPXCj5V4xD5EBQgFqgPj59STtI8C2kg nxkT/Wy6o1gYl4JGb/wCoGu97f/9DAPZaEICwzWquGzZLW2+AzybsTqagJHBXXK9EaWr SDUA==
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=BtSrpB9XienHLORxWAArp4sD11u2hCwSH8EpKuZV+vI=; b=XmwslHW/nuCnH0UJyj/KLY2b46E4CyBihOBPuYn/n1RVVEPNbKx6ZdsPitVrpiAEu1 U1GMC3dLA9xtb1dVrzmRyuE0UIAMU8hVCXdnXDYZP0U/U8+6BHlPS9AWAW5V49VX3i02 k5cumi4P0C+X63aNRoVUTGFFGguKTTsVm/AF0csP+h+WlCcm3yqyFmw58ONCE/l2Dvhb n9EHCfxU5KS8dwhRchyO1BEvGWxhXaMtSDhr5tRXJf7URxmUh7lbu8rQjGFlxrOu4sD7 Sh5YpfRsI5/77JvQA7aLBmDED8BSzA122aOY0ip0kuH3g1HSf1msr8kdjXMeFteMohjU LCAA==
X-Gm-Message-State: AOPr4FX9i4SbEyL3tnI+P6hbGMgmgz3CmX8AdgfxB10t7rz6xGK3L6wUCNg47YqI+j4QlQ==
X-Received: by with SMTP id l15mr3224383wma.30.1462452081724; Thu, 05 May 2016 05:41:21 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k139sm3023349wmg.24.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 May 2016 05:41:20 -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: Yoav Nir <>
In-Reply-To: <00d901d191a4$185fa340$491ee9c0$>
Date: Thu, 5 May 2016 15:41:18 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <017a01d190ca$ace223b0$06a66b10$> <> <00d901d191a4$185fa340$491ee9c0$>
To: Roni Even <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
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: Thu, 05 May 2016 12:41:26 -0000

Hi Roni.

I think I can explain one of your questions.

> On 8 Apr 2016, at 5:36 PM, Roni Even <>; wrote:

<snip />

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

<snip />

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

The WG specifically requested these values. Google was eager to have this algorithms in Chrome, so they chose some values at (almost) random that were not being used by anyone else. Others have followed suit and a number of other implementations use the same values (NSS, OpenSSL). So these identifiers are now “out there”. In retrospect, it would have been better if they had squatted on the “Standards Action” range, but by now it doesn’t make much of a difference.