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

[Nicolas Williams <[e-mail]>]

On Wed, Oct 28, 2009 at 11:00:13AM -0500, Nicolas Williams wrote:
> On Wed, Oct 28, 2009 at 10:18:04AM +0000, Larry Zhu wrote:
> > There is a design issue in tls-unique. For vendors who implement TLS
> > in a separate library, the TLS library does not by itself control the
> > transport therefore it would not know if there is a new connection, so
> > that the current specification is not implementable for these vendors.
> > 
> > It would be much easier to say the following instead:
> > 
> > The client's TLS Finished message from the first handshake of the
> > session (note: TLS session, not connection, so that the channel
> > binding is specific to each TLS session regardless of whether session
> > resumption is used).

I spoke to Jeff and I think I understand your issue, and I agree that we
never meant for that interpretation.  Proposed new text is below, but
first...

What the text says now:

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

I think we meant to say is that if you're a server, and you see a
ClientHello, and you do a handshake and then receive a client Finished
message, and then return a handle to the application for the resulting
TLS whatever-you-call-it, then _that_ Finished message will be the
channel binding, EVEN IF the client then does a second handshake (for
re-keying, for authenticating the client, whatever).

Similarly, if you're a client and send a ClientHello and so on and so
forth and then return a handle to the application for the resulting TLS
whatever-you-call-it, then the first Finished message will be the
channel binding, EVEN IF the client then does a second handshake (for
re-keying, for authenticating the client, whatever).

The reason we used the word "connection" in the description was to avoid
the possibility that in a session resumption someone might interpret
tls-unique to be the client Finished message of the original connection
that established the session resumption state.  Changing the text to say
"session" instead of "connection" now would risk creating that
confusion.

The key issue here is how to write the description in such a way that
it is obvious to a TLS implementor in spite of the fact that the words
"connection", "session" and "transport" have multiple possible meanings
in the contexts where TLS is used.

Here, then, is my proposed clarification:

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

(Yes, I changed "connection" to "session", followed by this:)

   Clarification: If a connection resumes a previous session, then the
   Finished message to use is that of the new session, not the one from
   the original session.  If a session has multiple handshakes and,
   therefore, multiple client Finished messages, the first client
   Finished message of that session is the one to use as the tls-unique
   channel binding.  From an application programming interface (API)
   perspective, the client's Finished message is saved in the contextual
   object handle that the client and server applications obtain when
   they initiate or resume a TLS session; later, when the applications
   request the tls-unique channel binding, the TLS implementation
   retrieves the saved first client Finished message from that context
   handle.

Nico
--