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

Simon Josefsson <> Wed, 04 November 2009 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 254DD3A68E7; Wed, 4 Nov 2009 11:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.695
X-Spam-Status: No, score=-2.695 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cUoplztkeEdB; Wed, 4 Nov 2009 11:26:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D05A73A67B6; Wed, 4 Nov 2009 11:26:12 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (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: <> <> <> <> <> <> <20091104181257.GY1105@Sun.COM>
OpenPGP: id=B565716F; url=
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: <>
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
Subject: Re: [TLS] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard)
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." <>
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.