[TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

[Nicolas Williams <[e-mail]>]

On Mon, May 10, 2010 at 11:48:09PM +0200, Simon Josefsson wrote:
> Nicolas Williams <[e-mail]> writes:
> 
> >  - Add a description of what happens if cached object checksums collide.
> >
> >    No, the current security considerations section doesn't deal with
> >    this, and rightly so _if_ collisions are not a security problem, but
> >    what happens when there are collisions?  Do hanshakes fail?
> 
> I agree that it is important to explain this.
> 
> If collisions happen, it appears that we do get slightly weaker
> semantics of what it means for a handshake to succeed: we aren't
> cryptographically certain (in the sense that there is cryptographic
> reduction) that the client and server agree on the data used during the
> handshake for cached items (CA cert list, server certificate) after the
> handshake has concluded.

In the success case I think we are certain that we don't care about
collisions, if there were any: the cryptographic properties of TLS
ensure this.

It's the failure case I'm concerned with.  If failures occur, how do you
recover?  If failures occur, will users want this?

> It seems a server could easily create two pairs of server certificates
> that results in the same FNV-1a value but are different certificates.  A
> client connecting to a server offering a cached value for the server
> certificate would not know which server certificate was intended, even
> after completing the handshake.  If correct, that seems surprising.

If the server figures it out, who cares.  If not, bad.

> This requires a conspiring server, so maybe it is irrelevant.

Or just a CA to issue colliding certs.  Think rollover.

> This problem would be solved if the Finished message were computed over
> the replaced data rather than the digest value.  Then any data
> mismatches would be detected at the TLS Finished computation, and the
> handshake fail.  Perhaps this is simpler than introducing a
> cryptographic digest.

I think modifying the way Finished msgs are computed would make this
protocol way too complicated.  I'd be happier with the server assigning
object IDs to cacheable objects.

Nico
--