IETF Logo Mail Archive

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

Stefan Santesson <stefan@aaa-sec.com> Mon, 10 May 2010 22:29 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 4311F3A69FC for <tls@core3.amsl.com>; Mon, 10 May 2010 15:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level:
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.778, 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 o52btvU9oZ1l for <tls@core3.amsl.com>; Mon, 10 May 2010 15:29:54 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.112]) by core3.amsl.com (Postfix) with ESMTP id BCEAD3A69CE for <tls@ietf.org>; Mon, 10 May 2010 15:29:54 -0700 (PDT)
Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id AA17328FD5E for <tls@ietf.org>; Tue, 11 May 2010 00:29:51 +0200 (CEST)
Received: (qmail 86672 invoked from network); 10 May 2010 22:29:42 -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 s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <Nicolas.Williams@oracle.com>; 10 May 2010 22:29:42 -0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Tue, 11 May 2010 00:29:39 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Nicolas Williams <Nicolas.Williams@oracle.com>
Message-ID: <C80E5573.AB33%stefan@aaa-sec.com>
Thread-Topic: Collisions (Re: Nico's suggestions - Re: [TLS] Consensus Call: FNV vs SHA1)
Thread-Index: AcrwkEb2SBWQ8QPpvkC1m1RsaEnXkg==
In-Reply-To: <20100510221531.GC9429@oracle.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, tls@ietf.org
Subject: Re: [TLS] Collisions (Re: 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 22:29:56 -0000

On 10-05-11 12:15 AM, "Nicolas Williams" <Nicolas.Williams@oracle.com>
wrote:

>> Upon a failed cached handshake, the client and server tries a new handshake
>> without caching, updates it's cache and moves on with life.
> 
> Well...  Many applications might not.  Can the handshake be retried
> transparently to the application?  Or will the application have to
> close() its socket and re-connect()?

I agree that the draft may be underspecified here.

Would it help to say that upon handshake failure using cached information,
client and servers MUST NOT retry the same handshake using the same cached
information.

I would expect this to be totally transparent to a client application above
the socket.

/Stefan

v2.2.0 | Report a Bug | By Email