Bulletproof TLS Newsletter #42
Does TLS have to change constantly to make it future-proof?
28 Jun 2018
Author: Hanno Böck

This issue was distributed to 45,789 email subscribers.

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space.

In this issue:

  1. Does TLS have to change constantly to make it future-proof?
  2. Short news

Does TLS have to change constantly to make it future-proof?

The TLS 1.3 standard will soon be finished; however, getting here wasn’t always easy. One problem that accompanied the standardization process was devices assuming old TLS versions. These issues were worked around by protocol quirks—making the protocol needlessly complex, but also deployable. We’ve followed this development in our newsletter. To avoid similar issues in the future, the only option may be to change TLS constantly.

First, there was version intolerance: devices receiving a TLS 1.3 connection would not downgrade to a lower version. To avoid these problems, version negotiation was moved to an extension, and the GREASE mechanism, invented by David Benjamin from Google, was introduced. TLS 1.3 implementations can send a set of bogus version numbers that servers are meant to ignore. The same mechanism can also be used for other fields, like cipher suites.

But version negotiation wasn’t the only problem: middleboxes would assume that TLS packages would follow the format they had used in TLS 1.2 and would break connections if they didn’t. By making TLS 1.3 look more like 1.2, many of these issues could be remedied.

Going forward, the question is how to avoid similar pain in the future. Experience has shown that device makers are unlikely to learn from previous mistakes. Misunderstandings about what you can and can’t do without breaking the TLS protocol are prevalent, and even institutions like the UK government’s National Cyber Security Center seem to be confused.

David Benjamin has proposed something that sounds extreme, but it may be just what’s needed to deploy changes in TLS in the future. The idea is that beside the normal, standardized version of TLS 1.3, there could be temporary variations of it. These would change every few weeks. Some servers and browsers could support them for short amounts of time.

Given the large market share belonging just to Chrome and Google’s own services, it would be unlikely that anyone would deploy devices that break connections between them. It also would be no problem if browsers and web pages couldn’t agree on a temporary TLS version: they can always fall back to standardized TLS 1.3 (at least if both sides implement version negotiation correctly, but this is likely for the implementations participating in such an effort).

Short news