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

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 11 May 2010 19:28 UTC

Return-Path: <Nicolas.Williams@oracle.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 6A12F28C270 for <tls@core3.amsl.com>; Tue, 11 May 2010 12:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.767
X-Spam-Level:
X-Spam-Status: No, score=-3.767 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 6hzW7AXx6F6N for <tls@core3.amsl.com>; Tue, 11 May 2010 12:28:17 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id CB0AE3A6D0F for <tls@ietf.org>; Tue, 11 May 2010 12:24:52 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BJOe5t011652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 May 2010 19:24:41 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BFs1Yo015141; Tue, 11 May 2010 19:24:36 GMT
Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 255935861273605835; Tue, 11 May 2010 12:23:55 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 12:23:54 -0700
Date: Tue, 11 May 2010 14:23:50 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20100511192350.GS9429@oracle.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43B479@xmb-sjc-225.amer.cisco.com> <20100510190954.GV9429@oracle.com> <87r5lj4eee.fsf@mocca.josefsson.org> <20100510215652.GA9429@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100510215652.GA9429@oracle.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090207.4BE9AEF9.01DE:SCFMA922111,ss=1,fgs=0
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 19:28:22 -0000

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
--