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

Wan-Teh Chang <wtc@google.com> Thu, 05 May 2016 13:58 UTC

Return-Path: <wtc@google.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17A312D6BB for <ietf@ietfa.amsl.com>; Thu, 5 May 2016 06:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.697
X-Spam-Level:
X-Spam-Status: No, score=-3.697 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf4LzzmGAD-M for <ietf@ietfa.amsl.com>; Thu, 5 May 2016 06:58:37 -0700 (PDT)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C75512D8A3 for <ietf@ietf.org>; Thu, 5 May 2016 06:55:39 -0700 (PDT)
Received: by mail-yw0-x233.google.com with SMTP id t10so140277600ywa.0 for <ietf@ietf.org>; Thu, 05 May 2016 06:55:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=ReW2vuVtfouzzOdccyc01VKyXushWhnEx5auPueKJIo=; b=E6YuNJvOjJ8MKA6/Gr8cDvOuPr/yR4ywGJN+2/to2HGXI6FlxUcyxm5oTIZv6UwwA/ Sc07bBIkOIENdaIulgWRoOF3RViT1+c42c/8rECvVebyBQxDvX1zZli646YakwJ0583W XF9wUWVU9SlsfkdhSaNkJuBh0ygl/4/o7a16Zvj9F7gqBSTyrZwTR2fwmIEGQ1d77nnU 2GbO2AMpFGffjXIpNuH6qw5Un/b73lMAEFVz2rwhmL2Rh9mSQzYicg8jaQIiIGxBfxMK FeO15FjT+v5PLrI7jRft4z5OHIlM5n1sISKdn/daVp+LL5RXUEg4VqQknF4bsW5aZ0fn lV+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ReW2vuVtfouzzOdccyc01VKyXushWhnEx5auPueKJIo=; b=GmddualV/lXfR19JSGzi/besRj/vqJPouXXjIVXM5kCJR5D9WafqhL3to7IXoPvfSL etmcNFCbQE+W15ERTZHD7hw+7koJUD6OKnXK58jsp/cHZSBMiOlOqkKA+AcgpGfXVEvf DUzAzg746rtXa6FujiO2XqIIMEw9NaFrwiGDQCRGLasOF23PS+9SJ5q/gq2J9zeh7Raj WOUItiXGM4ShIp6IX1IqjK0zVQp3/9mwAGmpynf057dm9kZAvEe12nL3Tiq9utrARxkk jrqGVdwxSQask52TEFVyu8gKLl4/sZKiKBl3418VmdtkbvflmufhIU6VZ2/bXe2HzuEp 6aAA==
X-Gm-Message-State: AOPr4FWKm3WMBiaYuz4ffh9Ef7tkQrgvpSU5uW/3/eYjepAwTF4HpiYrH+ry21/vTN7AaWv/26tX58ppHbFFoVEE
MIME-Version: 1.0
X-Received: by 10.129.161.207 with SMTP id y198mr9757518ywg.100.1462456538183; Thu, 05 May 2016 06:55:38 -0700 (PDT)
Received: by 10.37.113.67 with HTTP; Thu, 5 May 2016 06:55:38 -0700 (PDT)
In-Reply-To: <4E747344-7607-4715-8A88-A48FE1B3E70C@gmail.com>
References: <017a01d190ca$ace223b0$06a66b10$@gmail.com> <A8A038B3-E10F-4A94-99D3-2C4D23A6E065@sn3rd.com> <00d901d191a4$185fa340$491ee9c0$@gmail.com> <4E747344-7607-4715-8A88-A48FE1B3E70C@gmail.com>
Date: Thu, 5 May 2016 06:55:38 -0700
Message-ID: <CALTJjxHQNvwj4Ms9c5RhfxHXu4YpyUN7dckTxTJgwPz3Qn8=ww@mail.gmail.com>
Subject: Re: Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend
From: Wan-Teh Chang <wtc@google.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4d1JowhLa_IijjcDE8SM4NjNOZ8>
Cc: gen-art@ietf.org, draft-ietf-tls-chacha20-poly1305.all@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 May 2016 13:58:39 -0000

On Thu, May 5, 2016 at 5:41 AM, Yoav Nir <ynir.ietf@gmail.com>; 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@gmail.com>; 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