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