Re: [CHANNEL-BINDING] [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
Simon Josefsson <simon@josefsson.org> Wed, 04 November 2009 19:26 UTC
Return-Path: <simon@josefsson.org>
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 <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BAE0E5@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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 <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2009 19:26:14 -0000
Nicolas Williams <Nicolas.Williams@sun.com> writes: > On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote: >> <Pasi.Eronen@nokia.com> 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
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Nicolas Williams
- [CHANNEL-BINDING] Last Call: draft-altman-tls-cha… The IESG
- Re: [CHANNEL-BINDING] Last Call: draft-altman-tls… Simon Josefsson
- Re: [CHANNEL-BINDING] Last Call: draft-altman-tls… Nicolas Williams
- [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLVED (… Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Pasi.Eronen
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Simon Josefsson
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Simon Josefsson
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Nicolas Williams
- [CHANNEL-BINDING] lasgt call comments (st Call: d… Larry Zhu
- Re: [CHANNEL-BINDING] lasgt call comments (st Cal… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] lasgt call comments … Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] [sasl] lasgt call com… Martin Rex
- [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Simon Josefsson
- Re: [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Peter Gutmann
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLV… Martin Rex
- Re: [CHANNEL-BINDING] Unrelated (Re: [TLS] RESOLV… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Martin Rex
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Pasi.Eronen
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [sasl] [TLS] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Jeffrey Hutzelman
- Re: [CHANNEL-BINDING] [sasl] [TLS] lasgt call com… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Michael D'Errico
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Sam Hartman
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Simon Josefsson
- Re: [CHANNEL-BINDING] [TLS] lasgt call comments (… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] RESOLVED (Re: [sasl] … Larry Zhu
- [CHANNEL-BINDING] New Problem (Was: Last Call: dr… Nicolas Williams
- Re: [CHANNEL-BINDING] [TLS] New Problem (Was: Las… Larry Zhu
- Re: [CHANNEL-BINDING] [TLS] New Problem (Was: Las… Nicolas Williams