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

Brian Smith <> Fri, 03 October 2014 16:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 14A951A1A26 for <>; Fri, 3 Oct 2014 09:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0pmHTkVlYRgP for <>; Fri, 3 Oct 2014 09:35:02 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FCBB1A19F4 for <>; Fri, 3 Oct 2014 09:35:02 -0700 (PDT)
Received: by with SMTP id x69so1039666oia.31 for <>; Fri, 03 Oct 2014 09:35:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cWYrMm6zyFiwc7C6HEfu3sPpLdP/JaQVqxz3Rd6NCNE=; b=Y4PZNJ0c+eE+jjOpcV6SFWqOjx0PysEj0Xg04J7coLdqj4Q6aYtaZ0JuIesEk5jWQw zfDzrOdrKzeLr27Ee/h01JZqEZuLl+oNVp/s5mUvmZgmPUdt7TrWZI4n6QMnqFIVVIa1 BpoEb+c6cyqz7RzNdnNLVGiNONFfyK0HHxKiWINTe5jb/y0tXnHh3TiJjljfcl4a8JJD JpPN6rxCnQjE4FSY6U2PZqVrQSQb7LNuZYWGlf9WhM0u73BVoUftBjXndujVkS2ZdjP4 dIQGBlv4ZX67Hu87vao9fUOmjhoQIxZbFrJ8aa3R4t1nFN+zHVYnAzXobXWoN+NILdfu FIeg==
X-Gm-Message-State: ALoCoQlQUacu2HTAKbb4zm5VPash5z9DeEvLwq3NIjIoKBjVsTSIob6F2NfPOZSdf2DSKV+VyYlg
MIME-Version: 1.0
X-Received: by with SMTP id cv5mr8171906oeb.17.1412354101801; Fri, 03 Oct 2014 09:35:01 -0700 (PDT)
Received: by with HTTP; Fri, 3 Oct 2014 09:35:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Fri, 3 Oct 2014 09:35:01 -0700
Message-ID: <>
From: Brian Smith <>
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:35:04 -0000

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.

I agree with this. The ChaCha20-HMAC-SHA-1 cipher suite is not a good
use of resources and should be removed so we can focus on other, more
important, improvements.

> The market segment I work on makes products that are designed to last
> 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.

There are real reasons to add support for TLS 1.2 to stable products
like RHEL (in particular). For example, versions less than 1.2 rely on
the collision resistance of MD5 and SHA1, which really a bad idea.
Further, nobody would be able to deploy HTTP/2 effectively (i.e. works
with most browsers) without TLS 1.2, unless their products avoid the
system crypto stack, which is counter to the purpose of having a
system crypto stack in the first place. Consequently, I think it makes
a lot more sense to spend time to figure out how to spread TLS 1.2 to
these more conservative products and deployments, than it does to
spend time figuring out how to avoid doing so.

Further, why would any user that is too change-averse to deploy TLS
1.2 want to deploy ChaCha20 cipher suites?

> 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.

We already have the AES-based cipher suites for 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.

You had to do the same thing for the stream construction. See
where you redefine the stream construction.

> Then implementers would
> have, implement my special design and release.

Who is planning to implement ChaCha20-SHA1, regardless of how it is
specified? I expect very few people to do so.

Also, some newer implementations of TLS may not even implement the
stream mode construction at all, since currently it is used only for
RC4. This makes it even less likely that implementations will support
the HMAC-SHA1 version.