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

[Marsh Ray <[e-mail]>]

On 5/11/2010 2:59 AM, Simon Josefsson wrote:
> 
> I'm thinking about two scenarios:
> 
>  1) the undetectable modification of the list of acceptable CA names
>     cause the client to select and use an unintended certificate.
> 
>  2) where multiple server certificates can be used to successfully
>     establish the key.  That can happen if two certificates use the same
>     public key.  Once connected, the client will not know the server by
>     the same identity (certificate) as the server believe the client
>     used.

Frankly, this scares the hell out of me.

I admit now that part of why I supported the simple 'hashtable' function
was to ensure that this aspect got thoroughly analyzed.

> This is not an problem in the sense that an attacker gains some benefit
> (for 1 the client chose to proceed with the certificate

Hmm, this could enable an attacker to influence the client to choose a
client cert using different information than the server thought he sent,
and in a way which doesn't break the Finished hashes?

Let's say I have separate "administrator" and "normal user" client
certs, both recognized by a server. Could mitm trick me into authing
with the admin cert even if the server app didn't intend to ask for it?

Note MS IIS has a feature for client-cert-to-user mapping, so
theoretically that could end up running code with different actual user
permissions.

> and for 2 the
> attacker needs to know the private key of the server): instead I'm
> pointing at a semantic problem because, with the extension, the
> historically true invariant that the client, after handshake, will know
> which certificate the server used, does not hold strongly.
> 
> This doesn't necessarily have to affect the document in any way, but it
> is an interesting property.

Historically, it has turned out to be notoriously difficult to put
limits on the effects of a violated security guarantee. We may not be so
familiar with all the dependencies and assumptions made in the original
analysis that we can run through them backwards.

I recommend we walk through the security analysis on this again from
scratch. This time with extra focus on an attacker who can trivially
craft collisions.

Also, we should look into how this might interact with running multiple
servers on the same IP address (and same stack) using SNI. Sometimes
things that are secure in isolation do not produce a secure system when
composed.

- Marsh