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

Stefan Santesson <stefan@aaa-sec.com> Mon, 10 May 2010 21:32 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4FEF63A6801 for <tls@core3.amsl.com>; Mon, 10 May 2010 14:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.587
X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id j--6KnHynvmI for <tls@core3.amsl.com>; Mon, 10 May 2010 14:32:41 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se []) by core3.amsl.com (Postfix) with ESMTP id 2A4C43A68C0 for <tls@ietf.org>; Mon, 10 May 2010 14:32:39 -0700 (PDT)
Received: from s128.loopia.se (s34.loopia.se []) by s87.loopia.se (Postfix) with ESMTP id 5CCFA28E7CE for <tls@ietf.org>; Mon, 10 May 2010 23:32:35 +0200 (CEST)
Received: (qmail 21440 invoked from network); 10 May 2010 21:32:26 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO []) (stefan@fiddler.nu@[]) (envelope-sender <stefan@aaa-sec.com>) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <paul.hoffman@vpnc.org>; 10 May 2010 21:32:26 -0000
User-Agent: Microsoft-Entourage/
Date: Mon, 10 May 2010 23:32:24 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Nicolas Williams <Nicolas.Williams@oracle.com>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Message-ID: <C80E4808.AB1E%stefan@aaa-sec.com>
Thread-Topic: Nico's suggestions - Re: [TLS] Consensus Call: FNV vs SHA1
Thread-Index: AcrwiEeLJCtpvE8ooU2WO0hRQzipXg==
In-Reply-To: <p06240816c80e266db104@[]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: [TLS] 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 21:32:42 -0000

On 10-05-10 11:10 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
> 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
>> made:
>> - 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.

I'm OK with everything Nico suggests with respect to FNV (If Joe is fine
with an informational reference to a web page)

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.