Re: [TLS] FNV versus SHA-1 in cached info

Stefan Santesson <stefan@aaa-sec.com> Fri, 07 May 2010 19:58 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80DC3A694D for <tls@core3.amsl.com>; Fri, 7 May 2010 12:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.943
X-Spam-Level:
X-Spam-Status: No, score=-0.943 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWkMLMVQUYJg for <tls@core3.amsl.com>; Fri, 7 May 2010 12:58:40 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 0DB1A3A6924 for <tls@ietf.org>; Fri, 7 May 2010 12:58:40 -0700 (PDT)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 4393828BC93 for <tls@ietf.org>; Fri, 7 May 2010 21:58:34 +0200 (CEST)
Received: (qmail 53102 invoked from network); 7 May 2010 19:58:28 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.16]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <uri@ll.mit.edu>; 7 May 2010 19:58:28 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Fri, 07 May 2010 21:58:24 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>, Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <C80A3D80.A9E5%stefan@aaa-sec.com>
Thread-Topic: [TLS] FNV versus SHA-1 in cached info
Thread-Index: AcruCuAmtDBKorKURySKCfXkytFOigAC05VBAAJeCOc=
In-Reply-To: <C809D93D.A4C1%uri@ll.mit.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] FNV versus SHA-1 in cached info
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: Fri, 07 May 2010 19:58:41 -0000

Let me remind that we started off with SHA-1 with no agility.

That kicked off a lot of debate whether agility was required and the general
opinion was that we needed agility, so agility was added.

That kicked off a long debate on what hash algorithm that should be
mandatory and what measures that should be in place to advertise supported
hash algorithms.

And this when discussion is held by prime experts.

I believe that we in this case have demonstrated our inability to agree on a
single cryptographic hash algorithm without agility, when no cryptographic
properties are required.

Except for that I think you are right. SHA-1 would work fine.

Is there anyone who has a compelling argument why FNV would be bad?

/Stefan 


On 10-05-07 8:50 PM, "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
wrote:

> Well, I have not seen a *convincing* rationale why cryptographically
> unsuitable algorithms must not be used in non-cryptographic applications,
> and I see no reason why formerly-cryptographic algorithms should be an
> exception from the above.
> 
> 
> On 5/7/10  13:28 , "Nicolas Williams" <Nicolas.Williams@oracle.com> wrote:
> 
>> On Fri, May 07, 2010 at 01:10:40PM -0400, Blumenthal, Uri - 0668 - MITLL
>> wrote:
>>> For cryptographic purposes agility is critical, and it's obvious.
>>> 
>>> For non-cryptographic purposes - who cares. Let the implementers figure what
>>> works best and "codify" it. If it's SHA - fine. If it's FNV - fine. If it's
>>> MD4 - fine. No sense avoiding cryptographically broken algorithms for
>>> non-cryptographic use.
>> 
>> I agree, but it's important to have a rationale for this position.  I
>> stated one.  Simon and others have stated rationales for the opposite
>> position (that we should not use MD5 nor SHA-1 even when cryptographic
>> properties are not required).
>> 
>> It'd be nice if we didn't have to revisit this every time someone needs
>> a non-cryptographic hash function in an Internet protocol.
>> 
>> Nico