From wwwrun@core3.amsl.com Mon Oct 5 09:27:04 2009 Return-Path: X-Original-To: channel-binding@ietf.org Delivered-To: channel-binding@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8C1B43A6873; Mon, 5 Oct 2009 09:27:04 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091005162704.8C1B43A6873@core3.amsl.com> Date: Mon, 5 Oct 2009 09:27:04 -0700 (PDT) X-Mailman-Approved-At: Mon, 05 Oct 2009 09:41:22 -0700 Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: [CHANNEL-BINDING] Last 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 Reply-To: ietf@ietf.org List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 16:27:04 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Channel Bindings for TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15087&rfc_flag=0 From simon@josefsson.org Tue Oct 6 00:44:24 2009 Return-Path: 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 8C65228C0E7; Tue, 6 Oct 2009 00:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] 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 Vllv-l258bf8; Tue, 6 Oct 2009 00:44:15 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5331E28C0ED; Tue, 6 Oct 2009 00:43:51 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n967jHqX028098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Oct 2009 09:45:21 +0200 From: Simon Josefsson To: ietf@ietf.org, channel-binding@ietf.org References: <20091005162704.8C1B43A6873@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091006:ietf@ietf.org::MwQOCeKte9kqyda7:0N33 X-Hashcash: 1:22:091006:sasl@ietf.org::1nUD5UkSGoFoKEJo:1YYF X-Hashcash: 1:22:091006:tls@ietf.org::IvURsjl2DE3wv/ov:6Y/O X-Hashcash: 1:22:091006:ietf-announce@ietf.org::oF2ogzltAizjTR5K:5/iY X-Hashcash: 1:22:091006:channel-binding@ietf.org::nm5rJ8Z0+IzUCM3M:6+YJ Date: Tue, 06 Oct 2009 09:45:16 +0200 In-Reply-To: <20091005162704.8C1B43A6873@core3.amsl.com> (The IESG's message of "Mon, 5 Oct 2009 09:27:04 -0700 (PDT)") Message-ID: <87vditezjn.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Subject: Re: [CHANNEL-BINDING] Last 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 07:44:25 -0000 I support the goal of this document, i.e. to publish the text in the IANA repository as an RFC. There are differences between the text in the current IANA repository and the document. These differences are not spelled out in the document for the 'tls-server-end-point' channel binding. The document says: Note that the only material changes from the original registration should be: the "owner" (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. That is not correct, compare the content registered with IANA The hash of the TLS server's end entity certificate as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's end entity certificate.) The hash function to be selected is as follows: if the certificate's signature hash algorithm is either MD5 or SHA-1, then use SHA-256, otherwise use the certificate's signature hash algorithm. The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. with what the document says: The hash of the TLS server's certificate [RFC5280] as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's certificate). The hash function is to be selected as follows: o if the certificate's signatureAlgorithm uses a single hash function, and that hash function is either MD5 [RFC1321] or SHA-1 [RFC3174] then use SHA-256 [FIPS-180-2]; o if the certificate's signatureAlgorithm uses a single hash function and that hash function neither MD5 nor SHA-1, then use the hash function associated with the certificate's signatureAlgorithm; o if the certificate's signatureAlgorithm uses no hash functions or multiple hash functions, then this channel binding type's channel bindings are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises). The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. I suggest that the first paragraph quoted above from section 4 is modified like this: OLD: Note that the only material changes from the original registration should be: the "owner" (now the IESG), the contacts, the published specfication, and a note indicating that the published specification should be consulted for applicability advice. NEW: Note that the only material changes from the original registration should be: the "owner" (now the IESG), the contacts, the published specfication, and a clarification to the description related to certificate's that do not use hash functions or use multiple hash functions. We also added a note indicating that this specification contains applicability advice, and we moved security considerations notes to the security considerations section of this document. The last sentence is copied from section 3 for consistency. Also missing is in section 3 and section 5 is a note that references were added to the text. I suggest: OLD: ...security considerations section of this document. All other fields of the registration are copied here for the convenience of readers. NEW: ...security considerations section of this document. References were added to the description. All other fields of the registration are copied here for the convenience of readers. /Simon From Nicolas.Williams@sun.com Tue Oct 6 08:43:36 2009 Return-Path: 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 D995C3A69FF; Tue, 6 Oct 2009 08:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.887 X-Spam-Level: X-Spam-Status: No, score=-5.887 tagged_above=-999 required=5 tests=[AWL=0.159, 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 lUsYlqBEA96y; Tue, 6 Oct 2009 08:43:36 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 8225A3A69FD; Tue, 6 Oct 2009 08:43:35 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n96FjCiD008340; Tue, 6 Oct 2009 15:45:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n96FjClr054739; Tue, 6 Oct 2009 09:45:12 -0600 (MDT) 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 n96FXs6B005025; Tue, 6 Oct 2009 10:33:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n96FXrZv005024; Tue, 6 Oct 2009 10:33:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 6 Oct 2009 10:33:53 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091006153353.GI887@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87vditezjn.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vditezjn.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, ietf@ietf.org Subject: Re: [CHANNEL-BINDING] Last 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 15:43:37 -0000 On Tue, Oct 06, 2009 at 09:45:16AM +0200, Simon Josefsson wrote: > I support the goal of this document, i.e. to publish the text in the > IANA repository as an RFC. > > There are differences between the text in the current IANA repository > and the document. These differences are not spelled out in the document > for the 'tls-server-end-point' channel binding. The document says: > > Note that the only material changes from the original registration > should be: the "owner" (now the IESG), the contacts, the published > specfication, and a note indicating that the published specification > should be consulted for applicability advice. > > That is not correct, compare the content registered with IANA This is true, though the difference isn't likely to have any real impact, ever. That may be why I neglected to update the above note. > I suggest that the first paragraph quoted above from section 4 is > modified like this: > > OLD: > Note that the only material changes from the original registration > should be: the "owner" (now the IESG), the contacts, the published > specfication, and a note indicating that the published specification > should be consulted for applicability advice. > > NEW: > Note that the only material changes from the original registration > should be: the "owner" (now the IESG), the contacts, the published > specfication, and a clarification to the description related to > certificate's that do not use hash functions or use multiple hash ^ remove apostrophe. > functions. We also added a note indicating that this specification > contains applicability advice, and we moved security considerations > notes to the security considerations section of this document. > > The last sentence is copied from section 3 for consistency. > > Also missing is in section 3 and section 5 is a note that references > were added to the text. I suggest: > > OLD: > ...security considerations section of this document. All other > fields of the registration are copied here for the convenience of > readers. > > NEW: > ...security considerations section of this document. References were > added to the description. All other fields of the registration are > copied here for the convenience of readers. I'm happy with your proposed changes. Nico -- From Pasi.Eronen@nokia.com Wed Oct 28 06:27:05 2009 Return-Path: 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 CEEAA28C18C; Wed, 28 Oct 2009 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 lhryLCXE0z5U; Wed, 28 Oct 2009 06:27:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 83EB328C171; Wed, 28 Oct 2009 06:27:04 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9SDQ5HJ027250; Wed, 28 Oct 2009 15:27:16 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:27:11 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 15:27:07 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Wed, 28 Oct 2009 14:27:07 +0100 From: To: , , , Date: Wed, 28 Oct 2009 14:27:04 +0100 Thread-Topic: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV7fuvme20kL+T0ihZxz3sI4KRJEa9Icg Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Oct 2009 13:27:07.0071 (UTC) FILETIME=[585CDCF0:01CA57D2] X-Nokia-AV: Clean Subject: Re: [CHANNEL-BINDING] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 13:27:05 -0000 Larry, Could you elaborate a bit about your first paragraph? =20 Certainly the TLS library knows when there's a new connection, because it receives (on the server) or sends (on the client) an unencrypted=20 ClientHello message? Best regards, Pasi > -----Original Message----- > From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of > ext Larry Zhu > Sent: 28 October, 2009 12:18 > To: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: Re: [sasl] lasgt call comments (st Call: draft-altman-tls- > channel-bindings (Channel Bindings for TLS) to Proposed Standard) >=20 >=20 > 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. >=20 > It would be much easier to say the following instead: >=20 > 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). >=20 > And the updated text does reflect what has been deployed for tls- > unique. >=20 > I would like to raise a red flag now. Needless to say that I will start > a discussion with the responsible AD and the rest of the editors of > this ID to fix this issue, and do so based on consensus. >=20 > Pasi, please consider this issue blocking for now. >=20 > Thanks, >=20 > --Larry >=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel > Bindings for TLS) to Proposed Standard >=20 > The IESG has received a request from an individual submitter to > consider > the following document: >=20 > - 'Channel Bindings for TLS ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings- > 07.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag > =3D15087&rfc_flag=3D0 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl From simon@josefsson.org Wed Oct 28 07:11:18 2009 Return-Path: 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 D8E1E28C1B0; Wed, 28 Oct 2009 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] 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 TZl2EdaCDI2z; Wed, 28 Oct 2009 07:11:17 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 6598028C187; Wed, 28 Oct 2009 07:11:16 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SEBRaQ017498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 15:11:29 +0100 From: Simon Josefsson To: Larry Zhu References: <20091005162704.8C1B43A6873@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091028:larry.zhu@microsoft.com::EI86AA0//9OMStfJ:369+ X-Hashcash: 1:22:091028:sasl@ietf.org::xFFGQYY2sXIzmc8Z:BtXJ X-Hashcash: 1:22:091028:channel-binding@ietf.org::7scYWHr9BwUTqkD3:Ajbd X-Hashcash: 1:22:091028:tls@ietf.org::dREygPsbHj7GTjNV:xGjQ Date: Wed, 28 Oct 2009 15:11:28 +0100 In-Reply-To: (Larry Zhu's message of "Wed, 28 Oct 2009 10:18:04 +0000") Message-ID: <87ocnrpq0f.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:11:19 -0000 I agree with Larry that the current definition of tls-unique is impossible to implement in TLS libraries in the way you'd typically want, i.e., a tls_get_tls_unique_cb() function. However, there IS a way that TLS libraries can support the current approach: add a callback interface to provide applications with the TLS Finished message, and let the application handle the complexities regarding connections vs session. That is what I decided to do in GnuTLS, a callback like this: typedef void (*gnutls_finished_callback_func) (gnutls_session_t session, const void *finished, size_t len); void gnutls_session_set_finished_function (gnutls_session_t session, gnutls_finished_callback_func func); Generally, I'm not happy with draft-altman-tls-channel-bindings so if this is an opportunity to consider alternatives I want to remind you of this work: http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt It makes sure to bind the channel binding uniquely to BOTH the current connection and the current session. The draft-altman-tls-channel-bindings-07 document only binds to the current TLS connection. So from this perspective, my work has the same issue, but it is different in other aspects. /Simon Larry Zhu writes: > 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). > > And the updated text does reflect what has been deployed for tls-unique. > > I would like to raise a red flag now. Needless to say that I will start a discussion with the responsible AD and the rest of the editors of this ID to fix this issue, and do so based on consensus. > > Pasi, please consider this issue blocking for now. > > Thanks, > > --Larry > > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Channel Bindings for TLS ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15087&rfc_flag=0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Wed Oct 28 07:23:59 2009 Return-Path: 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 C266F3A688A; Wed, 28 Oct 2009 07:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599] 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 VZRpSDlW+eE5; Wed, 28 Oct 2009 07:23:59 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 8715B3A6802; Wed, 28 Oct 2009 07:23:58 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-24-211.bredband.comhem.se [80.216.24.211]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n9SEO9A5017808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Oct 2009 15:24:11 +0100 From: Simon Josefsson To: Larry Zhu References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091028:larry.zhu@microsoft.com::qCr4riIOKTCzZhd5:2Nly X-Hashcash: 1:22:091028:sasl@ietf.org::/qW9gdiPsqOxoR6Q:6gs2 X-Hashcash: 1:22:091028:tls@ietf.org::mZpenux+wCdG4ep7:8Ngg X-Hashcash: 1:22:091028:channel-binding@ietf.org::pddBusMwiZxZOSpQ:FPqa Date: Wed, 28 Oct 2009 15:24:09 +0100 In-Reply-To: <87ocnrpq0f.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 28 Oct 2009 15:11:28 +0100") Message-ID: <87hbtjppfa.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v X-Virus-Status: Clean Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 14:23:59 -0000 Simon Josefsson writes: > http://josefsson.org/sasl-gs2/draft-josefsson-sasl-tls-cb-02.txt > > It makes sure to bind the channel binding uniquely to BOTH the current > connection and the current session. The > draft-altman-tls-channel-bindings-07 document only binds to the current > TLS connection. So from this perspective, my work has the same issue, > but it is different in other aspects. This reminded me of an earlier observation, and it might be relevant to re-iterate it here. Consider this: Day 1: 1. Client establish TLS anon-anon to server. 2. User authenticates using SCRAM with channel binding to the TLS channel 3. User/client disconnects Day 2: 4. Client resumes the TLS anon-anon connection 5. Client rehandshake with X.509 client + server authentication 6. User authenticates using SCRAM with channel binding to the TLS channel 7. User/client disconnects Day 3: 7. Client resumes the TLS session 8. Client rehandshake it as anon-anon 9. User authenticates using SCRAM with channel binding to the TLS channel 10. User/client disconnects With draft-altman-tls-channel-bindings-07, the channel binding data used in all three SCRAM authentications is the same bit sequence. That means there is only an indirect cryptographic binding between the SCRAM user authentication and the X.509 client authentication. /Simon From Nicolas.Williams@sun.com Wed Oct 28 09:11:28 2009 Return-Path: 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 28BD83A6858; Wed, 28 Oct 2009 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.985 X-Spam-Level: X-Spam-Status: No, score=-5.985 tagged_above=-999 required=5 tests=[AWL=0.061, 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 eZUegWPx01qm; Wed, 28 Oct 2009 09:11:27 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 5B24D3A6847; Wed, 28 Oct 2009 09:11:27 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9SGBe3t009036; Wed, 28 Oct 2009 16:11:40 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 n9SGBeuK042429; Wed, 28 Oct 2009 10:11:40 -0600 (MDT) 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 n9SG0EOb002442; Wed, 28 Oct 2009 11:00:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SG0DF4002441; Wed, 28 Oct 2009 11:00:13 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 11:00:13 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028160013.GL1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:11:28 -0000 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). > > And the updated text does reflect what has been deployed for > tls-unique. > > I would like to raise a red flag now. Needless to say that I will > start a discussion with the responsible AD and the rest of the editors > of this ID to fix this issue, and do so based on consensus. > > Pasi, please consider this issue blocking for now. Larry, It's hard to parse your message because the words "connection" and "transport" have multiple possible meanings in this context. In any case we've discussed this before, and the _current_ text is what we reached consensus on earlier. I believe the current text says what I think you meant to say, in your e-mail. Nico -- From larry.zhu@microsoft.com Wed Oct 28 03:09:44 2009 Return-Path: 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 1C5DB3A6875; Wed, 28 Oct 2009 03:09:44 -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 iscsYzzLd9C6; Wed, 28 Oct 2009 03:09:43 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 4D3043A679C; Wed, 28 Oct 2009 03:09:43 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 03:10:11 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 03:09:58 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 28 Oct 2009 03:09:56 -0700 From: Larry Zhu To: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Thread-Topic: lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV7bNkYZKmFk3aUmrP688ZIDTOQ== Date: Wed, 28 Oct 2009 10:09:58 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> In-Reply-To: <20091005162704.8C1B43A6873@core3.amsl.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 X-Mailman-Approved-At: Wed, 28 Oct 2009 09:17:14 -0700 Subject: [CHANNEL-BINDING] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:09:44 -0000 There is a design issue in tls-unique. For vendors who implement TLS in a s= eparate library, the TLS library does not by itself control the transport t= herefore it would not know if there is a new connection, so that the curren= t 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). And the updated text does reflect what has been deployed for tls-unique. =20 I would like to raise a red flag now. Needless to say that I will start a d= iscussion with the responsible AD and the rest of the editors of this ID to= fix this issue, and do so based on consensus.=20 Pasi, please consider this issue blocking for now. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The I= ESG Sent: Monday, October 05, 2009 9:27 AM To: IETF-Announce Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindin= gs for TLS) to Proposed Standard The IESG has received a request from an individual submitter to consider=20 the following document: - 'Channel Bindings for TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-02. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.tx= t IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D15087&rfc_flag=3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From larry.zhu@microsoft.com Wed Oct 28 03:17:49 2009 Return-Path: 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 E97B83A679C; Wed, 28 Oct 2009 03:17:49 -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 2IKN+Ft8fX88; Wed, 28 Oct 2009 03:17:49 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 1A5003A67D8; Wed, 28 Oct 2009 03:17:49 -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 03:18:03 -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 03:18:03 -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 03:18:04 -0700 From: Larry Zhu To: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Thread-Topic: lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV7fuvme20kL+T0ihZxz3sI4KRA== Date: Wed, 28 Oct 2009 10:18:04 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.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 X-Mailman-Approved-At: Wed, 28 Oct 2009 09:17:14 -0700 Subject: Re: [CHANNEL-BINDING] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 10:17:50 -0000 There is a design issue in tls-unique. For vendors who implement TLS in a s= eparate library, the TLS library does not by itself control the transport t= herefore it would not know if there is a new connection, so that the curren= t 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). And the updated text does reflect what has been deployed for tls-unique. =20 I would like to raise a red flag now. Needless to say that I will start a d= iscussion with the responsible AD and the rest of the editors of this ID to= fix this issue, and do so based on consensus.=20 Pasi, please consider this issue blocking for now. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of The I= ESG Sent: Monday, October 05, 2009 9:27 AM To: IETF-Announce Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel Bindin= gs for TLS) to Proposed Standard The IESG has received a request from an individual submitter to consider=20 the following document: - 'Channel Bindings for TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-11-02. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings-07.tx= t IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D15087&rfc_flag=3D0 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Oct 28 09:44:48 2009 Return-Path: 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 4E3663A68AC; Wed, 28 Oct 2009 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.059, 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 DAVGvXcO6lh9; Wed, 28 Oct 2009 09:44:47 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id E9B1E28C205; Wed, 28 Oct 2009 09:44:34 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SGin5V013332; Wed, 28 Oct 2009 16:44:49 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SGinsL050176; Wed, 28 Oct 2009 10:44:49 -0600 (MDT) 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 n9SGXNJL002486; Wed, 28 Oct 2009 11:33:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SGXN8L002485; Wed, 28 Oct 2009 11:33:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 11:33:23 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028163322.GO1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091028160013.GL1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091028160013.GL1105@Sun.COM> User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] [TLS] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:44:48 -0000 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 -- From larry.zhu@microsoft.com Wed Oct 28 13:59:41 2009 Return-Path: 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 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 To: Nicolas Williams 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: References: <20091005162704.8C1B43A6873@core3.amsl.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" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] [TLS] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:59:41 -0000 How about The client's TLS Finished message (note: the Finished=20 struct) in the clear text form from the first handshake of=20 the TLS session as identified by the=20 session ID in the server=20 hello message, as defined in 7.4.1.3 of RFC5246,=20 of the last handshake in the current active TLS session. =20 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 t= hat. It does not hurt to create another label just to avoid potential inter= operability issues. This seems to be the most intuitive definition and we do not have any ambig= uity here. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as 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-ch= annel-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. > >=20 > > It would be much easier to say the following instead: > >=20 > > 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=20 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 --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Oct 28 14:05:36 2009 Return-Path: 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 C38F828C104; Wed, 28 Oct 2009 14:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.028, 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 SzRPAwTuo+Ml; Wed, 28 Oct 2009 14:05:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C0A223A6989; Wed, 28 Oct 2009 14:05:35 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SL5pHS023180; Wed, 28 Oct 2009 21:05:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SL5oIa039884; Wed, 28 Oct 2009 15:05:51 -0600 (MDT) 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 n9SKsOxx002768; Wed, 28 Oct 2009 15:54:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SKsO3P002767; Wed, 28 Oct 2009 15:54:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 15:54:24 -0500 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091028205423.GG1105@Sun.COM> References: <20091028163322.GO1105@Sun.COM> <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call comments (st Call: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:05:36 -0000 On Wed, Oct 28, 2009 at 09:49:28PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > 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. > > This description/terminology about resume/previous/new/original session > is confusing and wrong. > > > If a TLS session is resumed, then the result is always the SAME session, > which is indicated by the use of the SAME session id (and internally, > by the use of the same underlying master secret). Yes, I know. That's why we had written "connection" instead of session! But now Larry finds that confusing as well. > A cached TLS session can be resumed quite often and simultaneously is > parallel (which leads to multiple parallel/forked sessions). > > The session keys are newly re-derived for each connection and each > session resume, and they should be unique because of the client > random and server random that go into the session key derivation > of every new connection (=resumed session). > > A resumed TLS session will also NOT exchange (and therefore not verify) > any certificates. Indeed. But it does exchange Finished messages. That's crucial here. > Since the finished messages of the tls handshake cover the > client random and server random of the SSL handshake, the finished > messages are going to be unique for each connection, even for > two resumes of the same session. Exactly. That's what we want. > > 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. > > Asking the TLS protocol stack to memorize the original finished message > sounds awkward to me. The thing that the ssl session cache is already > memorizing for a session is the master secret, so maybe deriving something > from that would be better suited for the purpose than a requirement to > store the original finished message. Argh, I've managed to confuse you too. I mean EXACTLY this: it's NOT the client Finished message from the _session_ that is being resumed (when one is), but the one for the connection. Martin, I appreciate your help, but we really need to hear from Larry, because I'm all confused, and as a result I'm confusing you too. Larry, can you please clarify? Nico -- From larry.zhu@microsoft.com Wed Oct 28 14:18:24 2009 Return-Path: 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 83D2028C14E; Wed, 28 Oct 2009 14:18:24 -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 xW-1jQJluLVc; Wed, 28 Oct 2009 14:18:23 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 630DD28C155; Wed, 28 Oct 2009 14:18:23 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 14:18:50 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server id 14.0.639.20; Wed, 28 Oct 2009 13:59:55 -0700 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 28 Oct 2009 13:59:52 -0700 From: Larry Zhu To: "Pasi.Eronen@nokia.com" , "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Thread-Topic: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AQHKV9Jq+JazopF2qkSChPC47bDhk5EbWFXw Date: Wed, 28 Oct 2009 20:59:53 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F66078D@NOK-EUMSG-01.mgdnok.nokia.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 Subject: Re: [CHANNEL-BINDING] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:18:24 -0000 Hi Pasi,=20 Thanks for allowing me to expand. A quick summary is that the tls-unique de= finition hinges on an ambiguous notation of "connection", and that is unnec= essary if not harmful.=20 To show why we should look at RFC5246 first. Please allow a disclaimer firs= t too. The following information is provided in order to demonstrate we can= make this better or over specified thus leave with no ambiguity therefore = improve interoperability. On page 39 of RFC 5246, we have the following text that describes the sessi= on id in the client hello message: The session identifier MAY be from an earlier connection, this connection, or from another currently active connection. This suggests that a connection can be associated with multiple sessions (a= s identified by "session IDs"). But then on page 79, we have the following = text Every connection is associated with one session. This seems to suggest a connection can only have one session (as identified= by a session ID). On page 81, we have the following text: Sessions are used to avoid the expensive negotiation of new security pa= rameters for each connection. Which seems to suggest that a session is identified by a session id. Do we = have a real inconsistency here?=20 With that it gets worse if we read the text on page 36: The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. Let's note the words "re-establish the connection" used here. It seems to s= uggest that in a TLS session resumption, we are merely re-establishing a pr= evious connection. There are evidences that suggest different interpretatio= ns exist as the recent responses from Joseph clearly demonstrated. Now the reader is left to wonder what really identifies a connection? Does = an unencrypted hello really demarcate a new connection as you suggested? If= we follow the path you suggested, it is desirable? If we interpret that a connection is one in the transport layer, the TLS li= brary does not know and should not care. In that case, it would have the pr= oblem I alluded earlier. Furthermore the current definition would not work with DTLS though if we th= row out the notion of "connection", say for example use the TLS session or = the last handshake, we can reuse the work for DTLS. I will discuss with the rest of the editor team and we should come up with = a recommendation for how to address this issue. Thanks, --Larry -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, October 28, 2009 6:27 AM To: Larry Zhu; channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: RE: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-= bindings (Channel Bindings for TLS) to Proposed Standard) Larry, Could you elaborate a bit about your first paragraph? =20 Certainly the TLS library knows when there's a new connection, because it receives (on the server) or sends (on the client) an unencrypted=20 ClientHello message? Best regards, Pasi > -----Original Message----- > From: sasl-bounces@ietf.org [mailto:sasl-bounces@ietf.org] On Behalf Of > ext Larry Zhu > Sent: 28 October, 2009 12:18 > To: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: Re: [sasl] lasgt call comments (st Call: draft-altman-tls- > channel-bindings (Channel Bindings for TLS) to Proposed Standard) >=20 >=20 > 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. >=20 > It would be much easier to say the following instead: >=20 > 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). >=20 > And the updated text does reflect what has been deployed for tls- > unique. >=20 > I would like to raise a red flag now. Needless to say that I will start > a discussion with the responsible AD and the rest of the editors of > this ID to fix this issue, and do so based on consensus. >=20 > Pasi, please consider this issue blocking for now. >=20 > Thanks, >=20 > --Larry >=20 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > The IESG > Sent: Monday, October 05, 2009 9:27 AM > To: IETF-Announce > Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org > Subject: [TLS] Last Call: draft-altman-tls-channel-bindings (Channel > Bindings for TLS) to Proposed Standard >=20 > The IESG has received a request from an individual submitter to > consider > the following document: >=20 > - 'Channel Bindings for TLS ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-11-02. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-altman-tls-channel-bindings- > 07.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag > =3D15087&rfc_flag=3D0 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > sasl mailing list > sasl@ietf.org > https://www.ietf.org/mailman/listinfo/sasl From Nicolas.Williams@sun.com Wed Oct 28 14:32:28 2009 Return-Path: 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 E0D0D3A68C3; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Z+Al+uglr3KS; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 121973A67F4; Wed, 28 Oct 2009 14:32:28 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9SLWhmO004701; Wed, 28 Oct 2009 21:32:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9SLWheo056711; Wed, 28 Oct 2009 15:32:43 -0600 (MDT) 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 n9SLLHlU002786; Wed, 28 Oct 2009 16:21:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SLLHC8002785; Wed, 28 Oct 2009 16:21:17 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 16:21:17 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091028212116.GI1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091028160013.GL1105@Sun.COM> <20091028163322.GO1105@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] [TLS] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:32:29 -0000 On Wed, Oct 28, 2009 at 08:59:53PM +0000, Larry Zhu wrote: > 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. Larry and I just spoke on the phone. The real issue is the word "connection". Apparently RFC5246 uses it in two senses, one of them being the-transport-layer-above-IP (i.e., TCP for TLS and UDP for DTLS, typically), and that is confusing. I explained to Larry that using "session" instead, as in his proposed text above is nearly impossible to implement, because it means updating session resumption state caches -- a very intrusive change to existing TLS implementations. What Larry really wants is to find a way to refer to what Microsoft's SSPI-based implementation of TLS calls a "security context". Advice on what would be the best TLS-specific term for "security context" is welcome. Nico -- From Martin.Rex@sap.com Wed Oct 28 13:49:18 2009 Return-Path: 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 910E73A6A6A; Wed, 28 Oct 2009 13:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qHyGQPzgBfkw; Wed, 28 Oct 2009 13:49:17 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DF1143A686C; Wed, 28 Oct 2009 13:49:15 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n9SKnSDG021053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 21:49:28 +0100 (MET) From: Martin Rex Message-Id: <200910282049.n9SKnSdG000971@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 28 Oct 2009 21:49:28 +0100 (MET) In-Reply-To: <20091028163322.GO1105@Sun.COM> from "Nicolas Williams" at Oct 28, 9 11:33:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Mailman-Approved-At: Thu, 29 Oct 2009 08:59:59 -0700 Cc: channel-binding@ietf.org, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call comments (st Call: X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:49:18 -0000 Nicolas Williams wrote: > > 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. This description/terminology about resume/previous/new/original session is confusing and wrong. If a TLS session is resumed, then the result is always the SAME session, which is indicated by the use of the SAME session id (and internally, by the use of the same underlying master secret). A cached TLS session can be resumed quite often and simultaneously is parallel (which leads to multiple parallel/forked sessions). The session keys are newly re-derived for each connection and each session resume, and they should be unique because of the client random and server random that go into the session key derivation of every new connection (=resumed session). A resumed TLS session will also NOT exchange (and therefore not verify) any certificates. A new TLS session is created when one of - the client does not propose TLS session resume at all - the server does not agree to TLS session resumption, and creates and returns a new/different session id and performs a full handshake - the client performs a renegotiate for an established session (usually upon request from the server) and the server goes through a full ssl handshake. Since the finished messages of the tls handshake cover the client random and server random of the SSL handshake, the finished messages are going to be unique for each connection, even for two resumes of the same session. > 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. Asking the TLS protocol stack to memorize the original finished message sounds awkward to me. The thing that the ssl session cache is already memorizing for a session is the master secret, so maybe deriving something from that would be better suited for the purpose than a requirement to store the original finished message. -Martin From Nicolas.Williams@sun.com Fri Oct 30 15:48:02 2009 Return-Path: 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 F411B3A68B1; Fri, 30 Oct 2009 15:48:01 -0700 (PDT) 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 tfIUfHhXy2Bj; Fri, 30 Oct 2009 15:48:01 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 0973B3A6843; Fri, 30 Oct 2009 15:48:00 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9UMmFPs019151; Fri, 30 Oct 2009 22:48:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9UMmFvG011443; Fri, 30 Oct 2009 16:48:15 -0600 (MDT) 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 n9UMamJo004135; Fri, 30 Oct 2009 17:36:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9UMam8c004134; Fri, 30 Oct 2009 17:36:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Oct 2009 17:36:48 -0500 From: Nicolas Williams To: Larry Zhu Message-ID: <20091030223647.GO1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: [CHANNEL-BINDING] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2009 22:48:02 -0000 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 --