Re: [TLS] tls-unique

[Eric Rescorla <[e-mail]>]

On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson <[e-mail]> wrote:

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

I'm not sure what you mean by "backported", but I believe that BoringSSL
presently has session-hash, SChannel has it soon or does already, and
the next version of NSS (3.21) will have it.


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

I am not aware of a stack which has this function. Are you?

-Ekr

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
>