Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:

[Nicolas Williams <[e-mail]>]

On Wed, Nov 04, 2009 at 02:16:29AM +0100, Martin Rex wrote:
> Nicolas Williams wrote:
> > 
> > On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote:
> > > Martin Rex <[e-mail]> writes:
> > > 
> > > > It might be easier to _NOT_ key on the finished message, but on the
> > > > master secret instead.
> > > 
> > > That was my conclusion as well, hence
> > > http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00
> > > which uses the TLS PRF interface.
> > > 
> > > For -02 I also added hashing the Finished message, to match the
> > > semantics for connection/session (regardless of its definition) of
> > > draft-altman-tls-channel-bindings, but I'd prefer to avoid it
> > > completely.
> > 
> > I don't agree.  That it's easier to speak of the master secret is not
> > enough.  The Finished message's construction provides better binding of
> > the entire negotiation (up to that Finished message), and that's why we
> > chose it.
>  
> 
> I have not yet understood what semantics you and Larry are actually
> looking for.

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

See my follow-up, just now, that begins with that same text.

> Is it (1)
> about binding to a specific incarnation of a TLS session
> over one single network connection, then TLS PRF would be OK.
> Using the Finished message of the TLS handshake (independent
> of whether it was a full handshake or a resume) would be
> equivalent.

The latter: the client's Finished message from a handshake that is not
protected by any other TLS connection, and regardless of whether the
handshake is a session resumption handshake.

> Or is it (2)
> about binding to a particular full TLS handshake (and the
> authentication of one of both peers in that full TLS handshake),
> so that it can be used on several parallel connections and with short
> interruptions of the network connection, provided that TLS session
> caching is used and works correctly.

No.  This is not about whether the client or server are authenticated.
Authentication in the TLS layer is irrelevant to the channel binding.

We want to be able to bind to anon-anon TLS connections.

> TLS session renegotiation reshuffles the cards, so any kind of
> channel binding or TLS PRF usage must be deferred until
> the urge for renegotiation among the peers has been fully
> saturated/quenched to both peers satisfaction.

Re-negotiation is not an issue: it suffices to use a channel binding for
the "first" connection, meaning: a connection whose handshake is not
protected by another connection, and NOT meaning: the one that
established a session that is being resumed.