IETF Logo Mail Archive

Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

Stefan Santesson <stefan@aaa-sec.com> Tue, 11 May 2010 23:06 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 4AE663A68F0 for <tls@core3.amsl.com>; Tue, 11 May 2010 16:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 HO1YurKeBTGB for <tls@core3.amsl.com>; Tue, 11 May 2010 16:06:34 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id 59A713A6864 for <tls@ietf.org>; Tue, 11 May 2010 16:06:33 -0700 (PDT)
Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 795D7349C20 for <tls@ietf.org>; Wed, 12 May 2010 01:06:05 +0200 (CEST)
Received: (qmail 60645 invoked from network); 11 May 2010 23:05:55 -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 <marsh@extendedsubset.com>; 11 May 2010 23:05:55 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 23:05:55 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Marsh Ray <marsh@extendedsubset.com>
Message-ID: <C80F9353.ABE0%stefan@aaa-sec.com>
Thread-Topic: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
Thread-Index: AcrxXoJfj3Uo0vkWB0OPlW6lTvDRnA==
In-Reply-To: <4BE9E06B.5000706@extendedsubset.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, tls@ietf.org
Subject: Re: [TLS] Collisions (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: Tue, 11 May 2010 23:06:35 -0000

On 10-05-12 12:55 AM, "Marsh Ray" <marsh@extendedsubset.com> wrote:

> 
>> On the other hand, I would not object to include a requirement that data
>> should/must only be cached from a successful handshake where the server is
>> successfully authenticated. That should remove any residue of this issue.
> 
> If "successfully authenticated" is only fully determined sometime after
> returning application code, does that mean that this extension should
> never come enabled by default for a TLS library?

There is a difference between passing path validation, which is done by the
crypto library, and deciding if the certificate subject is an appropriate
entity, which is done by the application.

In this case I think it is enough that the certificate pass path validation
to a trusted root.

/Stefan

v2.23.0 | Report a Bug | By Email