On 2009-12-07 03:20 PST, Ian G wrote: > Nelson, > > can you say something about whether & when Firefox will deliver "relief" > for this issue? > > My motivation for the question is here: > http://financialcryptography.com/mt/archives/001210.html
Well, first, I must tell you about the plans of the IETF TLS working group and the plans of NSS for the future of SSL/TLS renegotiation. The IETF TLS working group is working now on drafting a new improved standard for "safe renegotiation". The result is expected to offer a way for a client and server to do renegotiation without vulnerabilities of the forms that present renegotiation has. It is also expected to offer a way for a client to tell a server "I no longer do unsafe renegotiation", and for a server to likewise respond "I no longer do unsafe renegotiation" in the initial negotiation. This will enable a client to protect itself from completing a handshake with an unsafe server, and likewise, will enable a server to protect itself from completing a handshake with an unsafe client. Only then will a client and server truly be able to be certain that they are not vulnerable. Until then, even a client that has disabled renegotiation completely is vulnerable if it handshakes with an unpatched (and hence unsafe) server, and likewise, a server that has disabled renegotiation completely is still potentially vulnerable if it handshakes with an unpatched client. (The renegotiation MITM attack can work either way. The MITM can "splice" streams from two clients into an unpatched server, or from two servers into an unpatched client.) The relief that NSS has delivered in NSS 3.12.5 is a first phase, interim relief, until such time as NSS can deliver the new standard for safe renegotiation and safety signaling. It is hoped that the IETF TLS WG will finish its work very soon (this month) and that a new NSS release will be forthcoming also very soon (this month or next). Now, as to "whether and when" any particular product that uses NSS will deploy any particular fix, that is up to each individual product to decide for itself, and those products must speak for themselves. Looking at the SSL/TLS software industry as a whole, we are seeing an amazing variety of responses from various vendors, including: - disabling all renegotiation by default - disabling renegotiation only in https servers and not in other servers nor in any clients. - disabling renegotiation in all servers only, not in clients. - disabling only client-initiated renegotiation, not server-initiated, in servers only, or in both clients and servers. - disabling renegotiation in some versions of SSL/TLS but not others A number of major software vendors have publicly stated that they believe their customers will not tolerate ANY reduction in functionality for any period of time longer than a few hours, vulnerability or not. Some server vendors seem to genuinely believe that only client-initiated renegotiations are vulnerable. I would have to summarize what I see as being that software vendors as a group mostly think their customers (both commercial and consumers) value security as a distant second to even the most minute nuances of functionality and convenience, especially in December. I realize this doesn't directly answer your question. Someone who is truly empowered to speak for MoCo will have to do that. -- dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
