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

Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 11 May 2010 15:23 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 F28C73A6CE3 for <tls@core3.amsl.com>; Tue, 11 May 2010 08:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.68
X-Spam-Level:
X-Spam-Status: No, score=-3.68 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_40=-0.185, 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 Nah3BTaUjRTY for <tls@core3.amsl.com>; Tue, 11 May 2010 08:23:05 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 336E53A689C for <tls@ietf.org>; Tue, 11 May 2010 08:22:40 -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 o4BFMD0r017346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 May 2010 15:22:14 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 o4B7P2F0022096; Tue, 11 May 2010 15:22:10 GMT
Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 255168581273591327; Tue, 11 May 2010 08:22:07 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 May 2010 08:22:03 -0700
Date: Tue, 11 May 2010 10:21:54 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Martin Rex <mrex@sap.com>
Message-ID: <20100511152153.GF9429@oracle.com>
References: <20100510221531.GC9429@oracle.com> <201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp>
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.0A090204.4BE97626.0205: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 15:23:07 -0000

On Tue, May 11, 2010 at 03:39:50PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > 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()?
> 
> Re-thinking this scenario, I do not think that is a workable approach.
> 
> The reason why I originally asked for using a (sha-1) hash value over the
> replaced data instead of a simple, server-assigned identifier,
> was robustness.  Going through a handshake failure is _NOT_ an option.

That's what I expect as well, that handshake failure is not transparent
to _all_ applications, and that any retry logic will have to be in the
application.  That makes this protocol a bit problematic -- failures
will be rare, no doubt, so rare that we might not care, but when they
happen the application won't know that the failure is not permanent.
For browsers that may not be a problem (the user will just reload); for
non-browser apps (and scripts running in the browser!) this could be a
problem.

> I wanted to avoid the cache of the server and client to get out-of-sync,
> and the use of a sha-1 hash value over the real data instead of that
> data should be sufficiently robust so that the server will send the
> real data in case the clients cached value differs from what the
> server would normally send.

I don't see how to recover from collisions, transparently to apps,
without either adding round-trips, which is supposed to be a big no-no,
or making handshakes retriable (I'm assuming they aren't).

> It is generally impossible to recover from a TLS handshake failure.

Well, the app can retry.

Also, StartTLS protocols might be able to retry without the application
having to disconnect/reconnect.

> It normally requires closure of the existing connection and opening
> of a new connection because it is completely unspecified how to
> recover from a TLS handshake failure on a connection (and how to
> clear the network pipe from unprocessed data from the previous handshake).

It's easy to clear the "pipe" since the records have lengths.

> If a client-side proxy traversal is involved, a full app-level proxy
> handshake is required.  If proxy traversal requires an OTP authentication,
> it will be completely impossible without user interaction.

Is there such a thing as proxies that require OTP for authentication?

Nico
--