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

Nicolas Williams <> Mon, 10 May 2010 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF22F3A6931 for <>; Mon, 10 May 2010 15:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.083
X-Spam-Status: No, score=-4.083 tagged_above=-999 required=5 tests=[AWL=1.026, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PZGpwY24mNz5 for <>; Mon, 10 May 2010 15:16:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB7B53A6800 for <>; Mon, 10 May 2010 15:16:44 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AMGOLx020035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 22:16:27 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4AMGMlH002103; Mon, 10 May 2010 22:16:23 GMT
Received: from by with ESMTP id 229325161273529737; Mon, 10 May 2010 15:15:37 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 May 2010 15:15:36 -0700
Date: Mon, 10 May 2010 17:15:32 -0500
From: Nicolas Williams <>
To: Stefan Santesson <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: []
X-CT-RefId: str=0001.0A090204.4BE885BC.0077:SCFMA922111,ss=1,fgs=0
Cc: Paul Hoffman <>,
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - 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: Mon, 10 May 2010 22:16:45 -0000

On Tue, May 11, 2010 at 12:06:48AM +0200, Stefan Santesson wrote:
> On 10-05-10 11:39 PM, "Nicolas Williams" <>
> 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.

That's fine: I'd have accepted a URL to that debate.

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

The server sure could use a hash, leaving it to the operator to look for
and address collisions.

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

True!  That's one thing I was looking for.  It's more than enough for me
to prefer the client-hashes approach to the server-assigns object IDs

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

That's what I thought.

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

Well...  Many applications might not.  Can the handshake be retried
transparently to the application?  Or will the application have to
close() its socket and re-connect()?

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

Just a pair of questions left (see above).