Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call:
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Nicolas Williams wrote:
> 
> On Mon, Nov 02, 2009 at 04:55:48PM +0100, Simon Josefsson wrote:
> > Martin Rex <Martin.Rex at sap.com> 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.

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.


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.


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.


-Martin

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.