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

mrex@sap.com (Martin Rex) Wed, 26 March 2014 23:28 UTC

Return-Path: <mrex@sap.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 6E2D11A024D for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 16:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 mwLLSS69r0QU for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 16:28:34 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 73BC21A0380 for <tls@ietf.org>; Wed, 26 Mar 2014 16:28:34 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s2QNSRlj027405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Mar 2014 00:28:27 +0100 (MET)
In-Reply-To: <CACsn0c=77YwhmcoKxqMF=x=FUi_W=pxBHY-H3E2WHKEBBbhHMg@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 27 Mar 2014 00:28:27 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140326232827.85DF91AC7D@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-cM7wZRSSrEEh_VdtMkl_3yw9P0
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
Reply-To: mrex@sap.com
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:28:36 -0000

Watson Ladd wrote:
>>
>> 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.
> 
> 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.

When using an RSA server certificate the server can choose between having
to perform static RSA key exchange with an RSA private key (decryption)
operation on the RSA PremasterSecret or an RSA Private key (signature)
operation to sign the ServerKeyExchange handshake message
--and that signature covers ClientHello.random and ServerHello.random
so is unique per full handshake, just like the RSA decryption of the
Premaster secret.

Where exactly do you see a performance _advantage_ of an RSA-signed
(EC)DHE key exchange vs. an RSA-decrypted PremasterSecret?

-Martin