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

[<[e-mail]>]

Martin Rex wrote:

> > 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.
> 
> If you refer to the TLS-extractor interface with TLS PRF, that does
> unconditionally include the client.random and server.random in the
> computation and therefore the output will differ for different
> incarnations (resumes) of the same TLS session.  That is comparable
> to keying to the _most_recent_ finished message -- with __NO__
> special cased for TLS session resume and TLS renogiation.

Note that just extracting some bytes from the TLS master secret (with
TLS extractor) is not sufficient to produce a channel binding,
because with RSA cipher suites, a man-in-the-middle could cause two
TLS sessions to have the same TLS master secret (this is explained in
draft-ietf-tls-extractor-07, Section 5). But those two sessions would
have different Finished messages.

(Version -00 of draft-josefsson-sasl-tls-cb had this problem. Newer
versions avoid it by including the handshake messages (either hashed, 
or via the Finished message) in the calculation.)

Best regards,
Pasi