Re: [TLS] tls-unique

[Simon Josefsson <[e-mail]>]

> > The introduction says:
> >
> >    There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > intended properties.  If widely implemented and deployed, the
> > channel binding type in this document would not offer any
> > additional protection.  The purpose of this document is to provide
> > an alternative channel binding that offers the intended properties
> > without requiring TLS protocol changes.  However, keep in mind that
> > TLS implementations needs to offer the appropriate APIs necessary
> > to be able to implement the channel binding described in this
> > document.
> >
> > I agree that one alternative is to require session_hash for all
> > connections.
> 
> 
> Given that you need to modify *some* software in any case, it seems
> like one ought to adopt session-hash.

The problem is if you want to resolve this at the application level and
don't have sufficient control over the TLS layer to influence it to
negotiate session-hash.  This is the situation for many SASL
applications.

If universal adoption of session-hash is a prio, then there is no
problem.  While RFC 7627 updates 5246 it does not talk a lot about what
it actually updates in 5246, or I missed it, and I haven't seen
session-hash functionality back-ported to deployed code.

My current approach works with or without session-hash negotiated, but
requires that you can get the session_hash value out of the TLS stack.

Another approach is to say that if session-hash is in use, it uses a
simple TLS exporter API call, and if it is not, it has to use TLS
exporter API on the session_hash value.  This would secure all cases.

> >   But then what is the problem with use of 'tls-unique'?
> 
> The general consensus is that 96 bits is too short.

I agree -- I used 256 bits.

/Simon