On Thu, May 5, 2016 at 5:41 AM, Yoav Nir <ynir.ietf@xxxxxxxxx> wrote: > Hi Roni. > > I think I can explain one of your questions. > > >> On 8 Apr 2016, at 5:36 PM, Roni Even <ron.even.tlv@xxxxxxxxx> 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. 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