Re: [TLS] Single round trip abbreviated handshake

[Adam Langley <[e-mail]>]

On Tue, Feb 2, 2010 at 11:12 PM, Ravi Ganesan <[e-mail]> wrote:
> Adam/Google was going down this road independently. Adam has suggested
> server-random = function(client-random, unix-gmt, epoch) where last
> value is derived from Server cert.

At the moment, OCSP disk caches and OCSP stapling are the low hanging
latency fruit, but this idea has been knocked around at Google.

However, I didn't explain the 'epoch' bit very well in my emails to
Ravi so I'll try again.

The goal is to give the server an nonce. If the server chooses a long
random string then the job is obviously done. However, if the server
promises to only accept each nonce once, for all time, then we have an
nonce via another route. In order for the server to do this it needs
to bound its storage. Loose clock synchronisation gets us that. The
server can make a trade off between how loose and how much storage.

The epoch value was intended to be learnt by the client (since the
clients need to know the server's certificate before hand anyway) and
used to segment the nonce space. Consider two different clusters on
different sides of the world, both using the same certificate. Without
an epoch value (which would be specific to each cluster) they would
have to synchronise with each other for every new nonce.

Also, it's very expensive to provide durable transactions for
frequently changing data. If we kept the "used nonce" store in memory
then we would need a way to invalidate all previous nonces in the
event of a power failure or other data loss. Changing the epoch value
would suffice here.

However, having the server's nonce be non-fresh leads to this attack:

Client (A) performs a 0-RTT setup to a server (B). This means that it
sends (somehow) enough information for a valid server to extract
application data with no additional round trips. An attacker (M)
intercepts A's traffic and stops it. A sees a timeout as B never
replies. However, the nonce was never used, so M can replay A's
message at a later time.

This suggests that 0-RTT techniques could only be used when the
request is side-effect free (as GETs are supposed to be in HTTP).

That rather scary and we shant be rushing into anything here.


AGL