Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> On Tue, May 11, 2010 at 06:40:52PM +0200, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > I don't see how to recover from collisions, transparently to apps,
> > > without either adding round-trips, which is supposed to be a big no-no,
> > > or making handshakes retriable (I'm assuming they aren't).
> > 
> > A theoretical possibility would be some kind of "epoch" counter by
> > the server (or more general "peer", when caching is later extended
> > to apply to client-side handshake data as well).  The server would
> > have to bump that counter whenever it knows (or can not rule out)
> > that the cachable data has changed.
> 
> That only helps when colliding objects all come from the same server.

I assumes that ought to be an implicit requirement,
-- but forgot about the possibility of NAT-style server-side
load-balancing that may send you to a different server on
each connection.

The "prior art" about caching in TLS is TLS session caching,
where the session cache ID is 32-octets...

It appears that in principle, the caching extension should use
mostly the same granularity and scoping as the TLS session cache.


> 
> > > > It normally requires closure of the existing connection and opening
> > > > of a new connection because it is completely unspecified how to
> > > > recover from a TLS handshake failure on a connection (and how to
> > > > clear the network pipe from unprocessed data from the previous handshake).
> > > 
> > > It's easy to clear the "pipe" since the records have lengths.
> > 
> > There is *NO* guarantee that there are _only_ valid and complete TLS records
> > left in the pipe.
> 
> Yeah, TLS handshakes are just not retriable.  You could have an
> extension that makes them retriable, but if the TLS-GSS extension
> foundered on state machine issues resulting from adding round-trips,
> then so would an extension that makes handshakes retriable.


The issue may be more complex.  What about a renegotiation handshake
under protection of a previous ciphersuite?  To what exact state do
you return when the server determines an error trying to process
the clients finished message?  What would it send back, under protection
or without, and what should the client reply, under protection or
without?  To me, that looks like a can of worms.

-Martin