Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call: FNV vs SHA1)

Stefan Santesson <stefan@aaa-sec.com> Mon, 10 May 2010 22:07 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 CB7A93A68AE for <tls@core3.amsl.com>; Mon, 10 May 2010 15:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.295
X-Spam-Level:
X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_40=-0.185, 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 1JrSiddbicbf for <tls@core3.amsl.com>; Mon, 10 May 2010 15:07:03 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id B85B93A6767 for <tls@ietf.org>; Mon, 10 May 2010 15:07:03 -0700 (PDT)
Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 6CFE928A598 for <tls@ietf.org>; Tue, 11 May 2010 00:07:00 +0200 (CEST)
Received: (qmail 27357 invoked from network); 10 May 2010 22:06:51 -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 s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <Nicolas.Williams@oracle.com>; 10 May 2010 22:06:51 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 00:06:48 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <C80E5018.AB2B%stefan@aaa-sec.com>
Thread-Topic: Collisions (Re: Nico's suggestions - Re: [TLS] Consensus Call: FNV vs SHA1)
Thread-Index: AcrwjRXIFxVym9h7e0mtYH83kHWRUA==
In-Reply-To: <20100510213924.GY9429@oracle.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tls@ietf.org
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - 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 22:07:04 -0000

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

>> On the last question I think the correct answer is: Yes it is possible to do
>> a variant of the protocol without a hash function but it does not make the
>> protocol any better. Rather it make it worse. Both in terms of functionality
>> and complexity.
> 
> That's just a statement without an argument; I'm unconvinced.  Convince
> us.  If you can show that collisions don't result in failure to complete
> a TLS handshake successfully then all will be fine, so start there.
> Else I think you should explain how a collision-free protocol would be
> worse than the current proposal, then we could weigh the two approaches.

Yeah I know,

I was hoping I didn't have to since we have been through that debate
already.

If you force the Server to assign identifier you are adding complexity to
the protocol. The server now need to remember the relationship between
identifiers and objects instead of just calculating them when needed.

It also limits functionality since the client now first have to ask each
server about their identifiers, store them (per server) and replay them to
the server. With a hash, the client can try caching directly without first
asking the server for it's identifiers as soon as the client have a guess
about the cached info (e.g. By pulling info from a repository)

What if this is a cluster and two servers give out different identifiers for
the same cached object???  To me this simply smells like a lot of
un-necessary problems.

What if a collision occurs?

That is pretty deterministic too. The server and the client may then agree
on a cached value by mistake. They will then go ahead and try to complete
the handshake with different opinions on a cached security critical value,
such as disagreeing about the server certificate chain. This will inevitably
lead to a handshake failure.

Upon a failed cached handshake, the client and server tries a new handshake
without caching, updates it's cache and moves on with life.

However, the risk that a 64 bit FNV will collide by mistake (not as a result
of a malicious attack) is so small that the risk inconvenience of a
collision is acceptable.

Does this make any sense?

/Stefan