[TLS] FNV versus SHA-1 in cached info

Stefan Santesson <stefan@aaa-sec.com> Fri, 07 May 2010 11:15 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 28E383A6CAF for <tls@core3.amsl.com>; Fri, 7 May 2010 04:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.576
X-Spam-Level: **
X-Spam-Status: No, score=2.576 tagged_above=-999 required=5 tests=[AWL=-1.671, BAYES_99=3.5, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 kzgdxra2X0v0 for <tls@core3.amsl.com>; Fri, 7 May 2010 04:14:57 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 5E5DF3A6B14 for <tls@ietf.org>; Fri, 7 May 2010 04:14:23 -0700 (PDT)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 52EAE28CFBF for <tls@ietf.org>; Fri, 7 May 2010 13:14:10 +0200 (CEST)
Received: (qmail 17393 invoked from network); 7 May 2010 11:14:05 -0000
Received: from unknown (HELO [192.168.1.3]) (stefan@fiddler.nu@[85.235.2.114]) (envelope-sender <stefan@aaa-sec.com>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <tls@ietf.org>; 7 May 2010 11:14:05 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Fri, 07 May 2010 13:14:04 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <C809C29C.A99B%stefan@aaa-sec.com>
Thread-Topic: FNV versus SHA-1 in cached info
Thread-Index: Acrt1mb76BxWpF2zLEmH7x0p3McNTQ==
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3356082846_30818394"
Subject: [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 11:15:02 -0000

At the recent IETF meeting in Anaheim, Eric announced that he was not all
that happy with the choice of FNV in the Cached info draft.

I have recently had an e-mail exchange with Eric on this matter where he
told med that he do not want to see FNV used over SHA-1 in a TLS protocol
and that he plans on sending a message on the subject to this list.

I would therefore like to kick off the discussion as I want us to conclude
this issue and publish the draft. There is no reason to drag this on
forever.

The reason I personally agreed to use FNV for this draft is not because it
is better than SHA-1, nor that it is easier to implement (provided you have
a crypto library with SHA-1 functionality). The rationales for me was to
avoid a politically charged situation where many automatically think you
need 1) a high level of security 2) algorithm agility and 3) negotiations to
ensure interoperability, as soon as a hash algorithm is used for anything.

It was evident from earlier discussions on the list that we could not get
out of this discussion and the unnecessary extra protocol complexity unless
we picked a non-cryptographic hash.

Eric told me that he do not like the uncertainly introduced by a new
algorithm.

I don¹t understand this argument in this case, when the selected algorithm
isn¹t required to provide security.
The only issues of relevance (that I can se) is:

1) Does FNV do the job to create reasonably unique identifiers of cached
objects?
2) Can FNV be implemented with reasonable expectation of interoperability?

The answer to both questions is YES.

The draft contains code samples and test vectors. We already have three test
implementations that has demonstrated interoperability by matching the test
vectors. Its fast and its extremely easy to implement.

I would not have any problem with using SHA-1 if it could be used with no
agility what so ever. But I seriously doubt that this will be accepted and
for that reason I would like to keep FNV.

Please provide your thoughts and comments so we can close this issue and
move on.

/Stefan