[TLS] TLS handshake performance (was Re: Confirming Consensus on removing RSA key Transport from TLS 1.3<)

Watson Ladd <watsonbladd@gmail.com> Thu, 27 March 2014 00:01 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 897511A0408 for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 17:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EEDjfsebE9BP for <tls@ietfa.amsl.com>; Wed, 26 Mar 2014 17:01:18 -0700 (PDT)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 07A761A03FB for <tls@ietf.org>; Wed, 26 Mar 2014 17:01:17 -0700 (PDT)
Received: by mail-yk0-f172.google.com with SMTP id 200so1548284ykr.31 for <tls@ietf.org>; Wed, 26 Mar 2014 17:01:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mjY/LEGnp8dgqnOkmxfGbE3YynzvLOZDnypdRwbMkoA=; b=SjhaY/u1p9c3MvQCvTle7clQtF84YWgItTei37xifcBrfL18tu2luC1MSnfvtyTklJ uytVl9rduLsATZnZpMBkXvAKrXd3P0JopEjcOLyG759mm3ab03zb0s5+f42WSxoyhE3D ZtiN1BvX3NFaEGxeRCl4HLVf2NAmzV5VfuDKFMN4scvR4/VtZNi/DAJYNpVMIK2m1wv1 9PGZTe2lQPB1dV1DMABqN8pW03ayK52Wl+rWLr69bqzDdpLpnePhmAwGfKDEnYEjhwQ1 aS6jalJ9mkb5nvfx6ClsIJ4ac0bd+7bHUibVT1jy4prGqkAsyJd8a4Ymx+I9Z20PAYJS WnCg==
MIME-Version: 1.0
X-Received: by with SMTP id f77mr6400274yhj.128.1395878475926; Wed, 26 Mar 2014 17:01:15 -0700 (PDT)
Received: by with HTTP; Wed, 26 Mar 2014 17:01:15 -0700 (PDT)
Date: Wed, 26 Mar 2014 20:01:15 -0400
Message-ID: <CACsn0c=5Z_k6bAOOY=GsbjpbfWJMTNJkVeSnsNb0R87sjJF2Dw@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/rVjg1RL4m-mXDyLjZSM-pkYn7mU
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: [TLS] TLS handshake performance (was Re: 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 00:01:19 -0000

On Wed, Mar 26, 2014 at 7:28 PM, Martin Rex <mrex@sap.com> wrote:
> 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?

Not RSA signed, but ECDSA signed. Three exponentiations vs. one RSA
private key operation.  Using openssl speed I got that ECDH+ECDSA is
twice as fast as RSA.

If you are stuck with an RSA server key, you can use a semistatic
ECDSA key, and do exactly one exponentiation per connection,
plus one RSA private key operation per key rotation interval. There is
a reason large sites use ECDHE-ECDSA.

If I remember correctly, switching the key the server uses for clients
doesn't require a new certificate, but I might be wrong.

Watson Ladd

> -Martin

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin