Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call: FNV vs SHA1)

[Nicolas Williams <[e-mail]>]

On Tue, May 11, 2010 at 12:06:48AM +0200, Stefan Santesson wrote:
> On 10-05-10 11:39 PM, "Nicolas Williams" <[e-mail]>
> wrote:
> >> On the last question I think the correct answer is: Yes it is possible to do
> >> a variant of the protocol without a hash function but it does not make the
> >> protocol any better. Rather it make it worse. Both in terms of functionality
> >> and complexity.
> > 
> > That's just a statement without an argument; I'm unconvinced.  Convince
> > us.  If you can show that collisions don't result in failure to complete
> > a TLS handshake successfully then all will be fine, so start there.
> > Else I think you should explain how a collision-free protocol would be
> > worse than the current proposal, then we could weigh the two approaches.
> 
> Yeah I know,
> 
> I was hoping I didn't have to since we have been through that debate
> already.

That's fine: I'd have accepted a URL to that debate.

> If you force the Server to assign identifier you are adding complexity to
> the protocol. The server now need to remember the relationship between
> identifiers and objects instead of just calculating them when needed.

The server sure could use a hash, leaving it to the operator to look for
and address collisions.

> It also limits functionality since the client now first have to ask each
> server about their identifiers, store them (per server) and replay them to
> the server. With a hash, the client can try caching directly without first
> asking the server for it's identifiers as soon as the client have a guess
> about the cached info (e.g. By pulling info from a repository)

True!  That's one thing I was looking for.  It's more than enough for me
to prefer the client-hashes approach to the server-assigns object IDs
approach.

> 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()?

> However, the risk that a 64 bit FNV will collide by mistake (not as a result
> of a malicious attack) is so small that the risk inconvenience of a
> collision is acceptable.
> 
> Does this make any sense?

Just a pair of questions left (see above).

Nico
--