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

[Stefan Santesson <[e-mail]>]

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.

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.

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)

What if this is a cluster and two servers give out different identifiers for
the same cached object???  To me this simply smells like a lot of
un-necessary problems.

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.

Upon a failed cached handshake, the client and server tries a new handshake
without caching, updates it's cache and moves on with life.

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?

/Stefan