Re: [TLS] Ephemeral key exchange in TLS Snap Start (was RE: TLS Snap Start)

["Brian Smith" <[e-mail]>]

Adam Langley wrote:
> On Sat, Jul 31, 2010 at 6:37 PM, Brian Smith <[e-mail]> wrote:
> > 1. An extension (or new cipher suites) for indicating that the (EC)DH
> parameters in a ServerKeyExchange message are not really ephemeral, but
> rather are reusable for a certain duration of time. This part could be used reused
> independently of the other parts.
> 
> I believe that this is isomorphic to (EC)DH_(RSA|DSS). Although I must admit that
> I've never seen a fixed DH TLS connection, and a brief check of the RFC wasn't
> enlightening. I'm not aware of the standard format for (EC)DH_(RSA|DSS)
> certificates, although I suppose that the
> X.509 PublicKey field is flexible enough to admit a fixed DH value.

A certificate with fixed D-H parameters (ECDH or DH) puts the D-H parameters in the public key field. The _RSA|_DSS|_ECDSA at the end simply refers to the signature algorithm used to signed the certificate by the CA. That means you cannot use the same certificate for ECDH_RSA and RSA or for DH_RSA and RSA, because the public key formats don't match. So, if you want to support fixed D-H parameters AND also support regular RSA key exchange, you need TWO certificates, at least. And, you need a server that is willing and able to choose a certificate based on the negotiated cipher suite, which Apache/mod_ssl/OpenSSL cannot even do, and which many clients (including NSS and many other very popular ones) do not support. So, it isn't surprising that we don't see fixed DH parameter certificates in the wild. Further, I searched around and I could not find any indication from *any* commercial CA that they would be willing to issue a certificate with a ECDH, DH, or general-purpose ECC (which allows ECDH and ECDSA) public key.

But, even without those obstacles, there is another major one: rotating encryption keys by replacing certificates is a very tedious and error-prone manual process that has no tools available to automate it. And, setting up this kind of certificate rotation seems beyond what we can reasonably expect typical web server administrators to understand and care about, as the vast majority of documentation on configuring a SSL server is of the form "Here's the bare minimum to get a client to connect; don't touch anything after you see it working."

> If the server
> knew that the client could trust the fixed DH value via another means (i.e.
> DNSSEC) then the signature of the certificate could be omitted and the
> _(RSA|DSS) part rendered moot.

I agree that DNSSEC seems like a great idea, except we are still very far off from being able to rely on DNSSEC anywhere, and in some parts of the world, DNSSEC may not happen for a very long time. IMO, we can achieve the same effects much faster by creating a new set of "short-term static ECDH" cipher suites that allow one to use a plain old RSA certificate to sign a timestamped set of reusable ECDH parameters that are transmitted in the ServerKeyExchange message--much like ECDHE, but with additional signed parameters indicating the validity of the ECDH parameters.

> > 2. An extension that allows the client to put its ClientKeyExchange in a
> ClientHello extension. For DHE key exchanges, this would depend on the
> preceding extension.
> 
> I believe that the fixed DH value would be included in the client's certificate with
> (EC)DH_(RSA|DSS). Again, probably unsigned.

I think we have some miscommunication here. The vast majority of the time, there will be no client certificate. And, when there is a client certificate, it will almost never have fixed DH parameters. And, when it does have them, they mean something different than what I understand you to mean here.

> > Given #1 and #2, the handshake would be optimized to a sequence similar to
> session resumption, but allowing a request for client authentication:
> 
> (I intended that Snap start already allow for client-side certificates, although
> none of my unittests verify this.)

The current formulation of snap start requires the client to prove proof of possession of the user's private key (i.e. prove the user's identity) before the server identifies itself. This is a problem inherited from regular TLS's RSA key exchange. The (EC)DH(E) cipher suites require the server to prove possession of the server private key first, which is extremely helpful when the user has to decide whether or not to send his certificate. IMO, this means that client certificates shouldn't be used at all with RSA key exchange.

> In general, I see EDH as much more of a spectrum than the dichotomy that I
> often find it presented as. At one extreme, multiple EDH handshakes could be
> performed in a single connection to protect different time spans of that
> connection. At the other, the practice of rotating RSA keys every year provides
> some forward security: a compromise of this year's key doesn't allow for
> retrospective decryption of last year's traffic.

Almost all of the incentives for a server operator are to use RSA key as long as possible, unless they somehow have an understanding of forward secrecy. First, CAs give you deep discounts for buying certificates with longer validity periods (up to five or even ten years). And, nothing forces (and little documentation even encourages) a sysadmin to generate a new RSA private key when renewing certificates. I wouldn't be surprised to find that a huge number of servers on the internet are using the same RSA keys basically in perpetuity. When key rotation does happen, the tools available are so error-prone that they key rotation process itself becomes a very likely point of key compromise. And, how many server private keys get backed up every day, unprotected, in virtually permanent storage? These are the main reasons I advocate against using RSA key exchange. A new "short-term static ECDH" key exchange method would allow a server (cluster) to securely and frequently (e.g. daily) rotate encryption keys, autonomously, in a way that is much less error prone while potentially being much less expensive computationally than RSA key exchange.

> When using ECDHE with a 224-bit curve (or larger), I think key compromise is the
> greatest danger. The work required to calculate discrete logs in such a large
> group suggests that, if accomplished, the attacker probably has such a
> monumental breakthrough (i.e. a quantum computer) that per-connection EDH
> probably isn't going to present much more of a challenge.
> 
> Therefore, rotating a fixed DH value at some frequency may well provide a
> better performance/security trade-off than per-connection EDH.

I agree. 

> (And I'm
> probably pointing out the obvious when I say that DNSSEC seems to provide a
> convenient, dynamic trust base for that.)

It seems unlikely that we will be able to depend on any such mechanism any time soon. I am not even sure that we'll need TLS at the time that such a mechanism becomes generally useful. That's why I think an in-protocol solution is better.

Regards,
Brian