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

[Nicolas Williams <[e-mail]>]

On Wed, Nov 04, 2009 at 04:18:44PM +0100, Simon Josefsson wrote:
> <[e-mail]> 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
--