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

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Nov 2013 16:47:04 -0800

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Nov 2013 22:21:19 -0500

I am OK with this provided that we also make a Kerberos ticket like fast
session set up mandatory to support. This need not be the existing scheme
since we are talking about rejigging the key negotiation.

I certainly like the idea that TLS 1.3 becomes synonymous with the gold
standard for security. Knocking out the weak ciphers, key lengths and key
negotiation mechanisms is a good way to slim down the protocol.

But maybe one change we should consider is to break apart the cipher suites
so that we don't need to spend so much time discussing them.

If we made the cipher suite ID longer then we could break them down into
fields. The first few bits could specify whether the field zones are 8, 12
or 16 bits and then allocate numbers to each cipher.

The client and server would still negotiate over specific cipher suites but
adding a new block cipher would be one registry addition not twenty.

On Sat, Nov 16, 2013 at 7:47 PM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

-- 
Website: http://hallambaker.com/

---

From: Geoffrey Keating <[email-masked]>
Date: 16 Nov 2013 20:28:05 -0800

> the static RSA ciphersuites. We'll eventually need to decide on this
...
> server key. ssldump and wireshark, for instance, both provide this

Perhaps we could break the operations into three:

- key agreement and generation (including generation of keys for upper layers)
- bulk encryption/mac
- authentication

and negotiate these separately.

Then, if people want a key agreement where one side generates a random
master key, encrypts it with RSA, and sends it to the other, we can do
that.  The RSA key can be ephemeral (or, at least, changed much more
often than today's typical "once every two years"), which gives
forward secrecy, or the RSA key can be fixed, if forward secrecy is
explicitly not wanted.

The 'client' side needs to only do one RSA encryption and one (RSA)
signature verification, which are both the fast side of the
computation, so should be cheap enough.  (The client will probably
need to do some more signature verifications anyway, to verify the
certificate chain.)  You're adding only a single RSA signature
verification compared to the current non-PFS cipher suites.

For debugging, set a fixed RSA key.  When it's over, unconfigure the
fixed key, automatically generate a new one, and you're secure again.

There are a few cases that are more tricky.  Although I know of no
case where the bulk cipher is combined with key agreement or
authentication---there are some cases where a particular cipher is
standardised to be used with particular key agreement, SKIPJACK comes
to mind, but these are not technical restrictions---sometimes key
agreement and authentication are combined, for example in SRP.  I am
not sure if this is an important problem; it can always be worked
around by doing a separate key agreement and SRP (or whatever), and
using the key produced by SRP for a MAC on the original key agreement.
This is more expensive than plain SRP but it is similar to the
technique recommended for privacy using SRP where you start with an
anonymous cipher suite and then renegotiate SRP.

This will also help for those who want a 'raw public key' mode, they
can simply use 'no authentication'.  If you start the bulk
encryption before starting the authentication, you get privacy (but
probably more round trips).  And you could make client authentication
and server authentication the same messages, just in different
directions, which will help make the protocol more direction-agnostic,
and will also allow better negotiation of client authentication
algorithm and perhaps even server certificate roots.

The above covered two of the common reasons for renegotiation: privacy
and needing additional client auth.  The third is for ciphers that
need re-keying, which I think should be part of the 'bulk
encryption/mac' definition; if a cipher needs rekeying every 10M or
10T of data, the spec for using it in TLS should say when this
happens, and the 'key agreement & generation' algorithm should be
responsible for providing new keys.

Sorry for the length, hope there's at least one good idea in here!

---

From: Watson Ladd <[email-masked]>
Date: Sat, 16 Nov 2013 20:32:05 -0800

I think that we need a better idea of the problem we are trying to solve.
Trading computation for latency by going to ECDSA/RSA signing certs
and signing a Diffie-Hellman exchange is a good idea for Google and the web,
but not so for embedded devices.

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Nov 2013 21:03:10 -0800

> but not so for embedded devices.

TLS is extensively used in both settings.

That said, using ephemeral keying doesn't really improve latency
that much. There are a number of cases to consider, but off the top
of my head you get between 0-1/2 RTT by switching to ephemeral
exchange, depending on how much information the client has
about the server.

-Ekr

---

From: Watson Ladd <[email-masked]>
Date: Sat, 16 Nov 2013 21:13:05 -0800

> TLS is extensively used in both settings.
Actually, I take back what I said. ECC is much, much faster than RSA
on small devices
especially with hardware support. Static DH could be of interest here.
> exchange, depending on how much information the client has
If you use a signature, rather than an encrypted message, you get
three passes rather than four, and can send
arbitrary client data in the third pass that is authenticated and
encrypted. This is effectively a 1-RT protocol if
the client goes first in the application layer.

Sincerely,
Watson

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Nov 2013 21:26:34 -0800

> the client goes first in the application layer.

I'll revise what I said to 0-1RTT improvement. With that said...

- This depends on the client being able to send their share in the
first message, which requires some foreknowledge of what
parameters are acceptable.

- On repeated exchanges, the client can cache the server's
cert (Fast Track) and we're back to 1 RT.

- TLS with False Start is already 1RT, albeit without the client
being able to verify handshake correctness until he sees the
server's response.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 16 Nov 2013 21:29:33 -0800

On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <[email-masked]> wrote:
> explicitly not wanted

Oops, yeah, forgot to mention this.

As you say, it's possible to generate a short-term RSA key and use it
for multiple connections. This gives some level of forward security.

-Ekr

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 17 Nov 2013 16:28:23 +0100

On 17/11/2013 01:47, Eric Rescorla wrote:
> strictly faster than any ephemeral suite.

Yes, if you have an RSA certificate. OTOH, if in the coming years ECDSA
certificates become more popular, then ECDHE_ECDSA is less computationally
expensive for the server than static RSA, though more expensive for the client.

(By the way, having key exchanges that are less expensive for the server is also
good to make DOS attacks harder.)

> server key. ssldump and wireshark, for instance, both provide this
I don't know about ssldump, but with wireshark if you're interested in debugging
only a handful of sessions, it can directly use the premaster secret if you can
get your SSL library to display it (I know NSS can do it, I don't know if
OpenSSL can).

Also, it is possible to (temporarily) use static keys with a
supposedly-ephemeral (EC)DH key exchange and an option could be added to
wireshark and similar tools to take advantage of that.

Overall, I'd be inclined to drop static RSA key exchange in TLS 1.3 and allow
only ephemeral key exchanges (except maybe for the PSK key exchanges).

Manuel.

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 18 Nov 2013 18:53:51 -0800

On 11/16/2013 09:29 PM, Eric Rescorla wrote:
> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

Except that TLS 1.3 at least doesn't really make this possible with the
way that PKIX works now.  This could be changed.

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

--Andy

---

From: Geoffrey Keating <[email-masked]>
Date: 18 Nov 2013 19:20:59 -0800

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

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 18 Nov 2013 19:42:08 -0800

> than 10x slower, but that's on the server.)

I wonder how Curve25519 stacks up.

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

--Andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Nov 2013 09:58:25 -0500

On Sun, Nov 17, 2013 at 12:29 AM, Eric Rescorla <[email-masked]> wrote:

> On Sat, Nov 16, 2013 at 8:28 PM, Geoffrey Keating <[email-masked]>wrote:
>>

Rob Stradling and I were kicking around a scheme that was similar a few
weeks back.

The goal here is not so much forward secrecy as to increase the work factor
for an attacker. We have been considering short lived certs as a mechanism
for addressing the revocation issue for some time. Generating a new cert
with a different key each time does not increase the effort a great deal if
it is thought about at the start.

The precondition for any scheme that involves daily cert issue is that it
be fully automated. And this is the part that needs work. Specifically we
need:

1) Web servers able to switch certificates and keys without a reboot.
2) Automatic generation of key sets and CSRs in advance
3) Automatic issue of certificates.

Note that (2) and (3) are separate because we might well want to use
different tools to do each one. We might even want to do the process in
bulk and generate a whole year's worth of keys at once and the
corresponding CSRs and upload the whole lot to the CA in one go.

It is good to have ephemeral keying AS WELL. But we are currently limited
to only 1024 bits of EK due to the support issues. I would like more.

---

From: Marsh Ray <[email-masked]>
Date: Wed, 20 Nov 2013 01:50:05 +0000

From: Eric Rescorla
> being able to verify handshake correctness until he sees the

Might be worth mentioning that False Start on a client was enough
to enable the CRIME attack even if the legitimate server had
compression disabled.

In many ways, common implementations dodged the bullet with
CRIME. But this is an example where aggressive randomized
padding might have saved the day.

Saving every possible half-roundtrip brings huge rewards, and
I'm all for it. But it has its risks too.

- Marsh