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

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> > 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.
> 
> 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.

> 
> > It is generally impossible to recover from a TLS handshake failure.
> 
> Well, the app can retry.
> 
> Also, StartTLS protocols might be able to retry without the application
> having to disconnect/reconnect.
> 
> > 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.

Flushing an orphaned closure alert is something that may be used to clear
a TLS connection after successful communication and a closure alert
handshake http://tools.ietf.org/html/rfc5246#section-7.2.1
but the current TLS spec doesn't provide grounds for interoperably clearing
a connection from residue of a failed TLS handshake.  It amounts to
heuristics based on good faith.


> 
> > 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.
> 
> Is there such a thing as proxies that require OTP for authentication?

I think that SOCKS has been used with OTP authentication.

TLS does't imply HTTP-over-TLS and client-side proxy doesn't imply
HTTP-proxy with CONNECT method and header-based authentication.


-Martin