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

[Adam Langley <[e-mail]>]

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

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

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

> Notice that, since the key exchange is done before the server sends its ServerHello, the CertificateStatus, CertificateRequest, Certificate, CertificateVerify, and NewSessionTicket messages can be encrypted and authenticated simply by placing them after the Finished messages, instead of before them. This would provide the extra benefit of even better privacy for the client user than previous attempts like [1] and [2], including unlinkability of session tickets (but still subject to traffic analysis).

I like encrypting as much as possible in principle.

> Like I mentioned before, I think snap start should be modified so that only the initial ClientHello-embedded application-data is encrypted/authenticated using the keys derived purely from client-supplied information. All the subsequent application data should be protected using new keys derived using a random value generated by the server. For many applications, this would greatly reduce the impact of many replay attacks that weren't caught due to some error on the server side in managing the strike register, because it would provide the same guarantee as standard TLS that the server would *never* reuse IVs and keys, even if the client did. And, this change may  allow may allow many applications to work securely even *without* a strike register. For example, it seems like a public search engine that allowed read-only queries wouldn't necessarily need a strike register if this modification were made to snap start.

Your point about making sure that the server never reuses an IV + Key
is a very good one. I would want to consider it for a couple of days
but, at this point, I think it has sufficient merit to warrant
changing Snap Start. I suspect that my thinking was clouded because it
wouldn't have been easy in the original formulation of Snap Start, but
is much more so with the current one.

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.

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. (And I'm probably pointing out the obvious when I say that DNSSEC
seems to provide a convenient, dynamic trust base for that.)


AGL