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

Santosh Chokhani <SChokhani@cygnacom.com> Wed, 26 March 2014 23:25 UTC

Return-Path: <SChokhani@cygnacom.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 621551A0276 for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 16:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zpR9ZbkWJTsx for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 16:25:03 -0700 (PDT)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id AE98E1A024D for <tls@ietf.org>; Wed, 26 Mar 2014 16:25:03 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,738,1389762000"; d="scan'208";a="2404706"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 26 Mar 2014 19:25:01 -0400
Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([::1]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 19:25:01 -0400
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: "mrex@sap.com" <mrex@sap.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Thread-Topic: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3
Thread-Index: AQHPSTgYIMQ+i3GfNEGBIytwQbpiBZr0AJNw
Date: Wed, 26 Mar 2014 23:25:00 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E81139174CF2@scygexch10.cygnacom.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp>
In-Reply-To: <20140326211219.27D281AC7D@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.24.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7n_i4FgxnYwWiTdlvIS1ibbmcMI
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 23:25:07 -0000

Martin,

While I agree with most of what you say including some benefits of RSA, the DHE parameter verification by the client while desirable is not a genuine security threat.  A rogue server has many other ways to compromise the exchange,

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Rex
Sent: Wednesday, March 26, 2014 5:12 PM
To: Joseph Salowey (jsalowey)
Cc: tls@ietf.org
Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

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

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.


-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls