Re: [TLS] [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, 28 October 2009 20:59 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 0D95B3A6A81; Wed, 28 Oct 2009 13:59:41 -0700 (PDT)
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 KgpZ4K5sm2WX; Wed, 28 Oct 2009 13:59:40 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 06DE83A6A6F; Wed, 28 Oct 2009 13:59:39 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 13:59:55 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 13:59:54 -0700
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, 28 Oct 2009 13:59:53 -0700
From: Larry Zhu <larry.zhu@microsoft.com>
To: Nicolas Williams <Nicolas.Williams@sun.com>
Thread-Topic: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
Thread-Index: AQHKV+4iBeoFgQlJYUez5TZwqZCo85EbZYWg
Date: Wed, 28 Oct 2009 20:59:53 +0000
Message-ID: <D3DC9D45B39CFC4CB312B2DD279B354C29BAEE4B@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BAE0E5@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com> <20091028160013.GL1105@Sun.COM> <20091028163322.GO1105@Sun.COM>
In-Reply-To: <20091028163322.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] [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, 28 Oct 2009 20:59:41 -0000
How about The client's TLS Finished message (note: the Finished struct) in the clear text form from the first handshake of the TLS session as identified by the session ID in the server hello message, as defined in 7.4.1.3 of RFC5246, of the last handshake in the current active TLS session. Can we label this as "tls-session-unique"? The existing deployment seems to have a different interpretation but we do not have a real usage case for that. It does not hurt to create another label just to avoid potential interoperability issues. This seems to be the most intuitive definition and we do not have any ambiguity here. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicolas Williams Sent: Wednesday, October 28, 2009 9:33 AM To: Larry Zhu 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) On Wed, Oct 28, 2009 at 11:00:13AM -0500, Nicolas Williams wrote: > On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote: > > There is a design issue in tls-unique. For vendors who implement TLS > > in a separate library, the TLS library does not by itself control the > > transport therefore it would not know if there is a new connection, so > > that the current specification is not implementable for these vendors. > > > > It would be much easier to say the following instead: > > > > The client's TLS Finished message from the first handshake of the > > session (note: TLS session, not connection, so that the channel > > binding is specific to each TLS session regardless of whether session > > resumption is used). I spoke to Jeff and I think I understand your issue, and I agree that we never meant for that interpretation. Proposed new text is below, but first... What the text says now: 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). I think we meant to say is that if you're a server, and you see a ClientHello, and you do a handshake and then receive a client Finished message, and then return a handle to the application for the resulting TLS whatever-you-call-it, then _that_ Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). Similarly, if you're a client and send a ClientHello and so on and so forth and then return a handle to the application for the resulting TLS whatever-you-call-it, then the first Finished message will be the channel binding, EVEN IF the client then does a second handshake (for re-keying, for authenticating the client, whatever). The reason we used the word "connection" in the description was to avoid the possibility that in a session resumption someone might interpret tls-unique to be the client Finished message of the original connection that established the session resumption state. Changing the text to say "session" instead of "connection" now would risk creating that confusion. The key issue here is how to write the description in such a way that it is obvious to a TLS implementor in spite of the fact that the words "connection", "session" and "transport" have multiple possible meanings in the contexts where TLS is used. Here, then, is my proposed clarification: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the TLS session. (Yes, I changed "connection" to "session", followed by this:) Clarification: If a connection resumes a previous session, then the Finished message to use is that of the new session, not the one from the original session. If a session has multiple handshakes and, therefore, multiple client Finished messages, the first client Finished message of that session is the one to use as the tls-unique channel binding. From an application programming interface (API) perspective, the client's Finished message is saved in the contextual object handle that the client and server applications obtain when they initiate or resume a TLS session; later, when the applications request the tls-unique channel binding, the TLS implementation retrieves the saved first client Finished message from that context handle. 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