Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3
Watson Ladd <watsonbladd@gmail.com> Wed, 26 March 2014 22:34 UTC
Return-Path: <watsonbladd@gmail.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 E439E1A03EB for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 15:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQy8hzS2gg4S for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 15:34:45 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 669E51A03E9 for <tls@ietf.org>; Wed, 26 Mar 2014 15:34:45 -0700 (PDT)
Received: by mail-yk0-f174.google.com with SMTP id 20so1454107yks.33 for <tls@ietf.org>; Wed, 26 Mar 2014 15:34:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P1mD36wS93r+Huq1qfnGXZT4qSVOYVgfL3lTTQ2qak8=; b=VEqxVONS+0DzdKrOWLZZD2HDXvmf1uf0xQVAyjd9lA5yDm/5RlpvpqxJHbBjJlIO9r kplQS/dWhqolqOg1Ml9GnIIzQ6GycBNvK4iz5WciG/uM68J13o5juwpO3nl1o7EFK2lg GPvZHTAO5mtDkXq+grbfNjSijVbRMd9Wpf7tPIbx5n92wb5wU//8DzSuiEOonL0iWqfU TxQfmpoxOzIh9vglbXsuVP6q0OLQLENNlZNpOVExAZTWEfmiqOXHHKdOwzrG6GuBXEjf Elqqlp45tPCewKF9RAM/XRc/dRQ12vlTZ4tZgMK2mEo4r0Z7aBwGoLKg6BASWEi72YpU jG/Q==
MIME-Version: 1.0
X-Received: by 10.236.79.134 with SMTP id i6mr86084903yhe.16.1395873283746; Wed, 26 Mar 2014 15:34:43 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Wed, 26 Mar 2014 15:34:43 -0700 (PDT)
In-Reply-To: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp>
Date: Wed, 26 Mar 2014 18:34:43 -0400
Message-ID: <CACsn0c=77YwhmcoKxqMF=x=FUi_W=pxBHY-H3E2WHKEBBbhHMg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: mrex@sap.com
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ACHj_wWU8FOohUZxRJMMIMQjJt8
Cc: "tls@ietf.org" <tls@ietf.org>
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: Wed, 26 Mar 2014 22:34:48 -0000
On Wed, Mar 26, 2014 at 5:12 PM, Martin Rex <mrex@sap.com> wrote: > Joseph Salowey (jsalowey) wrote: >> >> TLS has had cipher suites based on RSA key transport (aka "static RSA", >> TLS_RSA_WITH_*) since the days of SSL 2.0. These cipher suites have >> several drawbacks including lack of PFS, pre-master secret contributed >> only by the client, and the general weakening of RSA over time. >> It would make the security analysis simpler to remove this option from >> TLS 1.3. RSA certificates would still be allowed, but the key >> establishment would be via DHE or ECDHE. The consensus in the room >> at IETF-89 was to remove RSA key transport from TLS 1.3. If you have >> concerns about this decision please respond on the TLS list by >> April 11, 2014. > > To me that looks like a pretty bogus statement. > > There really is nothing wrong with static RSA, and I can conceive a > number of scenarios where (EC)DHE could make the situation much worse. > > DHE has the problem that it lacks a required set of parameters. > Generating everything anew and having to verify all parameters > on the client side for each and every handshake is prohibitively expensive, > so a number of implementations seem to be using a static keypair for the > server that is manually generated by an admin once, and never refreshed/ > updated, making it appear better than static RSA, but de-facto much > worse. Small devices that currently have poor entropy sources may > be much better off with a static RSA keypair once generated by an > admin on a machine with good entropy and then pushed onto the device > rather then having to frequently generate new keys on such a device. If the admin is provisioning the devices, they can seed the devices with entropy, which gets irreversibly mixed each power cycle. But yes, DHE parameter validation is a big issue. > > > If RSA was weak, _any_single_use_ of RSA would make you "vulnerable", > not just the RSA encryption of the premaster secret, but in just the > same fashion the RSA signature on the (EC)DHE parameter in the > ServerKeyExchange handshake message. Or the signatures on the > certificate chain, or the signatures on the OCSP responses or CRLs. RSA signatures in the PKI are being increased in size to 2048 and 4096 over the next few years to address this problem. This doesn't seem to be in the cards for static RSA because of the speed issues. > > And once you do the whole PKI glory (long and complex certificate chains > and full revocation galore, then you may realize that RSA still has > a significant performance advantage over the alternatives. For a single signature, maybe. But for multiple signatures with the Schnorr scheme (or ECDSA plus a single extra bit... why wasn't this bit included?) you can batch verify. This has a significant performance advantage. Furthermore, this is orthogonal to the issue of the fastest TLS handshake. RSA decryption is very slow, so you can do the two exponentiations to complete a P256 handshake and signing in the time to encrypt. The client doesn't matter: it is making very few connections, so can take a while to do the calculations. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- [TLS] Confirming Consensus on removing RSA key Tr… Joseph Salowey (jsalowey)
- [TLS] On axing DHE (was: Re: Confirming Consensus… Rene Struik
- Re: [TLS] Confirming Consensus on removing RSA ke… Trevor Perrin
- Re: [TLS] Confirming Consensus on removing RSA ke… Martin Rex
- Re: [TLS] Confirming Consensus on removing RSA ke… Watson Ladd
- Re: [TLS] Confirming Consensus on removing RSA ke… Santosh Chokhani
- Re: [TLS] Confirming Consensus on removing RSA ke… Martin Rex
- Re: [TLS] Confirming Consensus on removing RSA ke… Hanno Böck
- Re: [TLS] Confirming Consensus on removing RSA ke… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming Consensus on removing RSA ke… Jack Lloyd
- Re: [TLS] Confirming Consensus on removing RSA ke… Alyssa Rowan
- Re: [TLS] Confirming Consensus on removing RSA ke… Paul Bakker
- Re: [TLS] Confirming Consensus on removing RSA ke… Alyssa Rowan
- Re: [TLS] Confirming Consensus on removing RSA ke… Hanno Böck
- Re: [TLS] Confirming Consensus on removing RSA ke… Johannes Merkle
- Re: [TLS] Confirming Consensus on removing RSA ke… Paul Bakker
- Re: [TLS] Confirming Consensus on removing RSA ke… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming Consensus on removing RSA ke… Salz, Rich
- Re: [TLS] Confirming Consensus on removing RSA ke… Watson Ladd
- Re: [TLS] Confirming Consensus on removing RSA ke… Salz, Rich
- Re: [TLS] Confirming Consensus on removing RSA ke… Andy Lutomirski
- Re: [TLS] Confirming Consensus on removing RSA ke… Marsh Ray
- Re: [TLS] Confirming Consensus on removing RSA ke… Daniel Kahn Gillmor
- Re: [TLS] Confirming Consensus on removing RSA ke… Daniel Kahn Gillmor
- [TLS] Negotiated Discrete Log DHE revision [was: … Daniel Kahn Gillmor
- Re: [TLS] Negotiated Discrete Log DHE revision [w… Michael D'Errico
- Re: [TLS] Negotiated Discrete Log DHE revision Michael D'Errico
- Re: [TLS] Negotiated Discrete Log DHE revision Henrick Hellström
- Re: [TLS] Negotiated Discrete Log DHE revision [w… Daniel Kahn Gillmor
- Re: [TLS] Negotiated Discrete Log DHE revision Daniel Kahn Gillmor
- Re: [TLS] Negotiated Discrete Log DHE revision Samuel Neves
- Re: [TLS] Negotiated Discrete Log DHE revision Watson Ladd
- Re: [TLS] Negotiated Discrete Log DHE revision Samuel Neves
- Re: [TLS] Negotiated Discrete Log DHE revision Liz meeks
- Re: [TLS] Negotiated Discrete Log DHE revision [w… Fedor Brunner
- Re: [TLS] Negotiated Discrete Log DHE revision [w… Fedor Brunner
- Re: [TLS] Confirming Consensus on removing RSA ke… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming Consensus on removing RSA ke… Martin Rex
- Re: [TLS] Confirming Consensus on removing RSA ke… Eric Rescorla
- Re: [TLS] Confirming Consensus on removing RSA ke… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming Consensus on removing RSA ke… Kurt Roeckx
- Re: [TLS] Confirming Consensus on removing RSA ke… Daniel Kahn Gillmor
- Re: [TLS] Confirming Consensus on removing RSA ke… Eric Rescorla
- Re: [TLS] Confirming Consensus on removing RSA ke… Kurt Roeckx
- Re: [TLS] Confirming Consensus on removing RSA ke… Eric Rescorla
- Re: [TLS] Confirming Consensus on removing RSA ke… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming Consensus on removing RSA ke… Viktor Dukhovni
- Re: [TLS] Confirming Consensus on removing RSA ke… Watson Ladd
- Re: [TLS] Confirming Consensus on removing RSA ke… Nikos Mavrogiannopoulos