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

Martin Rex <mrex@sap.com> Tue, 11 May 2010 17:36 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 0B0663A6D40 for <tls@core3.amsl.com>; Tue, 11 May 2010 10:36:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.767
X-Spam-Level:
X-Spam-Status: No, score=-7.767 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 w4xjQgTPkVGc for <tls@core3.amsl.com>; Tue, 11 May 2010 10:36:42 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id EDDCF3A6A08 for <tls@ietf.org>; Tue, 11 May 2010 10:35:28 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4BHZFqm005119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 19:35:15 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005111735.o4BHZEl0023818@fs4113.wdf.sap.corp>
To: Nicolas.Williams@oracle.com (Nicolas Williams)
Date: Tue, 11 May 2010 19:35:14 +0200 (MEST)
In-Reply-To: <20100511170151.GM9429@oracle.com> from "Nicolas Williams" at May 11, 10 12:01:52 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 17:36:43 -0000

Nicolas Williams wrote:
> 
> On Tue, May 11, 2010 at 06:40:52PM +0200, Martin Rex wrote:
> > Nicolas Williams wrote:
> > > 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).
> > 
> > A theoretical possibility would be some kind of "epoch" counter by
> > the server (or more general "peer", when caching is later extended
> > to apply to client-side handshake data as well).  The server would
> > have to bump that counter whenever it knows (or can not rule out)
> > that the cachable data has changed.
> 
> That only helps when colliding objects all come from the same server.

I assumes that ought to be an implicit requirement,
-- but forgot about the possibility of NAT-style server-side
load-balancing that may send you to a different server on
each connection.

The "prior art" about caching in TLS is TLS session caching,
where the session cache ID is 32-octets...

It appears that in principle, the caching extension should use
mostly the same granularity and scoping as the TLS session cache.


> 
> > > > 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.
> > 
> > There is *NO* guarantee that there are _only_ valid and complete TLS records
> > left in the pipe.
> 
> Yeah, TLS handshakes are just not retriable.  You could have an
> extension that makes them retriable, but if the TLS-GSS extension
> foundered on state machine issues resulting from adding round-trips,
> then so would an extension that makes handshakes retriable.


The issue may be more complex.  What about a renegotiation handshake
under protection of a previous ciphersuite?  To what exact state do
you return when the server determines an error trying to process
the clients finished message?  What would it send back, under protection
or without, and what should the client reply, under protection or
without?  To me, that looks like a can of worms.

-Martin