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

Martin Rex <mrex@sap.com> Tue, 11 May 2010 13:41 UTC

Return-Path: <mrex@sap.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 41C353A68E7 for <tls@core3.amsl.com>; Tue, 11 May 2010 06:41:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.783
X-Spam-Level:
X-Spam-Status: No, score=-7.783 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 hwA78ju+jTA3 for <tls@core3.amsl.com>; Tue, 11 May 2010 06:41:27 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F16993A68E1 for <tls@ietf.org>; Tue, 11 May 2010 06:40:05 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4BDdpZ4025787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 15:39:51 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp>
To: Nicolas.Williams@oracle.com (Nicolas Williams)
Date: Tue, 11 May 2010 15:39:50 +0200 (MEST)
In-Reply-To: <20100510221531.GC9429@oracle.com> from "Nicolas Williams" at May 10, 10 05:15:32 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
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
Reply-To: mrex@sap.com
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 13:41:28 -0000

Nicolas Williams wrote:
> 
> Stefan Santesson wrote:
> > 
> > What if a collision occurs?
> > 
> > That is pretty deterministic too. The server and the client may then agree
> > on a cached value by mistake. They will then go ahead and try to complete
> > the handshake with different opinions on a cached security critical value,
> > such as disagreeing about the server certificate chain. This will inevitably
> > lead to a handshake failure.
> 
> That's what I thought.
> 
> > 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()?

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.
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.


It is generally impossible to recover from a TLS handshake failure.
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).

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.


-Martin