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

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> Stefan Santesson wrote:
> > 
> > What if a collision occurs?
> > 
> > That is pretty deterministic too. The server and the client may then agree
> > on a cached value by mistake. They will then go ahead and try to complete
> > the handshake with different opinions on a cached security critical value,
> > such as disagreeing about the server certificate chain. This will inevitably
> > lead to a handshake failure.
> 
> That's what I thought.
> 
> > Upon a failed cached handshake, the client and server tries a new handshake
> > without caching, updates it's cache and moves on with life.
> 
> Well...  Many applications might not.  Can the handshake be retried
> transparently to the application?  Or will the application have to
> close() its socket and re-connect()?

Re-thinking this scenario, I do not think that is a workable approach.

The reason why I originally asked for using a (sha-1) hash value over the
replaced data instead of a simple, server-assigned identifier,
was robustness.  Going through a handshake failure is _NOT_ an option.
I wanted to avoid the cache of the server and client to get out-of-sync,
and the use of a sha-1 hash value over the real data instead of that
data should be sufficiently robust so that the server will send the
real data in case the clients cached value differs from what the
server would normally send.


It is generally impossible to recover from a TLS handshake failure.
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).

If a client-side proxy traversal is involved, a full app-level proxy
handshake is required.  If proxy traversal requires an OTP authentication,
it will be completely impossible without user interaction.


-Martin