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

Eric Rescorla <ekr@rtfm.com> Sun, 17 November 2013 00:47 UTC

MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 16 Nov 2013 16:47:04 -0800
Message-ID: <CABcZeBN3WPigLn-ggm2YGTcPEwn8G-1ecRAxdCtK3ueuUPF09Q@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bb048228f8a4404eb54c71f"
Subject: [TLS] Should we support static RSA in TLS 1.3?
Precedence: list

One of the topics we didn't really get to in Vancouver was the fate of
the static RSA ciphersuites. We'll eventually need to decide on this
for TLS 1.3.

Note that this isn't a question of either of the following:

* Removal of RSA from TLS 1.2 and below. There are still plenty of
  clients which only do static RSA and we can't actually break them
  for a long time.

* Removal of the use of RSA certificates: we would still almost
  certainly need ephemeral cipher suites where the server uses their
  RSA key for authentication, just like in the current RSA_DHE and
  RSA_ECDHE cipher suites.

The question is only for TLS 1.3 and only for static RSA.
(If you think differently, please raise on another thread.)


This message tries to summarize what I take to be the main arguments
for and against.

Static RSA has obvious deficiencies:

- It doesn't offer forward security.
- The larger key lengths that are required for security are increasingly
   uncompetitive with other algorithms (principally EC).

Additionally, since we know we want to offer ephemeral key agreement
modes such as DHE (see the recommendations in
http://tools.ietf.org/html/draft-sheffer-tls-bcp-01) it would reduce
complexity to *only* offer such modes rather than having to support
static RSA as well.

This isn't a no-brainer, though. Static RSA is still by far the
dominant key exchange algorithm and if you have an RSA certificate, is
strictly faster than any ephemeral suite. So, we're asking everyone to
take a performance hit at the same time as we're trying to make TLS
faster; of course this is a computational cost rather than one of
network latency, but there are still applications where that matters,
especially in constrained devices.

There are also some settings where PFS is actually undesirable,
especially for diagnosis and monitoring. In this settings, it's much
more convenient to simply provide the monitoring device with the
server key. ssldump and wireshark, for instance, both provide this
feature.

Please use this thread to discuss.

-Ekr

[TLS] Should we support static RSA in TLS 1.3? Eric Rescorla
Re: [TLS] Should we support static RSA in TLS 1.3? Phillip Hallam-Baker
Re: [TLS] Should we support static RSA in TLS 1.3? Geoffrey Keating
Re: [TLS] Should we support static RSA in TLS 1.3? Watson Ladd
Re: [TLS] Should we support static RSA in TLS 1.3? Eric Rescorla
Re: [TLS] Should we support static RSA in TLS 1.3? Watson Ladd
Re: [TLS] Should we support static RSA in TLS 1.3? Eric Rescorla
Re: [TLS] Should we support static RSA in TLS 1.3? Eric Rescorla
Re: [TLS] Should we support static RSA in TLS 1.3? Manuel Pégourié-Gonnard
Re: [TLS] Should we support static RSA in TLS 1.3? Andy Lutomirski
Re: [TLS] Should we support static RSA in TLS 1.3? Geoffrey Keating
Re: [TLS] Should we support static RSA in TLS 1.3? Andy Lutomirski
Re: [TLS] Should we support static RSA in TLS 1.3? Phillip Hallam-Baker
Re: [TLS] Should we support static RSA in TLS 1.3? Marsh Ray
Re: [TLS] Should we support static RSA in TLS 1.3? Peter Gutmann