Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls

Hubert Kario <hkario@redhat.com> Wed, 24 June 2015 11:53 UTC

Return-Path: <hkario@redhat.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 4CB9D1A891C for <tls@ietfa.amsl.com>; Wed, 24 Jun 2015 04:53:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iYO5TgJK6nzg for <tls@ietfa.amsl.com>; Wed, 24 Jun 2015 04:53:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6401A891B for <tls@ietf.org>; Wed, 24 Jun 2015 04:53:57 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 0EDC52B9DE9; Wed, 24 Jun 2015 11:53:56 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-121.brq.redhat.com [10.34.0.121]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5OBrsxl019744 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 24 Jun 2015 07:53:55 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 24 Jun 2015 13:53:49 +0200
Message-ID: <3039391.7h1HagpxET@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.7 (Linux/4.0.4-202.fc21.x86_64; KDE/4.14.7; x86_64; ; )
In-Reply-To: <79998D45-BF29-4261-968A-185931187DE2@gmail.com>
References: <FD8B7C3F-C3DD-4367-B84D-26B9907F1B9D@ieca.com> <20150623185141.GA20677@LK-Perkele-VII> <79998D45-BF29-4261-968A-185931187DE2@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2409185.SyiTynOQmb"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/v87mm9KQXJrBuuLLRGdxIR0OA5Q>
Subject: Re: [TLS] WG adoption + early code point assignment: draft-mavrogiannopoulos-chacha-tls
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 24 Jun 2015 11:53:59 -0000

On Tuesday 23 June 2015 23:21:53 Yoav Nir wrote:
> > On Jun 23, 2015, at 9:51 PM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> > wrote:> 
> > On Wed, May 20, 2015 at 12:51:40AM +0300, Yoav Nir wrote:
> >> 2) I question the need for TLS_DHE_ ciphersuites, and I seriously doubt
> >> anybody’s going to use those with ChaCha20 “in the wild”.
> > 
> > Can you expand on that (I found that comment strange)? The possiblities
> > that come to mind are:
> > 
> > a) That was a typo for TLS_RSA_ (which isn't FS)
> > b) Actually both TLS_DHE_ and TLS_RSA_, since whatever considers
> > 
> >   supporting Chacha20 supports ECDHE already (or it just does pure-PSK),
> >   and that's superrior to both.
> > 
> > c) Something else.
> 
> No, I actually meant DHE. DHE is hardly used. Any cryptographic library new
> enough to support ChaCha20 will also support ECDHE, which is faster than
> DHE and does not have the baggage of interoperability with legacy
> implementations that only support 1024 bits.
> 
> I thought that we should just deprecate DHE and not even do the
> negotiated-ff-dhe draft. The group thought differently, but pairing this
> legacy key exchange with a new cipher looks strange to me.

If we go the route of negotiating the KEX separately from bulk cipher in 
TLSv1.3, you'll have DHE with ChaCha20 in TLSv1.3.

So you'll remove it only from TLSv1.2 and lower.
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic