Hi, Recently both Adam Langley [1] and David Benjamin [2] indicated that they expect with TLS 1.3 Browsers will have to bring back the infamous version falbacks that caused so much trouble in the past (POODLE etc.) to work around broken implementations of the TLS handshake.
I don't blame browser vendors for this, I can understand their reasoning why they think they have to do this, although I don't share their opinion. But I think this sheds a light on the sorry state of TLS implementations and I want to ask if there's a better way out of this. Let me quickly summarize how I see the situation: * The issue has been known for a long time. I found a document from Mozilla [3] from 2003 that describes the core issue. * While there is a lot of scattered discussion about the issue, the pure documentation status of this problem is far from ideal. I am not aware of any good documentation that even describes how exactly version intolerance happens. The "classic" variant seems to be implementations that just close the connection if they are contacted with a version number higher than what they support. But there are also weirder variants where a connection attempt with TLS 1.2 will be downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead to an answer with TLS 1.0. Questions I couldn't easily answer is how connections are terminated (TCP disconnect? TLS alert? Timeouts?) Also I'm not fully aware what the different version numbers (ClientHelo + record version number) mean in context of a handshake and how this influences version intolerance issues. * There don't seem to be any straightforward tools that test for version intolerance. The SSL Labs test does detect version intolerance, but it's limited to public facing https servers and it doesn't seem to detect some of the weirder variations (as described above). There's also a test in Hubert Kario's tlsfuzzer, but I've been unable to get it to work. I tried to create a test myself, but the results were highly erratic and I'm not sure why. * We don't have good data on the issue. The latest numbers I could find came from Ivan Ristic in 2013 [4], and from David Benjamin we know he considers the problem to be large enough that version fallbacks are inevitable. That's far from good data. We also don't seem to have any public list of affected vendors, devices and webpages. I want to try to work on some of those issues in the near future. Roughly I'd like to see that we work on a plan to reduce TLS brokenness in general and in particular - right now as this is an issue affecting the deployment of TLS 1.3 - Version intolerance. Things that I think we could and should do: * Talk to developers of test tools (sslyze, testssl, openvas, but also commercial tools etc.) that they include appropriate tests in their tools and warn about these issues. Also it'd be great if e.g. things like the google webmaster tools or any other public test tools for webservers/websites could test for this. * Raise this issue with pentesters and tell them they should include this when they're testing devices / products. (Of course this requires to have test tools in the first place.) * Get some data from internet wide scans and make it public. Maybe have a public shame list of the top X pages breaking TLS. * In general, more and better detailed documentation of this and similar issues, also raise this as a potential research topic. My hope would be that we can avoid the reintroduction of version fallbacks or at the very least reduce the amount of time they have to be used. And hopefully at least avoid them altogether for TLS 1.4 or whatever comes after 1.3. I'm in Berlin at IETF96 in case people want to discuss this. As this is terribly late for this I don't know if this can be included in the TLS WG discussion as it's probably already packed with other issues (but I'd happily introduce the issue if people want to discuss it). [1] https://www.imperialviolet.org/2016/05/16/agility.html [2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html [3] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers [4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls