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

Watson Ladd <> Fri, 03 October 2014 16:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBB881A1A77 for <>; Fri, 3 Oct 2014 09:37:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ir-KQ4GrBwSR for <>; Fri, 3 Oct 2014 09:37:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F5FA1A1A26 for <>; Fri, 3 Oct 2014 09:37:49 -0700 (PDT)
Received: by with SMTP id 10so467266ykt.0 for <>; Fri, 03 Oct 2014 09:37:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id t21mr9632314yhl.65.1412354268443; Fri, 03 Oct 2014 09:37:48 -0700 (PDT)
Received: by with HTTP; Fri, 3 Oct 2014 09:37:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Fri, 3 Oct 2014 09:37:48 -0700
Message-ID: <>
From: Watson Ladd <>
To: Nikos Mavrogiannopoulos <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] why Chacha20-SHA1 was: adopting ChaCha20 as a WG item
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Oct 2014 16:37:51 -0000

On Fri, Oct 3, 2014 at 2:20 AM, Nikos Mavrogiannopoulos <> 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

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