Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

Hanno Böck <hanno@hboeck.de> Thu, 27 March 2014 13:01 UTC

Return-Path: <hanno@hboeck.de>
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 782FE1A06CB for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:01:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 70hAQxPtV7X6 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 06:01:46 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 635D01A06B9 for <tls@ietf.org>; Thu, 27 Mar 2014 06:01:46 -0700 (PDT)
Received: from localhost (91-66-83-156-dynip.superkabel.de [::ffff:91.66.83.156]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 27 Mar 2014 14:01:44 +0100 id 000000000002005A.0000000053342138.00005BCC
Date: Thu, 27 Mar 2014 14:01:00 +0100
From: Hanno Böck <hanno@hboeck.de>
To: tls@ietf.org
Message-ID: <20140327140100.0b98c4b5@hboeck.de>
In-Reply-To: <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com>
X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-23500-1395925304-0001-2"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YGN2xGyXEufjAIceVwsae9jiGTA
Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3
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: Thu, 27 Mar 2014 13:01:48 -0000

On Thu, 27 Mar 2014 12:27:17 +0000
Alyssa Rowan <akr@akr.io> wrote:

> I'm wondering: why even keep DHE around at all?
> 
> Let's face it: traditional DHE runs like an absolute dog compared to
> ECDHE using secp256r1, or especially curve25519 (which we have a live
> draft for now: I'm ready to start driving deployment almost as soon
> as we get a curve number!).

I'm not comfortable with the idea of going elliptic curve everywhere.
I'd really prefer to keep the "old and well tested" options around.

There's a particular reason I think so: I think at one point (which may
be 10, may be 30 years away or may not happen at all) we'll have to
deal with quantum computers. Right now we have nothing really to offer
here yet (I'm aware of pqcrypto algos, but none of them is in any usable
state right now), but the first defense to quantum computers is
increased key sizes.

It will be easier to build a quantum computer to break 512 bit keys
than one to break 4096 bit keys. That's why in a word where quantum
computers become a reality I'd rather go with RSA+DHE with large
key/modulus than with anything from the ECC family.

Appart from that: From the facts I know I am extremely uncomfortable
with both ECDSA and the NIST curves and I'd really like to have them
removed from TLS altogether. Strong vote for Ed25519 (or another
algorithm with similar properties) and only curves that pass the
safecurves criteria.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42