Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 18:24 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 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 <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20091104181257.GY1105@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>
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, tls@ietf.org, sasl@ietf.org
Subject: Re: [TLS] [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2009 18:24:07 -0000

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.

Nico
--