> > 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
pgpP0BuKKpBQi.pgp
Description: OpenPGP digital signatur
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
