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

[Simon Josefsson <simon at josefsson.org>]

Nicolas Williams <Nicolas.Williams at sun.com> writes:

> On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote:
>> <Pasi.Eronen at 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