Subject: Re: [TLS] draft-agl-tls-snapstart-00

From: "Brian Smith" <[email-masked]>
Date: Mon, 5 Jul 2010 13:29:48 -0500

Adam Langley wrote:
> On Mon, Jun 21, 2010 at 10:53 AM, David McGrew <[email-masked]>
> wrote:
> > I suggest adding this as a requirement for the "orbit": it MUST be
> > generated uniquely at random by each server.  If virtualization is in
> > use, each instance of the server MUST generate and use a distinct orbit value.
> 
> I think I disagree. There are situations where servers would want to share an
> orbit: as described in section 7.

The orbit should uniquely identify the strike register, and the strike register should be responsible for generating a unique orbit ID for itself every time it experiences any kind of data loss and/or any time it gets reset. Any time the strike register sends a server an "not previously used" response, it must include the orbit ID in that response. If and only if the orbit IDs match and the response was "not previously used", the server may continue on using snap start for the connection. These policies will ensure that servers using different strike registers never use the same orbit ID, reduce the likelihood of silent data loss in the strike register, and still allow sharing. Using other policies would be a recipe for disaster.

> > An option that might be worth considering: have the server issue the
> > client a range of nonce values that can be included in the
> > server_random, and require the client to use them sequentially (e.g.
> > as integers) or at least in a non-decreasing way.  In this scheme, a
> > server can check for a replay by storing a single integer, instead of
> > the set of server_random values within the time window.  This would
> > have the benefit of removing the tension on window size.  Of course,
> > it will be necessary for the server_random to contain an actual random
> > value, because we want to retain that property of the protocol to the
> > greatest extent possible (e.g. to retain analyses of the key derivation
> > processes).
> 
> I don't think the space savings are worth the additional complexity.
> Consider a cluster which is terminating a million TLS connections/second. The
> strike register takes 24 bytes to store a server_random (no need to save the
> orbit) and 8 bytes of overhead per entry. If we allow a window of +/- 60 seconds
> then that's 4GB of state: which is nothing for such a cluster.

One advantage of David's suggestion is that the nonces could be used as the master secret during resumption, and the perfect forward secrecy of TLS using ephemeral key exchange could be improved from protecting individual sessions to protecting individual connections.

- Brian