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

<Pasi.Eronen@nokia.com> Wed, 04 November 2009 14:28 UTC

Return-Path: <Pasi.Eronen@nokia.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 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: <Pasi.Eronen@nokia.com>
To: <Nicolas.Williams@sun.com>, <larry.zhu@microsoft.com>
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> <D3DC9D45B39CFC4CB312B2DD279B354C29BADFF7@TK5EX14MBXW653.wingroup.windeploy.ntdev.microsoft.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: [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: Wed, 04 Nov 2009 14:28:45 -0000

Nicolas Williams wrote:

> 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.

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".  
  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