Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 11 May 2010 16:34 UTC

Return-Path: <Nicolas.Williams@oracle.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 BBE013A6A80 for <tls@core3.amsl.com>; Tue, 11 May 2010 09:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.947
X-Spam-Level:
X-Spam-Status: No, score=-4.947 tagged_above=-999 required=5 tests=[AWL=1.651, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 NEzzg1bxXgQM for <tls@core3.amsl.com>; Tue, 11 May 2010 09:34:12 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id E36893A68DE for <tls@ietf.org>; Tue, 11 May 2010 09:34:11 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BGXs4Z019190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 May 2010 16:33:56 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4BCI6an010760; Tue, 11 May 2010 16:33:52 GMT
Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 255439181273595626; Tue, 11 May 2010 09:33:46 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 09:33:46 -0700
Date: Tue, 11 May 2010 11:33:41 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Message-ID: <20100511163339.GL9429@oracle.com>
References: <20100511155738.GJ9429@oracle.com> <C80F403B.AB91%stefan@aaa-sec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <C80F403B.AB91%stefan@aaa-sec.com>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: rcsinet15.oracle.com [148.87.113.117]
X-CT-RefId: str=0001.0A090209.4BE986F5.00BF:SCFMA4539811,ss=1,fgs=0
Cc: paul.hoffman@vpnc.org, tls@ietf.org
Subject: Re: [TLS] Collisions (Re: Nico's suggestions - Re: Consensus Call:
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 16:34:12 -0000

On Tue, May 11, 2010 at 05:11:23PM +0200, Stefan Santesson wrote:
> On 10-05-11 5:57 PM, "Nicolas Williams" <Nicolas.Williams@oracle.com> wrote:
> > b) the failure will eventually happen again (since the user will most
> > likely want to talk to the same servers whose objects' checksums
> > collided.
> > 
> 
> Yes, and with the cash for that server flushed, the client will be bound to
> retry without caching (since it has no data cached anymore).

It's not a forgone conclusion that the client will retry.  The retry
will have to be at the application layer, and the application might not
be prepared to retry (since it won't know that the fatal error isn't
quite so fatal).

> The client will then (typically) update it's cache on the next successful
> handshake and problem should be fixed.

If one collision arises once, it will arise again, and again, and again
until all or all-but-one of the colliding objects are retired from use.
The client will have to detect collisions and then mark colliding
objects as must-not-use-from-cache.

Detecting collisions is hard.  If the application does not retry then
you can only heuristically decide that fatal errors imply collisions,
which will often not be the case.  If the application does retry then
the collision can be detected.  The server can't detect collisions any
more reliably nor sooner than the client (the server may have less
context than the client), I think.

Nico
--