Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 03 November 2009 22:49 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: channel-binding@core3.amsl.com
Delivered-To: channel-binding@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 185F73A67A8; Tue, 3 Nov 2009 14:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 1R8zGp1AD8iY; Tue, 3 Nov 2009 14:49:49 -0800 (PST)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 267FF3A63EB; Tue, 3 Nov 2009 14:49:49 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MoANU006199; Tue, 3 Nov 2009 22:50:10 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA3Mo9x2037720; Tue, 3 Nov 2009 15:50:09 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3McdsF007609; Tue, 3 Nov 2009 16:38:39 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3McdSB007608; Tue, 3 Nov 2009 16:38:39 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 03 Nov 2009 16:38:39 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091103223839.GL1105@Sun.COM>
References: <20091030223647.GO1105@Sun.COM> <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org
Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call:
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of channel binding IANA registry requests and specifications <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2009 22:49:50 -0000

On Mon, Nov 02, 2009 at 05:48:44PM +0100, Martin Rex wrote:
> And btw. Channel Binding at the application layer and
> transparent TLS-session renegotiation at the TLS layer appear
> somewhere between hard-to-do and mutually exclusive--in case
> that the TLS session renegotiation happens totally transparent
> to the application.

In order to do channel binding to TLS channels you MUST have some sort
of interface to TLS, and that interface MUST let you get at, in this
case, the first Finished message (in cleartext) sent by the client.

Such an interface necessarily implies that TLS can't be entirely
transparent to the application, though some aspects of TLS well might
be.

Session resumption and re-negotiation complicate how we identify that
one message, but they hardly make it impossible.  It gets more
complicated if a protocol were to multiplex multiple unrelated TLS
connections on one TCP/SCTP connection/association.   But it's still not
impossible: the application, after all, would be keeping track of the
various streams and keeping them logically separate.

In spite of the _text_ that we need to describe tls-unique being
complicated by session resumption and re-negotiation, the actual
interfaces and source code will be simple.  The complexity is primarily
the result of not having a handy word in the TLS terminology for what
the Microsoft SSPI interface to TLS calls "security context".  If TLS
did define such a term, then it'd be easier to specify tls-unique.

So far I see no real objections to the actual proposal.  Larry objected
that the text might make an implementor think that TLS channel bindings
are associated with TCP connections.  You and Simon would prefer to
speak of the Master secret because that doesn't change when you
re-negotiate -- but that's hardly enough to change gears now, and then
you'd have to bind in things that the Master secret doesn't bind (which
would correspondingly complicate your alternative).

Let's keep things simple.  Please review the proposed text.

Nico
--