Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Nicolas Williams <> Tue, 11 May 2010 15:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B709828C152 for <>; Tue, 11 May 2010 08:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.968
X-Spam-Status: No, score=-3.968 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cu8XKMYjh4kh for <>; Tue, 11 May 2010 08:58:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBD7E3A6985 for <>; Tue, 11 May 2010 08:58:13 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BFvv0T018909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 May 2010 15:57:58 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BFKCt3023766; Tue, 11 May 2010 15:57:56 GMT
Received: from by with ESMTP id 255301901273593467; Tue, 11 May 2010 08:57:47 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 08:57:44 -0700
Date: Tue, 11 May 2010 10:57:38 -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.0A090203.4BE97E86.01D7:SCFMA4539811,ss=1,fgs=0
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
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: Tue, 11 May 2010 15:58:14 -0000

On Tue, May 11, 2010 at 04:45:51PM +0200, Stefan Santesson wrote:
> Wouldn't this be solved automatically if the cache is flushed upon failure?

Not really:

a) the failed handshake will be visible to the application
(handshake_failure is a fatal error);

b) the failure will eventually happen again (since the user will most
likely want to talk to the same servers whose objects' checksums

I think you'll want to say that the cache must not be flushed, but
rather that objects with colliding checksums must be flagged as such so
that they are never used again via this extension.

Again, I expect this will not often be a problem, but when and if it is
then this problem might be difficult to diagnose and re-occur too often.

I think this argues for a cryptographic hash.  Collisions are not a
security problem here, but they are an operational problem.  IMO this
rules out FNV-1a.  Also, as Uri points out, you will want to have larger
numbers of hash bits (64 is too few for this application).