Re: [TLS] Consensus Call: FNV vs SHA1

Simon Josefsson <> Mon, 10 May 2010 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D5343A6AA0 for <>; Mon, 10 May 2010 14:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.486
X-Spam-Status: No, score=-1.486 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_20=-0.74]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mXiJWMDkhA99 for <>; Mon, 10 May 2010 14:48:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EAF483A6A58 for <>; Mon, 10 May 2010 14:48:23 -0700 (PDT)
Received: from mocca ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4ALm9XU015429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Mon, 10 May 2010 23:48:10 +0200
From: Simon Josefsson <>
References: <> <>
OpenPGP: id=B565716F; url=
Date: Mon, 10 May 2010 23:48:09 +0200
In-Reply-To: <> (Nicolas Williams's message of "Mon, 10 May 2010 14:09:55 -0500")
Message-ID: <>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.96 at yxa-v
X-Virus-Status: Clean
Subject: Re: [TLS] 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 21:48:26 -0000

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

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.

This requires a conspiring server, so maybe it is irrelevant.

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.

It is late here, so I may be totally missing some aspect.