Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 19:16 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 ADAEE3A67D1; Wed, 4 Nov 2009 11:16:37 -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 Da+PqbqLExUY; Wed, 4 Nov 2009 11:16:37 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CF8C73A68C1; Wed, 4 Nov 2009 11:16:36 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4JGwpH005532; Wed, 4 Nov 2009 19:16:58 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 nA4JGwMA037327; Wed, 4 Nov 2009 12:16:58 -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 nA4J5R1p008329; Wed, 4 Nov 2009 13:05:27 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4J5RLb008328; Wed, 4 Nov 2009 13:05:27 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 04 Nov 2009 13:05:27 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
Message-ID: <20091104190526.GB1105@Sun.COM>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> <20091104182704.GA1105@Sun.COM> <tsl4opaktdn.fsf@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <tsl4opaktdn.fsf@mit.edu>
User-Agent: Mutt/1.5.7i
Cc: Michael D'Errico <mike-list@pobox.com>, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))
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: Wed, 04 Nov 2009 19:16:37 -0000

On Wed, Nov 04, 2009 at 02:00:20PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@sun.com> writes:
> 
>     Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote:
>     >> I don't pretend to know exactly what this feature is supposed
>     >> to do, but I think using the word "connection" would be a
>     >> mistake given its widespread use meaning TCP connections, etc.
> 
>     Nicolas> At least the word 'connection' is used in RFC5246 _some_
>     Nicolas> times to mean what we were using it to mean here.
> 
> Sanity check here: For the most part, there is a one-to-one mapping
> between what we're talking about and TCP connections, right?  In

For the most part, yes.

> particular, for most applications, even applications with multiple
> finish messages, grabbing the first finish message from a TCP
> connection gives exactly the one we want.  Am I correctly
> understanding our goal?

Yes.

> If so, this sounds fairly pedantic.  Pedantic is not bad--we should
> get it to be correct.  However for most app developers, it seems that
> if they assume connection means tcp connection, the right thing will
> happen.  If that's not true, then we have a lot of explaining to do,
> because if I'm confused, then this is a hard problem to explain.

You're not confused.  I fully agree that we've gotten pedantic here.
I don't really understand how anyone could have thought that the channel
binding needed to be communicated to TCP, and thence to the application,
but that's how we got to this point.  Now that we're here, I think we
might as well consider whether we want to have extra rigorous text, or
whether we approve the document as is.

Nico
--