Eric Rescorla <e...@rtfm.com> writes: > 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.
If session-hash isn't backported to deployed code, like some other security fixes has been backported (e.g., secure renegotiation), it will take years until it is deployed. Using only an TLS exporter interface will therefor be insecure meanwhile, as far as I understand, since it doesn't bind the entire handshake messages. However, you could have a new TLS channel binding based on the TLS exporter interface that demands use of session-hash, as you suggest. >> 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? No. Either the application inspects the handshake or code has to be added. /Simon
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
