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

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 10 May 2010 21:58 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A2DC53A6BA3 for <tls@core3.amsl.com>; Mon, 10 May 2010 14:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.475
X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id n4vsdWeqYiTP for <tls@core3.amsl.com>; Mon, 10 May 2010 14:58:08 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com []) by core3.amsl.com (Postfix) with ESMTP id 131A93A6A07 for <tls@ietf.org>; Mon, 10 May 2010 14:58:08 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com []) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4ALvpgS018963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 21:57:53 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com []) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AGYNEB019329; Mon, 10 May 2010 21:57:49 GMT
Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 252810901273528617; Mon, 10 May 2010 14:56:57 -0700
Received: from oracle.com (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 14:56:57 -0700
Date: Mon, 10 May 2010 16:56:52 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20100510215652.GA9429@oracle.com>
References: <AC1CFD94F59A264488DC2BEC3E890DE50A43B479@xmb-sjc-225.amer.cisco.com> <20100510190954.GV9429@oracle.com> <87r5lj4eee.fsf@mocca.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87r5lj4eee.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com []
X-CT-RefId: str=0001.0A090207.4BE88162.008D:SCFMA922111,ss=1,fgs=0
Cc: tls@ietf.org
Subject: [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: Mon, 10 May 2010 21:58:09 -0000

On Mon, May 10, 2010 at 11:48:09PM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> 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.