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

Geoffrey Keating <geoffk@geoffk.org> Tue, 19 November 2013 03:21 UTC

Return-Path: <geoffk@geoffk.org>
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 332831AEBB8 for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w5EDaJ-FHWUN for <tls@ietfa.amsl.com>; Mon, 18 Nov 2013 19:21:05 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) by ietfa.amsl.com (Postfix) with ESMTP id 412C01AEBB5 for <tls@ietf.org>; Mon, 18 Nov 2013 19:21:05 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 89E8733D108; Tue, 19 Nov 2013 03:20:59 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Andy Lutomirski <luto@amacapital.net>
References: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com> <m238mv1wkq.fsf@localhost.localdomain> <CABcZeBPzYi3rztRv7-mNWf7BwTJ83-Sc1c_=j4kN8nJhh2FCjA@mail.gmail.com> <528AD2BF.8070304@amacapital.net>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 18 Nov 2013 19:20:59 -0800
In-Reply-To: <528AD2BF.8070304@amacapital.net>
Message-ID: <m2txf9yt44.fsf@localhost.localdomain>
Lines: 23
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Should we support static RSA in 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: Tue, 19 Nov 2013 03:21:07 -0000

Andy Lutomirski <luto@amacapital.net> 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.)

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