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

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 30 October 2009 22:48 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 F411B3A68B1; Fri, 30 Oct 2009 15:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfIUfHhXy2Bj; Fri, 30 Oct 2009 15:48:01 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 0973B3A6843; Fri, 30 Oct 2009 15:48:00 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9UMmFPs019151; Fri, 30 Oct 2009 22:48:15 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9UMmFvG011443; Fri, 30 Oct 2009 16:48:15 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9UMamJo004135; Fri, 30 Oct 2009 17:36:48 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9UMam8c004134; Fri, 30 Oct 2009 17:36:48 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 30 Oct 2009 17:36:48 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Larry Zhu <larry.zhu@microsoft.com>
Message-ID: <20091030223647.GO1105@Sun.COM>
References: <20091005162704.8C1B43A6873@core3.amsl.com> <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.com>
User-Agent: Mutt/1.5.7i
Cc: "channel-binding@ietf.org" <channel-binding@ietf.org>, "tls@ietf.org" <tls@ietf.org>, "sasl@ietf.org" <sasl@ietf.org>
Subject: [TLS] RESOLVED (Re: [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: Fri, 30 Oct 2009 22:48:02 -0000

I spoke at length with Larry.

His concern is that the word "conenction" might be taken to mean "TCP
connection" or "connection for the transport below TLS".

Clearly it is not reasonable to expect to extract the TLS channel
binding from the "connection for the transport below TLS"!

Larry's proposal to say "session" was only to make that confusion go
away, but that proposal is very difficult to implement (as I described
separately already).

Larry has indicated to me (and I expect will indicate on the list in
reply to this email) that he will be happy if we simply clarify that
"TLS connection" refers to the TLS state, NOT to the transport below.

Unfortunately RFC5246 does not seem to have a term by which to refer the
"TLS connection" unambiguously: "connection" is defined in the glossary
(page 80) to mean that which Larry doesn't want (underlying transport),
but then, in section 6.1 RFC5246 quite clearly uses the word
"connection" to refer to "TLS connection", not to the underlying
transport.

Thus this is a simple matter of wordsmithing.

Another problem that Larry has is that in his implementation what I call
a "TLS connection" is called a "security context", and if the
application re-handshakes (e.g., to authenticate a user) then the result
is a second security context -- we need to be extra clear that it's the
client Finished message from the _first_ "security context" that we're
after.

My proposal, then, is this:

OLD:

   Description: The client's TLS Finished message (note: the Finished
   struct) from the first handshake of the connection (note: connection,
   not session, so that the channel binding is specific to each
   connection regardless of whether session resumption is used).

NEW:

   Description: The client's TLS Finished message (note: the Finished
   struct) from the first handshake of the application's TLS connection.

   NOTES:

   a) If a session is resumed, the client's TLS Finished message from
      the session resumption handshake is to be used;

   b) If a client does multiple TLS handshakes in sequence, each
      protected by the previous one, then the client's TLS Finished
      message from the first/outermost TLS connection is to be used;

   c) By "TLS connection" we refer to the TLS connection state, not to
      any notion of connection of any underlying transport protocols
      (such as TCP, UDP, SCTP, etcetera).

I'm not sure that we can make it any clearer.

Larry, please review.

Martin, please review.

Nico
--