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

From: Jari Arkko <[email-masked]>
Date: Thu, 5 May 2016 05:01:43 -0400

Thanks for your review, Roni!

I do agree with Sean’s explanation though.

There’s no requirement to make documents informational, even if the IANA rules don’t require something beyond informational. The decision to use informal or standards track depends on what the document is needed. And yes, usage of a major algorithm (not the national ones) in a protocol in my opinion is an OK and established use of the standards track.

Jari

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 May 2016 15:41:18 +0300

Hi Roni.

I think I can explain one of your questions.

> On 8 Apr 2016, at 5:36 PM, Roni Even <[email-masked]> 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.

HTH

Yoav

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 5 May 2016 06:55:38 -0700

On Thu, May 5, 2016 at 5:41 AM, Yoav Nir <[email-masked]> wrote:
> 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.

The first cipher suite values we (I remember it was Adam Langley)
chose for our experiments were actually mnemonics: 0xCC13 and 0xCC14,
where "CC" suggests ChaCha and "13" suggests Poly1305. You can see
these values in the sslproto.h file in the first NSS patch:

https://codereview.chromium.org/23619044/diff/31001/net/third_party/nss/ssl/sslproto.h

The definitions of those two cipher suites have since changed, so we
had to change their cipher suite values. But I asked the co-author
Nikos to keep the first byte as 0xCC. I don't know how Nikos chose the
range of the values of the second byte (starting with 0xA0, now 0xA8 -
0xAE).

Wan-Teh Chang