Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item

Watson Ladd <watsonbladd@gmail.com> Fri, 03 October 2014 16:37 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB881A1A77 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 09:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 Ir-KQ4GrBwSR for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 09:37:49 -0700 (PDT)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5FA1A1A26 for <tls@ietf.org>; Fri, 3 Oct 2014 09:37:49 -0700 (PDT)
Received: by mail-yk0-f169.google.com with SMTP id 10so467266ykt.0 for <tls@ietf.org>; Fri, 03 Oct 2014 09:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OWiShbEk0KdP3L/gF7mM5Pt3EurZyNMfIHZOr9+hDHI=; b=o9GSztiIcdxQglQTT7GsCor9qTEWcy2keoRRBhs9Ts3VGZ3O/l0oam/LcAnFYadwxA eORdyU0Hj+0L7Yo8B6YXHrG7FOdyEJgNOUmhn1Rpa5ZjZw27z35ApygYY5nX/2JHxHAU LZo8MBHmxuSVSWwrUgMMgWOwehvv9Pnr2K7Rie3NyAydFtsTosz79dGLPqFGbfn5fQNX uvkfxkSa0aLT/foX7TJzpl+L79LKGSXdAugwoROazPz2+J34PUg6krBl3TvX71vENlKD jPfUJKWNuoOG9ERecrn1sM1XnffVAtTDO9y0Zq8U0go5Gp587eWBU8kg9KAw21dIHlx8 fKjQ==
MIME-Version: 1.0
X-Received: by 10.236.172.161 with SMTP id t21mr9632314yhl.65.1412354268443; Fri, 03 Oct 2014 09:37:48 -0700 (PDT)
Received: by 10.170.195.149 with HTTP; Fri, 3 Oct 2014 09:37:48 -0700 (PDT)
In-Reply-To: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com>
References: <20141002005804.2760C1AE9D@ld9781.wdf.sap.corp> <BA2DFF33-7B0C-4E87-9C0E-215933AED88F@akr.io> <CADMpkc+j5kL1G=NA9phQy=nLAEUA1u8jfnNT=2wDp_S=kOTjNQ@mail.gmail.com> <A3F7FDF7-F7C3-4704-8FDD-C1198C6EE1A9@akr.io> <1412253233.27112.31.camel@dhcp-2-127.brq.redhat.com> <73B75C67-2608-4210-A624-14934E08016E@gmail.com> <1412255992.27112.41.camel@dhcp-2-127.brq.redhat.com> <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.com> <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 3 Oct 2014 09:37:48 -0700
Message-ID: <CACsn0c=4CX-N1NU0rF6K07+OkRQALDnMtUbkzBiYE=UAoX=ORw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HOWt3uCQobDiln5utXV62xlPD54
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 16:37:51 -0000

On Fri, Oct 3, 2014 at 2:20 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
> On Fri, 2014-10-03 at 00:22 +0300, Yoav Nir wrote:
>
>> HI Nikos
>>
>> A pre-1.2 implementation of ChaCha20 assumes that there are libraries
>> out there that on the one hand don’t have TLS 1.2, and on the other
>> hand are still actively developed enough that they will implement a new
>> algorithm. I don’t think that’s the case. If ChaCha20-Poly1305 is going
>> to be implemented in OpenSSL, it’s going to be in 1.0.1 or 1.0.2. I
>> don’t think anyone’s going to add it to 0.9,8, where every recent patch
>> has been a security hotfix. Similarly, every library I know of that is
>> being maintained already has TLS 1.2.  I don’t feel strongly about it,
>> but I don’t see the use of having new non-AEAD ciphers at this point.
>
> There have been quite some discussions about that with the TLS WG chairs
> as well. I'll provide my point of view here. The need for an alternative
> to Poly1305 hash is for redundancy and being conservative when
> introducing a new hash (we always had HMAC-SHA1 in addition to
> HMAC-MD5). The need for using a compatible with TLS 1.0/1.1 design is
> implementation simplicity, and definition simplicity. I elaborate below.

Right conclusion: wrong reasons. Carter-Wegman MACs are
unconditionally secure, but the code changes are minimized by reusing
a MAC.

Unfortunately the draft bobbles nonce handling: it's not clear to me
how the nonce is generated in TLS 1.1 and TLS 1.0.
>
> There are several market segments. Some make products that last less
> than 2-3 years and after that they are obsolete and unmaintained. That
> market segment has the luxury to adopt new technologies quickly and
> ignore any issues on a 10 year old mobile phone for example.
>
> The market segment I work on makes products that are designed to l
> for 6+ years (often more than 10) and during that time they are
> maintained and get new security features whenever that's possible. While
> adding a new stream ciphersuite to TLS 1.0 or 1.1 is trivial, adding
> support for TLS 1.2 or AEAD is significant work with many potential
> side-effects and regressions, and that is something you don't do on a
> production system unless there is a real reason for that.
>
> This provides rationale why I feel that a backwards compatible with TLS
> 1.0 and TLS 1.1 ciphersuite is needed that can replace RC4.
>
> The other reason I believe that Chacha20-SHA1 is needed, is redundancy
> and backup. Poly1305 is a new MAC algorithm not used anywhere else, and
> having a conservative design along it, provides a reasonable fallback.
> Why this design uses the TLS stream authenticated encryption? because it
> is simpler and safer. The TLS stream authenticated encryption is a tried
> and proved construction that combines a MAC and a stream cipher. By
> going the AEAD path I'd have to play cryptographer and define a "novel"
> Chacha20-SHA1 design, anyway that I'd feel like, send it to IETF to
> standardize it as AEAD (possibly pass through CFRG as well), and few
> years later when it is obsolete add it to TLS. Then implementers would
> have, implement my special design and release. You could argue that I
> could specify it to be exactly the same as the stream
> authenticated-encryption and shortcut some of that path... Isn't that
> what I'm doing? If there was commonly accepted form of AEAD that would
> allow to combine a stream cipher and a MAC, that would change things,
> but there isn't.

There is: encrypt then MAC, using two different keys and the same
nonce. This has been known for at least 20 years.

>
> regards,
> Nikos
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin