On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson <si...@josefsson.org> 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
