Re: [TLS] [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 18:24 UTC
Return-Path: <Nicolas.Williams@sun.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 369A928C0DB; Wed, 4 Nov 2009 10:24:07 -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 cFzyz6RbV5ib; Wed, 4 Nov 2009 10:24:06 -0800 (PST)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 48FBF28C115; Wed, 4 Nov 2009 10:24:05 -0800 (PST)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4IOR1C003545; Wed, 4 Nov 2009 18:24:27 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 nA4IOQ3P064769; Wed, 4 Nov 2009 11:24:27 -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 nA4ICwiG008262; Wed, 4 Nov 2009 12:12:58 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4ICwiu008261; Wed, 4 Nov 2009 12:12:58 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 04 Nov 2009 12:12:58 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20091104181257.GY1105@Sun.COM>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BAE0E5@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87bpjico8b.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
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: Wed, 04 Nov 2009 18:24:07 -0000
On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: > <Pasi.Eronen@nokia.com> writes: > > > Can you check if the latest text proposals (Nico's email on > > October 30th, starting "I spoke at length with Larry", and > > my email earlier today) make the situation clearer? > > I have the same question as Martin Rex: what is the actual semantic that > is wanted? I thought I understood what was intended, but given this > discussion my understanding of what was intended may have been wrong. The desired semantic is that tls-unique channel bindings are a channel binding in the RFC5056 sense, for a "TLS channel", with this particular feature (from the I-D): o Channel binding type: unique (which RFC5056 defines). Was this not utterly clear already? How could it not have been? The only possible point of contention from the above description is just what a "TLS channel" might be. And the only reasons for that are: - RFC5246 and predecessors don't define a name for what we've been calling a "TLS connection"; - Session resumption might cause someone to be confused and think that tls-unique refers to the client's Finished message from the resumed session; - Re-negotiation might cause someone to be confused and think that tls-unique refers to the client's Finished message from the re-negotiated "TLS connection". Let's dispose of these for once and for all: - We shall use "TLS connection" to refer to the TLS state created by an exchange beginning with a Client Hello message, followed by a TLS handshake sequence (which involves a ServerHello, a variety of optional messages such as Certificate, and ends in an optional ChangeCipherSpec message exchange) followed by an exchange of Finished messages. - Session resumption establishes new state as per the previous definition of "TLS connection", therefore it establishes a new "TLS connection", even though session resumption does NOT establish a new session. Therefore, the tls-unique channel binding for a "TLS connection" that resumes a session, MUST be the client's Finished message from the new connection, not the old session. - Re-negotiation consists of initiating a new "TLS connection" while using another "TLS connection" record layer for integrity (and usually also confidentiality) protection of the re-negotiation. As such re-negotiation creates a new "TLS connection". In this case want the tls-unique channel binding to be used by the application to be that of the first "TLS connection", that is, the one whose ClientHello and handshake were not protected by any other "TLS connection". (It follows that even if the client does N re-negotiations, where N > 2, we still want the application to use the tls-unique channel binding of the first "TLS connection", the one whose handshake was not protected by any other "TLS connection".) Therefore a "TLS channel" is really: a "TLS connection", as defined above, whose handshake was not protected by any other "TLS connection". This is a significantly more rigorous description than the ones we've discussed so far. Do you agree that it's air-tight? Should I propose new text that adds the above definitions of "TLS connection" and "TLS channel"? I think I should, so I will, shortly. Nico --
- [TLS] Last Call: draft-altman-tls-channel-binding… The IESG
- Re: [TLS] lasgt call comments (st Call: draft-alt… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: Martin Rex
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Larry Zhu
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- [TLS] RESOLVED (Re: [sasl] lasgt call comments (s… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Peter Gutmann
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLVED (… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] Unrelated (Re: [CHANNEL-BINDING] RESOLV… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] Unrelated (Re: RESOLV… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Martin Rex
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Martin Rex
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Pasi.Eronen
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Michael D'Errico
- Re: [TLS] [sasl] lasgt call comments (st Call: dr… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Nicolas Williams
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Jeffrey Hutzelman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Sam Hartman
- Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [TLS] lasgt call comments (st Call: draft-alt… Simon Josefsson
- Re: [TLS] lasgt call comments (st Call: draft-alt… Nicolas Williams
- Re: [TLS] RESOLVED (Re: [sasl] lasgt call comment… Larry Zhu
- [TLS] New Problem (Was: Last Call: draft-altman-t… Nicolas Williams
- Re: [TLS] New Problem (Was: Last Call: draft-altm… Larry Zhu
- Re: [TLS] [CHANNEL-BINDING] New Problem (Was: Las… Nicolas Williams