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

Nikos Mavrogiannopoulos <nmav@redhat.com> Fri, 03 October 2014 09:20 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 193CE1AD003 for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 02:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.688
X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pZki1YF_OUKO for <tls@ietfa.amsl.com>; Fri, 3 Oct 2014 02:20:49 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E01E1ACFFA for <tls@ietf.org>; Fri, 3 Oct 2014 02:20:49 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com []) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s939KkAF017850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 3 Oct 2014 05:20:46 -0400
Received: from [] (dhcp-2-127.brq.redhat.com []) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s939Ki2q031071 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 3 Oct 2014 05:20:45 -0400
Message-ID: <1412328043.6317.29.camel@dhcp-2-127.brq.redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Date: Fri, 03 Oct 2014 11:20:43 +0200
In-Reply-To: <039F1A93-7C77-45B0-87CA-33E0916FDB35@gmail.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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bqSNjuMvi0AisB0Tvy0QZMsBpts
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [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 09:20:51 -0000

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.

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

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.