From Martin.Rex@sap.com Mon Nov 2 06:59:30 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 702A33A657C; Mon, 2 Nov 2009 06:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.202 X-Spam-Level: X-Spam-Status: No, score=-6.202 tagged_above=-999 required=5 tests=[AWL=0.047, 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 597Bt2s2X7u1; Mon, 2 Nov 2009 06:59:29 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BF13128C14D; Mon, 2 Nov 2009 06:59:27 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2Exj5S008421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 15:59:45 +0100 (MET) From: Martin Rex Message-Id: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 2 Nov 2009 15:59:44 +0100 (MET) In-Reply-To: <20091030223647.GO1105@Sun.COM> from "Nicolas Williams" at Oct 30, 9 05:36:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: channel-binding@ietf.org, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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: Mon, 02 Nov 2009 14:59:30 -0000 Nicolas Williams wrote: > > 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. OooopS. The session that results from a re-handshake is an entirely new and independent session from what it started from, it does NOT modify the state of the original session (as identified by its TLS session ID). Many SSL protocol stacks, however, will perform the re-negotiation with the same "context" or API handle -- giving the application caller impression that the original session is modified. TLS does _NOT_ have capabilities to modify a session, however. It will either resume a cached session as proposed by the client as-is, or it will go through a full handshake and create a new session that is entirely independent from previous sessions. The TLS specs do not describe API semantics, however, only the network protocol and TLS session state, so your terminology is IMHO confusing. > > 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. b) sounds wrong to me. A renegotiate results in a entirely new and independent session. It might be easier to _NOT_ key on the finished message, but on the master secret instead. -Martin From simon@josefsson.org Mon Nov 2 07:55:35 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 279123A6A3D; Mon, 2 Nov 2009 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 l5BswaKrYCcm; Mon, 2 Nov 2009 07:55:34 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 116EC3A65A6; Mon, 2 Nov 2009 07:55:33 -0800 (PST) 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 nA2FtmIf027506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2009 16:55:50 +0100 From: Simon Josefsson To: mrex@sap.com References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091102:sasl@ietf.org::f95RzMcYqHmcRsGO:4eig X-Hashcash: 1:22:091102:tls@ietf.org::OsgaUW7ykzuMYTtl:IIUW X-Hashcash: 1:22:091102:mrex@sap.com::LD33Omjp0wiguZBd:VOow X-Hashcash: 1:22:091102:channel-binding@ietf.org::ot3ynh3vPUf301aj:MCBX X-Hashcash: 1:22:091102:nicolas.williams@sun.com::A5UJS+zrv3vz5mvf:Zljc Date: Mon, 02 Nov 2009 16:55:48 +0100 In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 2 Nov 2009 15:59:44 +0100 (MET)") Message-ID: <87hbtcc457.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, sasl@ietf.org, Nicolas Williams , tls@ietf.org Subject: Re: [CHANNEL-BINDING] RESOLVED (Re: [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: Mon, 02 Nov 2009 15:55:35 -0000 Martin Rex writes: > It might be easier to _NOT_ key on the finished message, but on the > master secret instead. That was my conclusion as well, hence http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 which uses the TLS PRF interface. For -02 I also added hashing the Finished message, to match the semantics for connection/session (regardless of its definition) of draft-altman-tls-channel-bindings, but I'd prefer to avoid it completely. /Simon From Martin.Rex@sap.com Mon Nov 2 08:34:53 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 EA0C73A67A5; Mon, 2 Nov 2009 08:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, 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 nIH4OQYLQ2zg; Mon, 2 Nov 2009 08:34:53 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id E8E4928C0ED; Mon, 2 Nov 2009 08:34:52 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA2GZBsu001915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:35:11 +0100 (MET) From: Martin Rex Message-Id: <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Mon, 2 Nov 2009 17:35:10 +0100 (MET) In-Reply-To: <87hbtcc457.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 2, 9 04:55:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, sasl@ietf.org, Nicolas.Williams@sun.com, tls@ietf.org Subject: Re: [CHANNEL-BINDING] RESOLVED (Re: [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: Mon, 02 Nov 2009 16:34:54 -0000 Simon Josefsson wrote: > > Martin Rex writes: > > > It might be easier to _NOT_ key on the finished message, but on the > > master secret instead. > > That was my conclusion as well, hence > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > which uses the TLS PRF interface. > > For -02 I also added hashing the Finished message, to match the > semantics for connection/session (regardless of its definition) of > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > completely. If you refer to the TLS-extractor interface with TLS PRF, that does unconditionally include the client.random and server.random in the computation and therefore the output will differ for different incarnations (resumes) of the same TLS session. That is comparable to keying to the _most_recent_ finished message -- with __NO__ special cased for TLS session resume and TLS renogiation. -Martin From Martin.Rex@sap.com Mon Nov 2 08:48: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 0ACB228C129; Mon, 2 Nov 2009 08:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=0.066, 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 Fbkr8vx-B1p6; Mon, 2 Nov 2009 08:48:27 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id DE27C28C0ED; Mon, 2 Nov 2009 08:48:26 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA2GmiQQ020042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:48:44 +0100 (MET) From: Martin Rex Message-Id: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Mon, 2 Nov 2009 17:48:44 +0100 (MET) In-Reply-To: <20091030223647.GO1105@Sun.COM> from "Nicolas Williams" at Oct 30, 9 05:36:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: channel-binding@ietf.org, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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: Mon, 02 Nov 2009 16:48:28 -0000 Nicolas Williams wrote: > > 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. Microsoft's implementation (which could be the one referred to by Larry's implementation) has a silly design flaw in its TLS renogiation, and I'm not sure that the previous text is a way to fix it. It is possible to configure Microsoft IIS in a fashion so that it will first perform a TLS handshake with a server-only authentication, and after having received the HTTP request, it will re-negotiate and ask for a client certificate. In the ClientHello, the client will send no TLS session ID (since the purpose is renegotiation -- aka a full TLS handshake. Microsoft IIS will send back a ServerHello with an entirely new TLS session ID. In my TLS clients, I will drop TLS sessions from the client-side cache for which the server asks for re-negotiation (actually replace them with the resulting renegotiated TLS session). Unfortunately, this doesn't save a TLS handshake on the next connect, Microsoft IIS will force another renegotiation when that re-negotiated session is resumed, resulting in yet another new TLS session. >From my experience, it is possible to TLS resume both, the original and the renegotiated session when Microsoft IIS is the server, and it will force through re-negotiation on both. So an IIS configured like that will artificially inflate its server-side session cache and impose unnecessary re-negotiations on the TLS client and on itself. And btw. Channel Binding at the application layer and transparent TLS-session renegotiation at the TLS layer appear somewhere between hard-to-do and mutually exclusive--in case that the TLS session renegotiation happens totally transparent to the application. -Martin From Martin.Rex@sap.com Tue Nov 3 04:43:04 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 96D5D28C17F; Tue, 3 Nov 2009 04:43:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 dzzVMJkPj1QD; Tue, 3 Nov 2009 04:43:03 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2C54528C149; Tue, 3 Nov 2009 04:43:02 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA3ChHnF008423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Nov 2009 13:43:17 +0100 (MET) From: Martin Rex Message-Id: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 3 Nov 2009 13:43:16 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Nov 3, 9 10:06:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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: Tue, 03 Nov 2009 12:43:04 -0000 Peter Gutmann wrote: > > Martin Rex writes: > > >Microsoft's implementation (which could be the one referred to by > >Larry's implementation) has a silly design flaw in its TLS renogiation, > >and I'm not sure that the previous text is a way to fix it. > > > >It is possible to configure Microsoft IIS in a fashion so that it > >will first perform a TLS handshake with a server-only authentication, > >and after having received the HTTP request, it will re-negotiate and > >ask for a client certificate. > > It's not necessarily a design flaw, AFAIK it's a performance optimisation to > avoid the server having to maintain state/leave a connection open for an > arbitrary amount of time while the user fumbles around with smart cards and > certificates and whatnot. I'm sorry if I have explained myself so badly. I was NOT talking about the closing of the connection while the client is prompting the user for selection of a client certificate. That is actually an extremely appreciated feature of MSIE (the Browser), a point where most other web browsers are broken in that they stall the server in the middle of a TLS handshake for an indefinite amount of time while performing user interaction. I was refering to a design flaw in server-side session caching of Microsoft IIS (the Server) when it is configured to perform renegotiation in order to obtain a client certificate after having seen and evaluated the request. -Martin From pgut001@wintermute01.cs.auckland.ac.nz Tue Nov 3 01:06:37 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 129F73A6999; Tue, 3 Nov 2009 01:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.564 X-Spam-Level: X-Spam-Status: No, score=-4.564 tagged_above=-999 required=5 tests=[AWL=-1.965, 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 Sw8FJ97M6P8c; Tue, 3 Nov 2009 01:06:36 -0800 (PST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.36]) by core3.amsl.com (Postfix) with ESMTP id 26FBA3A6973; Tue, 3 Nov 2009 01:06:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4E96C9CDBE; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp61vi-qjIn8; Tue, 3 Nov 2009 22:06:40 +1300 (NZDT) Received: from mf1.fos.auckland.ac.nz (mf1.fos.auckland.ac.nz [130.216.33.150]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id EC2909CD93; Tue, 3 Nov 2009 22:06:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz ([130.216.34.38]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N5FLb-0007Pe-J2; Tue, 03 Nov 2009 22:06:39 +1300 Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1N5FLb-0003cr-Qk; Tue, 03 Nov 2009 22:06:39 +1300 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> Message-Id: Sender: pgut001 Date: Tue, 03 Nov 2009 22:06:39 +1300 X-Mailman-Approved-At: Tue, 03 Nov 2009 13:48:41 -0800 Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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: Tue, 03 Nov 2009 09:06:37 -0000 Martin Rex writes: >Microsoft's implementation (which could be the one referred to by >Larry's implementation) has a silly design flaw in its TLS renogiation, >and I'm not sure that the previous text is a way to fix it. > >It is possible to configure Microsoft IIS in a fashion so that it >will first perform a TLS handshake with a server-only authentication, >and after having received the HTTP request, it will re-negotiate and >ask for a client certificate. It's not necessarily a design flaw, AFAIK it's a performance optimisation to avoid the server having to maintain state/leave a connection open for an arbitrary amount of time while the user fumbles around with smart cards and certificates and whatnot. Peter. From Nicolas.Williams@sun.com Tue Nov 3 14:35:06 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 A7F363A6831; Tue, 3 Nov 2009 14:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdgmYQNaDAHg; Tue, 3 Nov 2009 14:35:05 -0800 (PST) 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 CB86C3A67D6; Tue, 3 Nov 2009 14:35:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MZNxi006393; Tue, 3 Nov 2009 22:35:23 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 nA3MZNQN029500; Tue, 3 Nov 2009 15:35:23 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3MNrrf007585; Tue, 3 Nov 2009 16:23:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MNrtr007584; Tue, 3 Nov 2009 16:23:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:23:53 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103222352.GJ1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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: Tue, 03 Nov 2009 22:35:06 -0000 On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > > > 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. > > OooopS. > > The session that results from a re-handshake is an entirely new and > independent session from what it started from, it does NOT modify > the state of the original session (as identified by its TLS session ID). What "oops"? We need to identify one, and only one, client Finished message to use. The name of the thing that that message is related to is only relevant to writing the text for this channel binding type's definition. > Many SSL protocol stacks, however, will perform the re-negotiation > with the same "context" or API handle -- giving the application caller > impression that the original session is modified. TLS does _NOT_ > have capabilities to modify a session, however. It will either > resume a cached session as proposed by the client as-is, or it > will go through a full handshake and create a new session > that is entirely independent from previous sessions. > > The TLS specs do not describe API semantics, however, only the > network protocol and TLS session state, so your terminology is > IMHO confusing. All of that is irrelevant. > > > > 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. > > > b) sounds wrong to me. A renegotiate results in a entirely > new and independent session. That a renegotiate does that is irrelevant. What is relevant is that we want the first Finished message. > It might be easier to _NOT_ key on the finished message, but on the > master secret instead. Too late for that. Nico -- From Nicolas.Williams@sun.com Tue Nov 3 14:36:06 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 215FF3A67D6; Tue, 3 Nov 2009 14:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAVHoPWQ4APM; Tue, 3 Nov 2009 14:36:05 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 0BD6F3A63EB; Tue, 3 Nov 2009 14:36:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA3MaL10021489; Tue, 3 Nov 2009 22:36:22 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 nA3MaLa8030140; Tue, 3 Nov 2009 15:36:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3MOpCu007591; Tue, 3 Nov 2009 16:24:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MOp2A007590; Tue, 3 Nov 2009 16:24:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:24:51 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091103222451.GK1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> <87hbtcc457.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hbtcc457.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] RESOLVED (Re: [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: Tue, 03 Nov 2009 22:36:06 -0000 On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote: > Martin Rex writes: > > > It might be easier to _NOT_ key on the finished message, but on the > > master secret instead. > > That was my conclusion as well, hence > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > which uses the TLS PRF interface. > > For -02 I also added hashing the Finished message, to match the > semantics for connection/session (regardless of its definition) of > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > completely. I don't agree. That it's easier to speak of the master secret is not enough. The Finished message's construction provides better binding of the entire negotiation (up to that Finished message), and that's why we chose it. From Nicolas.Williams@sun.com Tue Nov 3 14:39: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 433933A67D6; Tue, 3 Nov 2009 14:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0ihQCu1fWuo; Tue, 3 Nov 2009 14:39:27 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id DB0C63A63EB; Tue, 3 Nov 2009 14:39:26 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nA3Mdlwn022230; Tue, 3 Nov 2009 22:39:47 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 nA3MdlEV031945; Tue, 3 Nov 2009 15:39:47 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3MKkbG007579; Tue, 3 Nov 2009 16:20:46 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3MKjmI007578; Tue, 3 Nov 2009 16:20:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:20:45 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103222045.GI1105@Sun.COM> References: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911031243.nA3ChGLw017926@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org, Peter Gutmann Subject: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLVED (Re: [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: Tue, 03 Nov 2009 22:39:28 -0000 On Tue, Nov 03, 2009 at 01:43:16PM +0100, Martin Rex wrote: > Peter Gutmann wrote: > > Martin Rex writes: > > >Microsoft's implementation (which could be the one referred to by > > >Larry's implementation) has a silly design flaw in its TLS renogiation, > > >and I'm not sure that the previous text is a way to fix it. > > > > > >It is possible to configure Microsoft IIS in a fashion so that it > > >will first perform a TLS handshake with a server-only authentication, > > >and after having received the HTTP request, it will re-negotiate and > > >ask for a client certificate. > > > > I was refering to a design flaw in server-side session caching of > Microsoft IIS (the Server) when it is configured to perform renegotiation > in order to obtain a client certificate after having seen and evaluated > the request. Why is that a problem? The request will have named a document, but if you're using confidentiality protection then so what? The client knows the document name, and so does the server. Authorization _correctly_ happens when the access request is made. That the necessary user authentication step is delayed until authorization is needed doesn't strike me as a problem -- it's a feature. After all some documents may have anonymous access, and some may require user authentication. If the server requested user authentication prior to knowing what document the client wants to access, then it will force an ugly interaction on users that only want to access documents that require no user authentication. Nico -- From Nicolas.Williams@sun.com Tue Nov 3 14:49:50 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 185F73A67A8; Tue, 3 Nov 2009 14:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R8zGp1AD8iY; Tue, 3 Nov 2009 14:49:49 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 267FF3A63EB; Tue, 3 Nov 2009 14:49:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA3MoANU006199; Tue, 3 Nov 2009 22:50:10 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 nA3Mo9x2037720; Tue, 3 Nov 2009 15:50:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3McdsF007609; Tue, 3 Nov 2009 16:38:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3McdSB007608; Tue, 3 Nov 2009 16:38:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 16:38:39 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103223839.GL1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021648.nA2Gmida005474@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911021648.nA2Gmida005474@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] RESOLVED (Re: [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: Tue, 03 Nov 2009 22:49:50 -0000 On Mon, Nov 02, 2009 at 05:48:44PM +0100, Martin Rex wrote: > And btw. Channel Binding at the application layer and > transparent TLS-session renegotiation at the TLS layer appear > somewhere between hard-to-do and mutually exclusive--in case > that the TLS session renegotiation happens totally transparent > to the application. In order to do channel binding to TLS channels you MUST have some sort of interface to TLS, and that interface MUST let you get at, in this case, the first Finished message (in cleartext) sent by the client. Such an interface necessarily implies that TLS can't be entirely transparent to the application, though some aspects of TLS well might be. Session resumption and re-negotiation complicate how we identify that one message, but they hardly make it impossible. It gets more complicated if a protocol were to multiplex multiple unrelated TLS connections on one TCP/SCTP connection/association. But it's still not impossible: the application, after all, would be keeping track of the various streams and keeping them logically separate. In spite of the _text_ that we need to describe tls-unique being complicated by session resumption and re-negotiation, the actual interfaces and source code will be simple. The complexity is primarily the result of not having a handy word in the TLS terminology for what the Microsoft SSPI interface to TLS calls "security context". If TLS did define such a term, then it'd be easier to specify tls-unique. So far I see no real objections to the actual proposal. Larry objected that the text might make an implementor think that TLS channel bindings are associated with TCP connections. You and Simon would prefer to speak of the Master secret because that doesn't change when you re-negotiate -- but that's hardly enough to change gears now, and then you'd have to bind in things that the Master secret doesn't bind (which would correspondingly complicate your alternative). Let's keep things simple. Please review the proposed text. Nico -- From Martin.Rex@sap.com Tue Nov 3 16:01:42 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 47EA93A6936; Tue, 3 Nov 2009 16:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, 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 MaHHInw4ERKa; Tue, 3 Nov 2009 16:01:41 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 1E0223A686B; Tue, 3 Nov 2009 16:01:40 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA401tk5002236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 01:01:55 +0100 (MET) From: Martin Rex Message-Id: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 4 Nov 2009 01:01:53 +0100 (MET) In-Reply-To: <20091103222045.GI1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:20:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org, pgut001@cs.auckland.ac.nz Subject: Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLVED (Re: [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, 04 Nov 2009 00:01:42 -0000 Nicolas Williams wrote: > > > > I was refering to a design flaw in server-side session caching of > > Microsoft IIS (the Server) when it is configured to perform renegotiation > > in order to obtain a client certificate after having seen and evaluated > > the request. > > Why is that a problem? The request will have named a document, but if > you're using confidentiality protection then so what? The client knows > the document name, and so does the server. Authorization _correctly_ > happens when the access request is made. That the necessary user > authentication step is delayed until authorization is needed doesn't > strike me as a problem -- it's a feature. You are barking up the wrong tree. The flaw in Microsoft IIS is, that it's server-side session cache is somehow broken. Once it has forced the client through a renegotiate, it should memorize what the client sent as response to the CertificateRequest message (either a client cert or the indication that it doesn't have one or doesn't want to send one). The way it is currently implemented in IIS, it will force the client through a renegotiate on every SSL resume. I never checked how other clients deal with a server that asks them to do a renegotiate in order to ask for a client certificate. Since a renegotiate will ALWAYS result in an entirely new TLS session by performing a full TLS handshake, a sensible client should replace the previously cached session with the re-negotiated one in the client-side cache. A server with a correctly working server-side session cache will find the reply to the CertificateRequest from the regenotiation if that session is later resumed on a new connection and does not need to force a renegotiate when a client proposes a TLS session resume over a new network connection (which is what Microsoft IIS currently does). This strange behaviour of Microsoft IIS only applies for the renegotiation configuration. IIRC, when Microsoft IIS is configured to always ask for the client certificate, it will do so in the initial TLS handshake and correctly use the memorized answer of the client on later TLS session resumes. -Martin From Nicolas.Williams@sun.com Tue Nov 3 16:18:14 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 98F843A6A34; Tue, 3 Nov 2009 16:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alMGzZp79hVp; Tue, 3 Nov 2009 16:18:14 -0800 (PST) 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 C7F3C3A6897; Tue, 3 Nov 2009 16:18:13 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA40IVCF029003; Wed, 4 Nov 2009 00:18:31 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 nA40IUBi021644; Tue, 3 Nov 2009 17:18:31 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA3NxVxQ007665; Tue, 3 Nov 2009 17:59:31 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA3NxUr9007664; Tue, 3 Nov 2009 17:59:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 3 Nov 2009 17:59:30 -0600 From: Nicolas Williams To: mrex@sap.com Message-ID: <20091103235930.GP1105@Sun.COM> References: <20091103222045.GI1105@Sun.COM> <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911040001.nA401rVh002365@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org, pgut001@cs.auckland.ac.nz Subject: Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLVED (Re: [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, 04 Nov 2009 00:18:14 -0000 On Wed, Nov 04, 2009 at 01:01:53AM +0100, Martin Rex wrote: > Nicolas Williams wrote: > > Why is that a problem? The request will have named a document, but if > > you're using confidentiality protection then so what? The client knows > > the document name, and so does the server. Authorization _correctly_ > > happens when the access request is made. That the necessary user > > authentication step is delayed until authorization is needed doesn't > > strike me as a problem -- it's a feature. > > You are barking up the wrong tree. > > The flaw in Microsoft IIS is, that it's server-side session cache is > somehow broken. Once it has forced the client through a renegotiate, > it should memorize what the client sent as response to the > CertificateRequest message (either a client cert or the indication > that it doesn't have one or doesn't want to send one). Ah, sure, that sounds like a bug. Nico -- From Martin.Rex@sap.com Tue Nov 3 16:32:09 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 7681828C0FB; Tue, 3 Nov 2009 16:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.048, 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 YEW5NsrzOqbn; Tue, 3 Nov 2009 16:32:08 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 447BC3A690A; Tue, 3 Nov 2009 16:32:08 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA40WRch023726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 01:32:27 +0100 (MET) From: Martin Rex Message-Id: <200911040032.nA40WQNB004167@fs4113.wdf.sap.corp> To: Nicolas.Williams@sun.com (Nicolas Williams) Date: Wed, 4 Nov 2009 01:32:26 +0100 (MET) In-Reply-To: <20091103222352.GJ1105@Sun.COM> from "Nicolas Williams" at Nov 3, 9 04:23:53 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: mrex@sap.com, channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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, 04 Nov 2009 00:32:09 -0000 Nicolas Williams wrote: > > On Mon, Nov 02, 2009 at 03:59:44PM +0100, Martin Rex wrote: > > Nicolas Williams wrote: > > > > > > 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. > > > > OooopS. > > > > The session that results from a re-handshake is an entirely new and > > independent session from what it started from, it does NOT modify > > the state of the original session (as identified by its TLS session ID). > > What "oops"? We need to identify one, and only one, client Finished > message to use. The name of the thing that that message is related to > is only relevant to writing the text for this channel binding type's > definition. The OooopS refers to the fact, that a TLS session that is renegotiated results in an entirely different TLS session with an independent MasterSecret, and I am violently opposed to having to memorize in the new re-negotiated TLS session anything from a completely unrelated TLS session. A full TLS-handshake and a later TLS session are still the same underlying TLS session, sharing the master secret. (they do have connection-specific and direction specific crypto keys, of course). When a Web Browser loads a new page containing several elements (style sheets, buttons, icons, frames, etc.), then it first needs to retrieve the top level document over a single network connection. Doing so, a new TLS session can be created and added to the session cache. The session can be added to the cache as soon as the TLS handshake is successfully completed, even before any application data has been transferred. Having received the top-level document, the browser determines that it will have to load another dozen or so elements in order to render the page, and will then usually open several network connections in parallel (and probably reuse the one it just used if it is HTTP 1.1 keep-alive). If session caching on both sides is working correctly, then the client can resume the original TLS session on all additional parallel network connections directly. If there is one top-level-page, 12 elements and up to 4 parallel network connections per server, then this will result in a single full TLS handshake and 3 TLS session resumes and one session in the session caches of client and server. 1st page: 1 full, 3 resumes, 1 session in the server session cache 2nd page: 4 resumes, 1 session in the server session cache If your server is a Microsoft IIS with special configuration, then it goes like this: 1 full TLS-handshake plus 1 renegotiate (=1 full TLS-handshake) plus 3 TLS-resumes, each followed by a renegotiate (=3 full TLS-handshakes) 1st page: 5 full, 3 resumes, 5 sessions in the server session cache 2nd page: 4 full, 4 resumes, 9 session in the server session cache A full TLS handshake is typically at least 10x more expensive than a TLS session resume (that is the crypto of the TLS handshake alone, not counting any fancy certificate path validation or revocation checking). > > > > > The TLS specs do not describe API semantics, however, only the > > network protocol and TLS session state, so your terminology is > > IMHO confusing. > > All of that is irrelevant. No, it isn't. With channel bindings, you are actually looking/asking for a particular API semantic. IMHO, a renegotiation is a problem for both TLS PRF ("extractors") and channel bindings, because on the wire and at the TLS protocol level (concerning the TLS session state), renegotiation restarts everything from scratch. It does so under protection of a previously negotiated TLS session, but still, the original and the re-negotiated session are completely distinct and will void all assumptions that the application may have associated with the originally established TLS session. -Martin From Pasi.Eronen@nokia.com Wed Nov 4 06:13:37 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 7BE333A6359; Wed, 4 Nov 2009 06:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.267 X-Spam-Level: X-Spam-Status: No, score=-6.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 nut4fQVoqxSK; Wed, 4 Nov 2009 06:13:36 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 432C43A68EA; Wed, 4 Nov 2009 06:13:35 -0800 (PST) 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 nA4EDOO7001542; Wed, 4 Nov 2009 16:13:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:13:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:13:44 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:13:43 +0100 From: To: , Date: Wed, 4 Nov 2009 15:13:42 +0100 Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: Thread-Index: Acpb2oJKfqzhjVd9R8G4op2bkJ4pBABfRgKw Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C55FE@NOK-EUMSG-01.mgdnok.nokia.com> References: <87hbtcc457.fsf@mocca.josefsson.org> from "Simon Josefsson" at Nov 2, 9 04:55:48 pm <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> In-Reply-To: <200911021635.nA2GZAEp004639@fs4113.wdf.sap.corp> 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: 04 Nov 2009 14:13:44.0184 (UTC) FILETIME=[0476AF80:01CA5D59] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, Nicolas.Williams@sun.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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, 04 Nov 2009 14:13:37 -0000 Martin Rex wrote: > > That was my conclusion as well, hence > > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00 > > which uses the TLS PRF interface. > > > > For -02 I also added hashing the Finished message, to match the > > semantics for connection/session (regardless of its definition) of > > draft-altman-tls-channel-bindings, but I'd prefer to avoid it > > completely. >=20 > If you refer to the TLS-extractor interface with TLS PRF, that does > unconditionally include the client.random and server.random in the > computation and therefore the output will differ for different > incarnations (resumes) of the same TLS session. That is comparable > to keying to the _most_recent_ finished message -- with __NO__ > special cased for TLS session resume and TLS renogiation. Note that just extracting some bytes from the TLS master secret (with TLS extractor) is not sufficient to produce a channel binding, because with RSA cipher suites, a man-in-the-middle could cause two TLS sessions to have the same TLS master secret (this is explained in draft-ietf-tls-extractor-07, Section 5). But those two sessions would have different Finished messages. (Version -00 of draft-josefsson-sasl-tls-cb had this problem. Newer versions avoid it by including the handshake messages (either hashed,=20 or via the Finished message) in the calculation.) Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 4 06:28:45 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 07D733A6900; Wed, 4 Nov 2009 06:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 bdDCWswXTEPT; Wed, 4 Nov 2009 06:28:39 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 348CD3A6852; Wed, 4 Nov 2009 06:28:38 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4ESTsQ013760; Wed, 4 Nov 2009 16:28:57 +0200 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:28:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:28:47 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:28:36 +0100 From: To: , Date: Wed, 4 Nov 2009 15:28:35 +0100 Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) Thread-Index: AcpZsxqWw6nYMK2FSZK/khOlvzWrPgDphhgw Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> In-Reply-To: <20091030223647.GO1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2009 14:28:47.0959 (UTC) FILETIME=[1F27CE70:01CA5D5B] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 14:28:45 -0000 Nicolas Williams wrote: > My proposal, then, is this: >=20 > OLD: >=20 > 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). >=20 > NEW: >=20 > Description: The client's TLS Finished message (note: the > Finished struct) from the first handshake of the application's > TLS connection. >=20 > NOTES: >=20 > a) If a session is resumed, the client's TLS Finished message from > the session resumption handshake is to be used; >=20 > 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; >=20 > 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). >=20 > I'm not sure that we can make it any clearer. In any case, I guess we agree that we're referring to the latest TLS handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)? Could we somehow refer to this? Perhaps: Note: We define a new "TLS connection" to start when the client sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client Hello message (which can lead to either a full handshake, or resuming a session). Renegotiation (sending a Client Hello protected under some other cipher suite) does not start a new "TLS connection". =20 Note that this is separate from any notion of "connection", if any,=20 in the underlying transport protocol (such as TCP or UDP). (Is this consistent with what the existing implementations do?) Best regards, Pasi From Pasi.Eronen@nokia.com Wed Nov 4 06:34:32 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 82F3E3A68EC; Wed, 4 Nov 2009 06:34:32 -0800 (PST) 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 wztOdza9JLv5; Wed, 4 Nov 2009 06:34:31 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4EAC83A6852; Wed, 4 Nov 2009 06:34:31 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id nA4EYQC8018760; Wed, 4 Nov 2009 16:34:50 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:34:40 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 4 Nov 2009 15:34:39 +0100 From: To: , Date: Wed, 4 Nov 2009 15:34:38 +0100 Thread-Topic: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard) Thread-Index: AcpX2mGW8VJUR3NfTRSHi2k9SZOeKAFgQdXQ Message-ID: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> In-Reply-To: <87hbtjppfa.fsf@mocca.josefsson.org> 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: 04 Nov 2009 14:34:40.0368 (UTC) FILETIME=[F1352700:01CA5D5B] X-Nokia-AV: Clean Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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, 04 Nov 2009 14:34:32 -0000 Simon Josefsson wrote: > This reminded me of an earlier observation, and it might be relevant > to re-iterate it here. Consider this: >=20 > Day 1: >=20 > 1. Client establish TLS anon-anon to server. > 2. User authenticates using SCRAM with channel binding to the TLS > channel > 3. User/client disconnects >=20 > Day 2: >=20 > 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 >=20 > Day 3: >=20 > 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 >=20 > With draft-altman-tls-channel-bindings-07, the channel binding data > used in all three SCRAM authentications is the same bit sequence. That certainly was not the intent (the Finished messages used by SCRAM would be from steps 1, 4, and 7 -- and they're all different). Can you check if the latest text proposals (Nico's email on=20 October 30th, starting "I spoke at length with Larry", and=20 my email earlier today) make the situation clearer? Best regards, Pasi From simon@josefsson.org Wed Nov 4 07:18:29 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 CC5E73A6890; Wed, 4 Nov 2009 07:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.148, 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 GHzR2TYlMRXQ; Wed, 4 Nov 2009 07:18:29 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 75F7E3A67FD; Wed, 4 Nov 2009 07:18:28 -0800 (PST) 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 nA4FIiuU017073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 16:18:47 +0100 From: Simon Josefsson To: References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091104:sasl@ietf.org::ftW2jU1+B6N6F/C6:1fK+ X-Hashcash: 1:22:091104:larry.zhu@microsoft.com::F7MW4Uwq1Kik7mX5:5qwM X-Hashcash: 1:22:091104:tls@ietf.org::t2M4k3UAgVXRhgn0:Le3I X-Hashcash: 1:22:091104:pasi.eronen@nokia.com::v5vtcQ3FOwHOIInM:B9Go X-Hashcash: 1:22:091104:channel-binding@ietf.org::/2CohyCJGw2UXiv0:ccXw Date: Wed, 04 Nov 2009 16:18:44 +0100 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> (Pasi Eronen's message of "Wed, 4 Nov 2009 15:34:38 +0100") Message-ID: <87bpjico8b.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, larry.zhu@microsoft.com, sasl@ietf.org, tls@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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, 04 Nov 2009 15:18:29 -0000 writes: > Can you check if the latest text proposals (Nico's email on > October 30th, starting "I spoke at length with Larry", and > my email earlier today) make the situation clearer? I have the same question as Martin Rex: what is the actual semantic that is wanted? I thought I understood what was intended, but given this discussion my understanding of what was intended may have been wrong. /Simon From Nicolas.Williams@sun.com Wed Nov 4 09:57:35 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 D64C03A67B1; Wed, 4 Nov 2009 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fx8eWbggz7d; Wed, 4 Nov 2009 09:57:35 -0800 (PST) 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 C354F3A67E5; Wed, 4 Nov 2009 09:57:34 -0800 (PST) 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 nA4Hveva000731; Wed, 4 Nov 2009 17:57:52 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 nA4HvdMV042877; Wed, 4 Nov 2009 10:57:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4HkAkk008243; Wed, 4 Nov 2009 11:46:10 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4Hk9oF008242; Wed, 4 Nov 2009 11:46:09 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 11:46:09 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091104174609.GW1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> 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] 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: Wed, 04 Nov 2009 17:57:35 -0000 On Wed, Nov 04, 2009 at 03:28:35PM +0100, Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: > > I'm not sure that we can make it any clearer. > > In any case, I guess we agree that we're referring to the latest TLS > handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)? Yes (and before any ChangeCipherSpec messages). > Could we somehow refer to this? Perhaps: > > Note: We define a new "TLS connection" to start when the client > sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client > Hello message (which can lead to either a full handshake, or > resuming a session). Renegotiation (sending a Client Hello protected > under some other cipher suite) does not start a new "TLS connection". > Note that this is separate from any notion of "connection", if any, > in the underlying transport protocol (such as TCP or UDP). I like that. > (Is this consistent with what the existing implementations do?) It's consistent with the description that had been registered. I don't have an implementation, so I can't say as to existing implementations. Jeff and/or Larry should know. Nico -- From Nicolas.Williams@sun.com Wed Nov 4 10:06:51 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 02E3F3A691D; Wed, 4 Nov 2009 10:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQIP4XF4ft5L; Wed, 4 Nov 2009 10:06:50 -0800 (PST) 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 E2BDD3A6922; Wed, 4 Nov 2009 10:06:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4I77us018389; Wed, 4 Nov 2009 18:07:07 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 nA4I77uk050114; Wed, 4 Nov 2009 11:07:07 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4HtcTm008250; Wed, 4 Nov 2009 11:55:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4HtbZ0008249; Wed, 4 Nov 2009 11:55:37 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 11:55:37 -0600 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20091104175537.GX1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> 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] [sasl] [TLS] 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, 04 Nov 2009 18:06:51 -0000 On Wed, Nov 04, 2009 at 03:34:38PM +0100, Pasi.Eronen@nokia.com wrote: > Simon Josefsson wrote: > > 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 certainly was not the intent (the Finished messages used by > SCRAM would be from steps 1, 4, and 7 -- and they're all different). Indeed, that's absolutely not the intent. The intent is that you use the first client Finished message sent on each of those "connections". Note, incidentally, that Simon's view of how tls-unique was intended to work, would not be flawed, cryptographically. It wouldn't interoperate with other implementations, and it'd be hard to implement (since it means updating saved session state). It would conflict the very name of the channel binding type and it's description as being a "unique" channel binding type in the RFC5056 sense -- that should be the biggest clue that Simon's interpretation is incorrect. I have a very, very hard time understanding how this might not by now be clear. It doesn't help that TLS doesn't have a name for the entity from which we're extracting the channel binding, but that's the only real problem here. I also have a very, very hard time understanding how the previous text could have led anyone to think that TCP connection state should track TLS channel binding data. RFC5246 may not have a name for the entity... but it does speak of "TLS connections", which you can see from the naming of section 6.1: "Connection States". Nonetheless I'm happy to revise text to make this matter clearer. I'd be happy even to introduce text naming that entity which RFC5246 does not name. Nico -- From jhutz@cmu.edu Wed Nov 4 10:14:23 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 396B53A68EA; Wed, 4 Nov 2009 10:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.133, 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 2iV0udUmxLQ3; Wed, 4 Nov 2009 10:14:22 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 778283A6801; Wed, 4 Nov 2009 10:14:22 -0800 (PST) Received: from [10.0.0.3] (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id nA4IEfnY025637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Nov 2009 13:14:41 -0500 (EST) Date: Wed, 04 Nov 2009 13:14:41 -0500 From: Jeffrey Hutzelman To: Nicolas Williams , mrex@sap.com Message-ID: <754BFABD8F4175F04918E805@atlantis.pc.cs.cmu.edu> In-Reply-To: <11983_1257287730_nA3MZT4b001736_20091103222352.GJ1105@Sun.COM> References: <20091030223647.GO1105@Sun.COM> <200911021459.nA2Exi67028763@fs4113.wdf.sap.corp> <11983_1257287730_nA3MZT4b001736_20091103222352.GJ1105@Sun.COM> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [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, 04 Nov 2009 18:14:23 -0000 --On Tuesday, November 03, 2009 04:23:53 PM -0600 Nicolas Williams wrote: >> It might be easier to _NOT_ key on the finished message, but on the >> master secret instead. > > Too late for that. Not just too late, but also a bad idea. Previous discussions relating to FAST and anonymous PKINIT resulted in some investigation which, in turn, led to the somewhat surprising result that the TLS master secret does _not_ name a unique channel, while the finished messages _do_. -- Jeff From Nicolas.Williams@sun.com Wed Nov 4 10:24:07 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 369A928C0DB; Wed, 4 Nov 2009 10:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFzyz6RbV5ib; Wed, 4 Nov 2009 10:24:06 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 48FBF28C115; Wed, 4 Nov 2009 10:24:05 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4IOR1C003545; Wed, 4 Nov 2009 18:24:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA4IOQ3P064769; Wed, 4 Nov 2009 11:24:27 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4ICwiG008262; Wed, 4 Nov 2009 12:12:58 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4ICwiu008261; Wed, 4 Nov 2009 12:12:58 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 12:12:58 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091104181257.GY1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bpjico8b.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, Pasi.Eronen@nokia.com, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [sasl] [TLS] 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, 04 Nov 2009 18:24:07 -0000 On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: > writes: > > > Can you check if the latest text proposals (Nico's email on > > October 30th, starting "I spoke at length with Larry", and > > my email earlier today) make the situation clearer? > > I have the same question as Martin Rex: what is the actual semantic that > is wanted? I thought I understood what was intended, but given this > discussion my understanding of what was intended may have been wrong. The desired semantic is that tls-unique channel bindings are a channel binding in the RFC5056 sense, for a "TLS channel", with this particular feature (from the I-D): o Channel binding type: unique (which RFC5056 defines). Was this not utterly clear already? How could it not have been? The only possible point of contention from the above description is just what a "TLS channel" might be. And the only reasons for that are: - RFC5246 and predecessors don't define a name for what we've been calling a "TLS connection"; - Session resumption might cause someone to be confused and think that tls-unique refers to the client's Finished message from the resumed session; - Re-negotiation might cause someone to be confused and think that tls-unique refers to the client's Finished message from the re-negotiated "TLS connection". Let's dispose of these for once and for all: - We shall use "TLS connection" to refer to the TLS state created by an exchange beginning with a Client Hello message, followed by a TLS handshake sequence (which involves a ServerHello, a variety of optional messages such as Certificate, and ends in an optional ChangeCipherSpec message exchange) followed by an exchange of Finished messages. - Session resumption establishes new state as per the previous definition of "TLS connection", therefore it establishes a new "TLS connection", even though session resumption does NOT establish a new session. Therefore, the tls-unique channel binding for a "TLS connection" that resumes a session, MUST be the client's Finished message from the new connection, not the old session. - Re-negotiation consists of initiating a new "TLS connection" while using another "TLS connection" record layer for integrity (and usually also confidentiality) protection of the re-negotiation. As such re-negotiation creates a new "TLS connection". In this case want the tls-unique channel binding to be used by the application to be that of the first "TLS connection", that is, the one whose ClientHello and handshake were not protected by any other "TLS connection". (It follows that even if the client does N re-negotiations, where N > 2, we still want the application to use the tls-unique channel binding of the first "TLS connection", the one whose handshake was not protected by any other "TLS connection".) Therefore a "TLS channel" is really: a "TLS connection", as defined above, whose handshake was not protected by any other "TLS connection". This is a significantly more rigorous description than the ones we've discussed so far. Do you agree that it's air-tight? Should I propose new text that adds the above definitions of "TLS connection" and "TLS channel"? I think I should, so I will, shortly. Nico -- From mike-list@pobox.com Wed Nov 4 10:23:43 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 6043928C106; Wed, 4 Nov 2009 10:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 To94f-FM7qfE; Wed, 4 Nov 2009 10:23:42 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 7468928C0FF; Wed, 4 Nov 2009 10:23:41 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 60EB9734F0; Wed, 4 Nov 2009 13:24:02 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=QZXsTlABM3zx u1/bNkv3znArCIo=; b=fX9GUPbAqn4NLJDeryIWGzDCKqLefxxDBdptipEJUknO NVyVwJ7fiCXwpMYXoxeZFytuKgKDaUnqeyrQW4hmVJ3Ag5YobQNkguVg0k6aFKCC lLExs5CXlo8jXfIpDz5GPLQxPyrTaSvnph5GgYkKhFlo6Q4hJWRHYABVfeiXPBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=C7SvV7 gZ1lgp86gAGaXGtAWwABbIxwleeRNlae+zbO6iugXz7Z7xHkUFFQ1WoGgns9zLZJ 19IEzjicjuDovbgeFxYK65o5PAH5QrpJhQnGrtp/Q/JGQ3j7NfFRlRAiK6IKa/Nl mO47vP13w+nH9zPXw2HTmGwCyHXj34O3JC4rQ= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 43069734EF; Wed, 4 Nov 2009 13:24:00 -0500 (EST) Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 7EA3F734EE; Wed, 4 Nov 2009 13:23:56 -0500 (EST) Message-ID: <4AF1C6DD.7030502@pobox.com> Date: Wed, 04 Nov 2009 10:24:29 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: channel-binding@ietf.org, tls@ietf.org References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 38FE9ABA-C96F-11DE-B1CA-1B12EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com X-Mailman-Approved-At: Wed, 04 Nov 2009 10:31:30 -0800 Cc: sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 18:23:43 -0000 I don't pretend to know exactly what this feature is supposed to do, but I think using the word "connection" would be a mistake given its widespread use meaning TCP connections, etc. Perhaps using a different word such as "link" would portray the meaning you want without causing confusion? Mike > Could we somehow refer to this? Perhaps: > > Note: We define a new "TLS connection" to start when the client > sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client > Hello message (which can lead to either a full handshake, or > resuming a session). Renegotiation (sending a Client Hello protected > under some other cipher suite) does not start a new "TLS connection". > Note that this is separate from any notion of "connection", if any, > in the underlying transport protocol (such as TCP or UDP). > > (Is this consistent with what the existing implementations do?) > > Best regards, > Pasi From Nicolas.Williams@sun.com Wed Nov 4 10:38: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 ABBFF3A68CB; Wed, 4 Nov 2009 10:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7V1T7EvW6gp; Wed, 4 Nov 2009 10:38:18 -0800 (PST) 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 355453A67AF; Wed, 4 Nov 2009 10:38:12 -0800 (PST) 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 nA4IcXEo015656; Wed, 4 Nov 2009 18:38:34 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 nA4IcXeM009722; Wed, 4 Nov 2009 11:38:33 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4IR4jc008279; Wed, 4 Nov 2009 12:27:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4IR4if008278; Wed, 4 Nov 2009 12:27:04 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 12:27:04 -0600 From: Nicolas Williams To: "Michael D'Errico" Message-ID: <20091104182704.GA1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AF1C6DD.7030502@pobox.com> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 18:38:18 -0000 On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: > I don't pretend to know exactly what this feature is supposed to do, > but I think using the word "connection" would be a mistake given its > widespread use meaning TCP connections, etc. At least the word 'connection' is used in RFC5246 _some_ times to mean what we were using it to mean here. > Perhaps using a different word such as "link" would portray the > meaning you want without causing confusion? 'Link' is even worse. We'll probably have to include our own definition in the I-D. The fact that certain words are overloaded does not mean that they cannot be used. This is a fact of life in Internet standards, that terminology varies significantly, and often overlaps, between areas, and even within areas. One way to avoid confusion is to indicate, in each context, the source of one's terminology, and to clarify whenever one must refer to multiple documents with conflicting terminologies. Another way is to invent new terminology whenever conflicts arise. The latter is very difficult to do and to popularize. The former requires discipline. I prefer the former. From hartmans@mit.edu Wed Nov 4 11:00:06 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 804CE3A6914; Wed, 4 Nov 2009 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 H95GKtKOJyTe; Wed, 4 Nov 2009 11:00:05 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ACBD53A6911; Wed, 4 Nov 2009 11:00:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 57C3920205; Wed, 4 Nov 2009 14:00:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2E52643BE; Wed, 4 Nov 2009 14:00:20 -0500 (EST) To: Nicolas Williams References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> <20091104182704.GA1105@Sun.COM> From: Sam Hartman Date: Wed, 04 Nov 2009 14:00:20 -0500 In-Reply-To: <20091104182704.GA1105@Sun.COM> (Nicolas Williams's message of "Wed\, 4 Nov 2009 12\:27\:04 -0600") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Michael D'Errico , channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 19:00:06 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: >> I don't pretend to know exactly what this feature is supposed >> to do, but I think using the word "connection" would be a >> mistake given its widespread use meaning TCP connections, etc. Nicolas> At least the word 'connection' is used in RFC5246 _some_ Nicolas> times to mean what we were using it to mean here. Sanity check here: For the most part, there is a one-to-one mapping between what we're talking about and TCP connections, right? In particular, for most applications, even applications with multiple finish messages, grabbing the first finish message from a TCP connection gives exactly the one we want. Am I correctly understanding our goal? If so, this sounds fairly pedantic. Pedantic is not bad--we should get it to be correct. However for most app developers, it seems that if they assume connection means tcp connection, the right thing will happen. If that's not true, then we have a lot of explaining to do, because if I'm confused, then this is a hard problem to explain. From Nicolas.Williams@sun.com Wed Nov 4 11:16:37 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 ADAEE3A67D1; Wed, 4 Nov 2009 11:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Da+PqbqLExUY; Wed, 4 Nov 2009 11:16:37 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id CF8C73A68C1; Wed, 4 Nov 2009 11:16:36 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4JGwpH005532; Wed, 4 Nov 2009 19:16:58 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 nA4JGwMA037327; Wed, 4 Nov 2009 12:16:58 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4J5R1p008329; Wed, 4 Nov 2009 13:05:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4J5RLb008328; Wed, 4 Nov 2009 13:05:27 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 13:05:27 -0600 From: Nicolas Williams To: Sam Hartman Message-ID: <20091104190526.GB1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <808FD6E27AD4884E94820BC333B2DB774E7F7C562A@NOK-EUMSG-01.mgdnok.nokia.com> <4AF1C6DD.7030502@pobox.com> <20091104182704.GA1105@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: Michael D'Errico , channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 19:16:37 -0000 On Wed, Nov 04, 2009 at 02:00:20PM -0500, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote: > >> I don't pretend to know exactly what this feature is supposed > >> to do, but I think using the word "connection" would be a > >> mistake given its widespread use meaning TCP connections, etc. > > Nicolas> At least the word 'connection' is used in RFC5246 _some_ > Nicolas> times to mean what we were using it to mean here. > > Sanity check here: For the most part, there is a one-to-one mapping > between what we're talking about and TCP connections, right? In For the most part, yes. > particular, for most applications, even applications with multiple > finish messages, grabbing the first finish message from a TCP > connection gives exactly the one we want. Am I correctly > understanding our goal? Yes. > If so, this sounds fairly pedantic. Pedantic is not bad--we should > get it to be correct. However for most app developers, it seems that > if they assume connection means tcp connection, the right thing will > happen. If that's not true, then we have a lot of explaining to do, > because if I'm confused, then this is a hard problem to explain. You're not confused. I fully agree that we've gotten pedantic here. I don't really understand how anyone could have thought that the channel binding needed to be communicated to TCP, and thence to the application, but that's how we got to this point. Now that we're here, I think we might as well consider whether we want to have extra rigorous text, or whether we approve the document as is. Nico -- From simon@josefsson.org Wed Nov 4 11:26:14 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 254DD3A68E7; Wed, 4 Nov 2009 11:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.695 X-Spam-Level: X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, 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 cUoplztkeEdB; Wed, 4 Nov 2009 11:26:13 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D05A73A67B6; Wed, 4 Nov 2009 11:26:12 -0800 (PST) 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 nA4JQUKj022658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 20:26:32 +0100 From: Simon Josefsson To: Nicolas Williams References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> <20091104181257.GY1105@Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:091104:tls@ietf.org::E+MsoNkDbZ0j/YBl:0Uvi X-Hashcash: 1:22:091104:nicolas.williams@sun.com::n3HUsOfNYddl4ZyB:1bDE X-Hashcash: 1:22:091104:channel-binding@ietf.org::RXChJT0iKFtgtKX5:2Ceb X-Hashcash: 1:22:091104:sasl@ietf.org::4t7yvQqTduGLQQSN:LgVb Date: Wed, 04 Nov 2009 20:26:30 +0100 In-Reply-To: <20091104181257.GY1105@Sun.COM> (Nicolas Williams's message of "Wed, 4 Nov 2009 12:12:58 -0600") Message-ID: <87aaz2jdll.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] [TLS] 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, 04 Nov 2009 19:26:14 -0000 Nicolas Williams writes: > On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: >> writes: >> >> > Can you check if the latest text proposals (Nico's email on >> > October 30th, starting "I spoke at length with Larry", and >> > my email earlier today) make the situation clearer? >> >> I have the same question as Martin Rex: what is the actual semantic that >> is wanted? I thought I understood what was intended, but given this >> discussion my understanding of what was intended may have been wrong. > > The desired semantic is that tls-unique channel bindings are a channel > binding in the RFC5056 sense, for a "TLS channel", with this particular > feature (from the I-D): > > o Channel binding type: unique > > (which RFC5056 defines). > > Was this not utterly clear already? How could it not have been? > > The only possible point of contention from the above description is just > what a "TLS channel" might be. And the only reasons for that are: > > - RFC5246 and predecessors don't define a name for what we've been > calling a "TLS connection"; > > - Session resumption might cause someone to be confused and think that > tls-unique refers to the client's Finished message from the resumed > session; > > - Re-negotiation might cause someone to be confused and think that > tls-unique refers to the client's Finished message from the > re-negotiated "TLS connection". > > Let's dispose of these for once and for all: > > - We shall use "TLS connection" to refer to the TLS state created by an > exchange beginning with a Client Hello message, followed by a TLS > handshake sequence (which involves a ServerHello, a variety of > optional messages such as Certificate, and ends in an optional > ChangeCipherSpec message exchange) followed by an exchange of > Finished messages. > > - Session resumption establishes new state as per the previous > definition of "TLS connection", therefore it establishes a new "TLS > connection", even though session resumption does NOT establish a new > session. Therefore, the tls-unique channel binding for a "TLS > connection" that resumes a session, MUST be the client's Finished > message from the new connection, not the old session. > > - Re-negotiation consists of initiating a new "TLS connection" while > using another "TLS connection" record layer for integrity (and > usually also confidentiality) protection of the re-negotiation. > > As such re-negotiation creates a new "TLS connection". In this case > want the tls-unique channel binding to be used by the application to > be that of the first "TLS connection", that is, the one whose > ClientHello and handshake were not protected by any other "TLS > connection". > > (It follows that even if the client does N re-negotiations, where N > > 2, we still want the application to use the tls-unique channel > binding of the first "TLS connection", the one whose handshake was > not protected by any other "TLS connection".) > > Therefore a "TLS channel" is really: a "TLS connection", as defined > above, whose handshake was not protected by any other "TLS connection". > > This is a significantly more rigorous description than the ones we've > discussed so far. Do you agree that it's air-tight? Should I propose > new text that adds the above definitions of "TLS connection" and "TLS > channel"? I think I should, so I will, shortly. With that definition, one couldn't use tls-unique channel binding to bind to the authentication credentials associated with a TLS channel uniquely -- a TLS re-negotiation doesn't change the channel binding data, but it may change the authentication credentials. I believe that problem needs to be explained in the security consideration -- it would be easy to think that channel binding data can be used to get a cryptographic association with the user credentials used for that channel. Otherwise I don't see any problem with this definition. /Simon From Nicolas.Williams@sun.com Wed Nov 4 12:03:20 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 778963A6A0A; Wed, 4 Nov 2009 12:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnDhrML3e5Sn; Wed, 4 Nov 2009 12:03:19 -0800 (PST) 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 79B8B3A6A09; Wed, 4 Nov 2009 12:03:19 -0800 (PST) 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 nA4K3dpJ009470; Wed, 4 Nov 2009 20:03:39 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 nA4K3cZQ003091; Wed, 4 Nov 2009 13:03:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4Jq9Mv008352; Wed, 4 Nov 2009 13:52:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4Jq8hG008351; Wed, 4 Nov 2009 13:52:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 13:52:08 -0600 From: Nicolas Williams To: Simon Josefsson Message-ID: <20091104195208.GD1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <87ocnrpq0f.fsf@mocca.josefsson.org> <87hbtjppfa.fsf@mocca.josefsson.org> <808FD6E27AD4884E94820BC333B2DB774E7F7C5641@NOK-EUMSG-01.mgdnok.nokia.com> <87bpjico8b.fsf@mocca.josefsson.org> <20091104181257.GY1105@Sun.COM> <87aaz2jdll.fsf@mocca.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87aaz2jdll.fsf@mocca.josefsson.org> User-Agent: Mutt/1.5.7i Cc: channel-binding@ietf.org, tls@ietf.org, sasl@ietf.org Subject: Re: [CHANNEL-BINDING] [TLS] 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, 04 Nov 2009 20:03:20 -0000 On Wed, Nov 04, 2009 at 08:26:30PM +0100, Simon Josefsson wrote: > Nicolas Williams writes: > > [...] > > With that definition, one couldn't use tls-unique channel binding to > bind to the authentication credentials associated with a TLS channel ^^^^^^^^^^^^^^^^^^^^^^^^^^ > uniquely -- a TLS re-negotiation doesn't change the channel binding > data, but it may change the authentication credentials. The point of channel binding is NOT to bind the authentication credentials of the channel's end-points. In fact, the point of channel binding is to allow authentication to happen at a layer above the channel, so that the authentication, or lack thereof in that channel, becomes irrelevant. Please see RFC5056. > I believe that problem needs to be explained in the security > consideration -- it would be easy to think that channel binding data can > be used to get a cryptographic association with the user credentials > used for that channel. There is no problem. > Otherwise I don't see any problem with this definition. Thanks. Nico -- From larry.zhu@microsoft.com Wed Nov 4 14:13:27 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 27DF83A68B3; Wed, 4 Nov 2009 14:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f19SG883+Ot1; Wed, 4 Nov 2009 14:13:26 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 45BB83A688D; Wed, 4 Nov 2009 14:13:26 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 14:14:03 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 14:13:47 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 14:13:48 -0800 From: Larry Zhu To: Nicolas Williams Thread-Topic: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) Thread-Index: AQHKWbNKKo89XNrhrEC3HCaJjhtWGJEmhAyA Date: Wed, 4 Nov 2009 22:13:46 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> In-Reply-To: <20091030223647.GO1105@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "channel-binding@ietf.org" , "tls@ietf.org" , "sasl@ietf.org" Subject: Re: [CHANNEL-BINDING] [TLS] 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: Wed, 04 Nov 2009 22:13:27 -0000 The proposed looks fine. Thanks, --Larry -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as Williams Sent: Friday, October 30, 2009 3:37 PM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-alt= man-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)) I spoke at length with Larry. His concern is that the word "conenction" might be taken to mean "TCP connection" or "connection for the transport below TLS". Clearly it is not reasonable to expect to extract the TLS channel binding from the "connection for the transport below TLS"! Larry's proposal to say "session" was only to make that confusion go away, but that proposal is very difficult to implement (as I described separately already). Larry has indicated to me (and I expect will indicate on the list in reply to this email) that he will be happy if we simply clarify that "TLS connection" refers to the TLS state, NOT to the transport below. Unfortunately RFC5246 does not seem to have a term by which to refer the "TLS connection" unambiguously: "connection" is defined in the glossary (page 80) to mean that which Larry doesn't want (underlying transport), but then, in section 6.1 RFC5246 quite clearly uses the word "connection" to refer to "TLS connection", not to the underlying transport. Thus this is a simple matter of wordsmithing. Another problem that Larry has is that in his implementation what I call a "TLS connection" is called a "security context", and if the application re-handshakes (e.g., to authenticate a user) then the result is a second security context -- we need to be extra clear that it's the client Finished message from the _first_ "security context" that we're after. My proposal, then, is this: OLD: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). NEW: Description: The client's TLS Finished message (note: the Finished struct) from the first handshake of the application's TLS connection. NOTES: a) If a session is resumed, the client's TLS Finished message from the session resumption handshake is to be used; b) If a client does multiple TLS handshakes in sequence, each protected by the previous one, then the client's TLS Finished message from the first/outermost TLS connection is to be used; c) By "TLS connection" we refer to the TLS connection state, not to any notion of connection of any underlying transport protocols (such as TCP, UDP, SCTP, etcetera). I'm not sure that we can make it any clearer. Larry, please review. Martin, please review. Nico --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Nov 4 14:58:51 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 5518C3A6A17; Wed, 4 Nov 2009 14:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXY3SaVogaXR; Wed, 4 Nov 2009 14:58:50 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 33B2E3A6A2A; Wed, 4 Nov 2009 14:58:49 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4MxBAT018545; Wed, 4 Nov 2009 22:59:11 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 nA4MxBlQ056693; Wed, 4 Nov 2009 15:59:11 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4MlgLm008697; Wed, 4 Nov 2009 16:47:42 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4MlgDx008696; Wed, 4 Nov 2009 16:47:42 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 16:47:42 -0600 From: Nicolas Williams To: Larry Zhu Message-ID: <20091104224741.GM1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.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: [CHANNEL-BINDING] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) 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, 04 Nov 2009 22:58:51 -0000 On Wed, Nov 04, 2009 at 10:13:46PM +0000, Larry Zhu wrote: > The proposed looks fine. Thanks, Thanks. HOWEVER, Martin's post to the TLS WG list about MITM attacks in re-negotiations is relevant. Re-negotiations have no real binding between inner and outer connections. Clients can enforce that the server end-point is the same (has the same certificate, whatever) for both connections: inner and outer. Servers can also force the inner connection to change cipher specs. But suppose that the outer connection used an TLS_DH_anon_* cipher suite! Then there is no binding whatsoever between the inner and outer connection. And then we have a real problem for tls-unique. We need at least a security considerations note about this. But we should also consider changing tls-unique to be the client's Finished message for the _inner-most_ TLS connection, not outer-most. (Outer-most is OK IFF there's a binding between each channel.) Comments? Nico -- From larry.zhu@microsoft.com Wed Nov 4 16:03:21 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 EE6CF3A67BD; Wed, 4 Nov 2009 16:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnlcYCWjela; Wed, 4 Nov 2009 16:03:21 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 086C73A679F; Wed, 4 Nov 2009 16:03:20 -0800 (PST) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 16:03:42 -0800 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server id 14.0.639.20; Wed, 4 Nov 2009 16:03:42 -0800 Received: from TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.181]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi; Wed, 4 Nov 2009 16:03:43 -0800 From: Larry Zhu To: Nicolas Williams Thread-Topic: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) Thread-Index: AQHKXaJ3/jMkb6C1dEyRuhhf/zDndZEmmUig Date: Thu, 5 Nov 2009 00:03:41 +0000 Message-ID: References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <20091104224741.GM1105@Sun.COM> In-Reply-To: <20091104224741.GM1105@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] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) 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: Thu, 05 Nov 2009 00:03:22 -0000 I think this is good as is. The mentioned issue is in the TLS itself at whi= ch layer it knows every well what a TLS connection is so we do not have any= confusions related to I mentioned. Now some comments on the alternative proposals, I would prefer a stable ide= ntifier for the channel. If the name of the channel constantly changes when= TLS renegotiates, it is a bad taste in the mouth for me. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicol= as Williams Sent: Wednesday, November 04, 2009 2:48 PM To: Larry Zhu Cc: channel-binding@ietf.org; tls@ietf.org; sasl@ietf.org Subject: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindin= gs) On Wed, Nov 04, 2009 at 10:13:46PM +0000, Larry Zhu wrote: > The proposed looks fine. Thanks, Thanks. HOWEVER, Martin's post to the TLS WG list about MITM attacks in re-negotiations is relevant. Re-negotiations have no real binding between inner and outer connections. Clients can enforce that the server end-point is the same (has the same certificate, whatever) for both connections: inner and outer. Servers can also force the inner connection to change cipher specs. But suppose that the outer connection used an TLS_DH_anon_* cipher suite! Then there is no binding whatsoever between the inner and outer connection. And then we have a real problem for tls-unique. We need at least a security considerations note about this. But we should also consider changing tls-unique to be the client's Finished message for the _inner-most_ TLS connection, not outer-most. (Outer-most is OK IFF there's a binding between each channel.) Comments? Nico --=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From Nicolas.Williams@sun.com Wed Nov 4 16:25:58 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 F332528C158; Wed, 4 Nov 2009 16:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkA4hARv9z-K; Wed, 4 Nov 2009 16:25:57 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3F2BB28C154; Wed, 4 Nov 2009 16:25:57 -0800 (PST) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA50QIcB021877; Thu, 5 Nov 2009 00:26:18 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 nA50QIAw039524; Wed, 4 Nov 2009 17:26:18 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA50EmEv008766; Wed, 4 Nov 2009 18:14:48 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA50ElEP008765; Wed, 4 Nov 2009 18:14:47 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 4 Nov 2009 18:14:47 -0600 From: Nicolas Williams To: Larry Zhu Message-ID: <20091105001447.GT1105@Sun.COM> References: <20091005162704.8C1B43A6873@core3.amsl.com> <20091030223647.GO1105@Sun.COM> <20091104224741.GM1105@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] New Problem (Was: Last Call: draft-altman-tls-channel-bindings) 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: Thu, 05 Nov 2009 00:25:58 -0000 On Thu, Nov 05, 2009 at 12:03:41AM +0000, Larry Zhu wrote: > I think this is good as is. The mentioned issue is in the TLS itself > at which layer it knows every well what a TLS connection is so we do > not have any confusions related to I mentioned. I'm inclined to agree. In fact, changing tls-unique would have zero effect in an HTTPS context if authentication would likely be happening before the server requests a re-negotiation, and if it happens after re-negotiation then it's too late no matter what. Therefore I see that we don't need to change tls-unique at all. > Now some comments on the alternative proposals, I would prefer a > stable identifier for the channel. If the name of the channel > constantly changes when TLS renegotiates, it is a bad taste in the > mouth for me. tls-server-end-point channel bindings are that. tls-unique is a unique type of CB, which means it must be different every time. We can't have any sort of non-unique channel binding for anonymous- anonymous channels. We can have them for anonymous-pseudonymous channels, but we can't create those from where we stand. Nico --