Re: [TLS] Should we support static RSA in TLS 1.3?

Andy Lutomirski <> Tue, 19 November 2013 03:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E117A1AEC46 for <>; Mon, 18 Nov 2013 19:42:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NkttBq_h0Puf for <>; Mon, 18 Nov 2013 19:42:36 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D4F5D1AEC42 for <>; Mon, 18 Nov 2013 19:42:34 -0800 (PST)
Received: by with SMTP id oy12so1715241veb.1 for <>; Mon, 18 Nov 2013 19:42:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SCkrCLt5HqOJyV5Ch1xyO2h+7HS4GFQxpKumeVTSe+U=; b=ZJBIO9LMCvXd94X6ZIzlHZ1C6HXZcvLR3FSMt22FO/9bdZRs4r1pHtioNvoBv2HivO sghsRq6VqB000Cch7vJyOi3tXm84fM6pQ8lQo3umVkxLsPfOGidL6N65nnx7YNkSAFkU 4YEqvXBFgy5PAVqhx6q8CpCYAg7JFS5Uab6sxHtwueOkZ8JAGTnJumOD8Qr5nLkqKRYV sIyhMHWQci8gzRaRiVmaJYlLa+8RRoFf1gEfU3YnCuXDIbaoWtwfXXzXloJBPa9Y2u8Y jMyxFq27Kq4+W+Sxp4758bw6yrUeQKeINpU5KnMxrMSBVWNrCPyc5zXOZRZHlI3LH6Le /bag==
X-Gm-Message-State: ALoCoQmHoh/0IKt4LrWxHsAV3g3oH47WtvlZ4GLMZKF3FGrNvtBjng5S3J1B+sHB0NZ0q7k24uAX
X-Received: by with SMTP id at9mr6509960ved.20.1384832548708; Mon, 18 Nov 2013 19:42:28 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 18 Nov 2013 19:42:08 -0800 (PST)
In-Reply-To: <m2txf9yt44.fsf@localhost.localdomain>
References: <> <m238mv1wkq.fsf@localhost.localdomain> <> <> <m2txf9yt44.fsf@localhost.localdomain>
From: Andy Lutomirski <>
Date: Mon, 18 Nov 2013 19:42:08 -0800
Message-ID: <>
To: Geoffrey Keating <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] Should we support static RSA in TLS 1.3?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Nov 2013 03:42:38 -0000

On Mon, Nov 18, 2013 at 7:20 PM, Geoffrey Keating <> wrote:
> Andy Lutomirski <> writes:
>> (For what it's worth, static RSA is faster on the client side than
>> short-term fixed DH certificates, but fixed DH may result in a cleaner
>> protocol.  I suspect that fixed ECDH is quite a bit faster than either.)
> I think you'll find fixed ECDH is still slower on the client than
> static RSA.  With 'openssl speed' on this system I find that a 256-bit
> ECDH takes 0.0013s, and two 2048-bit verify/encrypt operations takes
> 2*0.000197s=0.000394s, which is 3.3x faster.  (Of course the
> signing/decryption operations take 2*0.0074s=0.0148s, which is more
> than 10x slower, but that's on the server.)

I wonder how Curve25519 stacks up.

> Of course this changes a lot if you have hardware, but more clients
> have RSA in hardware than ECDH in hardware, and if you have to choose
> then it's better to have RSA hardware because you'll probably need to
> do some more RSA verify operations to check the certificate chain.
> Fixed DH and fixed ECDH don't give PFS when used in current TLS.
> You could make them do this in a new version of TLS by doing
> ephemeral DH or ECDH or RSA, and then using the fixed DH to agree on a
> key that is used in a MAC to verify the ephemeral DH public key, but
> it's twice as much work (and no-one seems to be using fixed DH anyway).

Google's QUIC almost has PFS -- they achieve it by signing a very
short-lived set of ECDH parameters using their X.509 certificate and
presenting those ECDH parameters, with signature, to the client.  The
client verifies the signature and does one ECDH calculation.

If those parameters are generated at server startup, flushed every
hour or two, and never hit disk, then it works pretty well.  (Whether
it's better than short-lived RSA keys is debatable.)