Re: [TLS] Consensus Call: FNV vs SHA1

Paul Hoffman <> Mon, 10 May 2010 21:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18FDB3A6C09 for <>; Mon, 10 May 2010 14:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.758
X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-1.312, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1luxuU84fAlf for <>; Mon, 10 May 2010 14:15:32 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) by (Postfix) with ESMTP id 6BABF3A6C0E for <>; Mon, 10 May 2010 14:14:08 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id o4ALAbHF093110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 May 2010 14:10:38 -0700 (MST) (envelope-from
Mime-Version: 1.0
Message-Id: <p06240816c80e266db104@[]>
In-Reply-To: <>
References: <> <>
Date: Mon, 10 May 2010 14:10:35 -0700
To: Nicolas Williams <>, "Joseph Salowey (jsalowey)" <>
From: Paul Hoffman <>
Content-Type: text/plain; charset="us-ascii"
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:15:35 -0000

At 2:09 PM -0500 5/10/10, Nicolas Williams wrote:
>On Mon, May 10, 2010 at 10:39:28AM -0700, Joseph Salowey (jsalowey) wrote:
>> I don't see much new being added to this discussion at this point.  I'd
>> like to close on this.  If you have an opinion please indicate if:
>> a) You favor SHA-1
>> b) You favor FNV-1a
>I lean towards (a) from a purely political point of view: I don't think
>it's a good idea to train auditors to act reflexively.  However, from a
>purely technical point of view I have no preference whatsoever at this
>time, but I'd like answers to my questions below.
>If the consensus is (b) then I think the following changes should be
> - Add an informative reference to FNV (and expand the acronym).
> - Refer to FNV as a checksum (or even hash, or better, non-
>   cryptographic hash) rather than as a digest.
>   In the context of TLS )RFC5246), "digest" definitely refers to
>   cryptographic hash functions.  We should not confuse the terminology.
> - 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?
>   Also, could caching have been done without reference to hash
>   functions?  E.g., by having servers assign IDs to objects for client
>   caching?  Is it too late to consider this approach?

Again, +1 to what Nico says here. If we're trying to make using FNV sensible for future use as well, let's do the work to get it right here.

--Paul Hoffman, Director
--VPN Consortium