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

[Geoffrey Keating <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

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

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!