[TLS] Thoughts on Version Intolerance

[Hanno Böck <[e-mail]>]

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: [e-mail]
GPG: BBB51E42