Re: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))
Larry Zhu <larry.zhu@microsoft.com> Wed, 04 November 2009 22:13 UTC
Return-Path: <larry.zhu@microsoft.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 27DF83A68B3; Wed, 4 Nov 2009 14:13:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 f19SG883+Ot1; Wed, 4 Nov 2009 14:13:26 -0800 (PST)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 45BB83A688D; Wed, 4 Nov 2009 14:13:26 -0800 (PST)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 14:14:03 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 14:13:47 -0800
Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 14:13:48 -0800
From: Larry Zhu <larry.zhu@microsoft.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))
Thread-Index: AQHKWbNKKo89XNrhrEC3HCaJjhtWGJEmhAyA
Date: Wed, 04 Nov 2009 22:13:46 +0000
Message-ID: <D3DC9D45B39CFC4CB312B2DD279B354C29BBA0B3@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091030223647.GO1105@Sun.COM>
In-Reply-To: <20091030223647.GO1105@Sun.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "channel-binding@ietf.org" <channel-binding@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "sasl@ietf.org" <sasl@ietf.org>
Subject: Re: [TLS] RESOLVED (Re: [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 22:13:27 -0000
The proposed looks fine. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicolas Williams Sent: Friday, October 30, 2009 3:37 PM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) I spoke at length with Larry. His concern is that the word "conenction" might be taken to mean "TCP connection" or "connection for the transport below TLS". Clearly it is not reasonable to expect to extract the TLS channel binding from the "connection for the transport below TLS"! Larry's proposal to say "session" was only to make that confusion go away, but that proposal is very difficult to implement (as I described separately already). Larry has indicated to me (and I expect will indicate on the list in reply to this email) that he will be happy if we simply clarify that "TLS connection" refers to the TLS state, NOT to the transport below. Unfortunately RFC5246 does not seem to have a term by which to refer the "TLS connection" unambiguously: "connection" is defined in the glossary (page 80) to mean that which Larry doesn't want (underlying transport), but then, in section 6.1 RFC5246 quite clearly uses the word "connection" to refer to "TLS connection", not to the underlying transport. Thus this is a simple matter of wordsmithing. Another problem that Larry has is that in his implementation what I call a "TLS connection" is called a "security context", and if the application re-handshakes (e.g., to authenticate a user) then the result is a second security context -- we need to be extra clear that it's the client Finished message from the _first_ "security context" that we're after. My proposal, then, is this: OLD: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). NEW: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the application's TLS connection. NOTES: a) If a session is resumed, the client's TLS Finished message from the session resumption handshake is to be used; b) If a client does multiple TLS handshakes in sequence, each protected by the previous one, then the client's TLS Finished message from the first/outermost TLS connection is to be used; c) By "TLS connection" we refer to the TLS connection state, not to any notion of connection of any underlying transport protocols (such as TCP, UDP, SCTP, etcetera). I'm not sure that we can make it any clearer. Larry, please review. Martin, please review. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [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