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

Stefan Santesson <stefan@aaa-sec.com> Tue, 11 May 2010 22:00 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD6F3A6A48 for <tls@core3.amsl.com>; Tue, 11 May 2010 15:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level:
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u01W6LVpk9Ww for <tls@core3.amsl.com>; Tue, 11 May 2010 15:00:31 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 4F1213A6A88 for <tls@ietf.org>; Tue, 11 May 2010 15:00:29 -0700 (PDT)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 002FC28C5B8 for <tls@ietf.org>; Wed, 12 May 2010 00:00:25 +0200 (CEST)
Received: (qmail 59973 invoked from network); 11 May 2010 22:00:16 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <Nicolas.Williams@oracle.com>; 11 May 2010 22:00:16 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 23:00:15 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Nicolas Williams <Nicolas.Williams@oracle.com>, Simon Josefsson <simon@josefsson.org>
Message-ID: <C80F91FF.ABD6%stefan@aaa-sec.com>
Thread-Topic: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
Thread-Index: AcrxVVXz9T0b4Y+suUOS5cWL5Yl7Ww==
In-Reply-To: <20100511192350.GS9429@oracle.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 22:00:32 -0000

Nico,

For there to exist two server certificates with the same public key but
entirely different certificate data, which are crafted to create a hash
collision, you must have at least one bad certificate issued by a dishonest
CA who validates to a root trusted by the client.

If this is the case, then cached info is the least of your problems.

For example, you have real problems if that same bad CA issues the attacker
a certificate (with the same name but another public key) through which the
attacker (having the corresponding private key) actually can fool the client
to authenticate the attacker as the legitimate server.

On the other hand, I would not object to include a requirement that data
should/must only be cached from a successful handshake where the server is
successfully authenticated. That should remove any residue of this issue.

/Stefan



On 10-05-11 9:23 PM, "Nicolas Williams" <Nicolas.Williams@oracle.com> wrote:

> On Mon, May 10, 2010 at 04:56:52PM -0500, Nicolas Williams wrote:
>> On Mon, May 10, 2010 at 11:48:09PM +0200, Simon Josefsson wrote:
>>> 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.
> 
> I didn't think this through yesterday.  Let me try again.
> 
> The only way the collision could happen and the handshake succeed is (at
> least for the cipher suites I've thought about) if a) the two certs have
> the same public key, b) the client had seen one or both server certs
> earlier.
> 
> And the attack?  I think it could be mostly harmless because the server
> thinks the client authenticated the server as one entity name while the
> client thinks it authenticated the server as another -- but both server
> names must have been reasonably close to equivalent (HUGE assumption;
> keep reading).  Sure, the client could get redirected to another server,
> but only if the incorrect cert was properly signed, and only if the
> client cache learns about that object (more assumptions).
> 
> The devil's in the details!
> 
> Some of those devilish details:
> 
>  - Clients MUST NOT cache objects from failed handshakes.
> 
>  - Clients MAY cache objects from succesful handshakes, and only when
>    the clients authenticate the server (including validation of the
>    server's cert chain to a TA).
> 
>  - In particular there MUST NOT be any caching in cases where the server
>    is authenticated by the use of pre-shared certificates.
> 
>     - There must be no chance of caching objects when a user clicks
>       through one of those "give your money to the bad guys?" dialogs.
> 
> Any others?  Yes, I should review the document closely now.
> 
> Nico