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

Marsh Ray <> Tue, 11 May 2010 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F9D63A67B2 for <>; Tue, 11 May 2010 11:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.216
X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E7ntvPcbKzzO for <>; Tue, 11 May 2010 11:30:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B615D3A6D18 for <>; Tue, 11 May 2010 11:28:26 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OBuBj-000AHO-LO; Tue, 11 May 2010 18:28:15 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 146DC631D; Tue, 11 May 2010 18:28:12 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19seNRe/F3wFtbfrKAOlzdlh4mk3pgpA+I=
Message-ID: <>
Date: Tue, 11 May 2010 13:28:13 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Simon Josefsson <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 May 2010 18:30:59 -0000

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

> 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

- Marsh