Just Published: A New Version of the TLS Guidelines
Yaron Sheffer, Peter Saint-Andre and Thomas Fossati #
There’s a new standard out, RFC 9325, with guidelines on secure use of TLS. This short post will explain some of the history behind it and why you might want to explore this document.
In early 2013, we started working on a set of guidelines for Transport Layer Security (TLS) deployments. TLS is the security protocol that underlies much of today’s internet. In fact, almost all web pages today are served over HTTPS, which means the HTTP protocol is layered on top of TLS. Many years ago, the same protocol was called Secure Socket Layer or SSL, and this is the name many people still use to refer to TLS.
Back in 2013, TLS was in crisis. It was becoming increasingly clear that the internet needed to move into a fully encrypted model, especially after the Snowden revelations in mid-2013. TLS was the obvious technology to do the job. But the most commonly deployed TLS version was still overwhelmingly TLS 1.0, a 14-year-old protocol. Even though a major upgrade, TLS 1.2, had been standardized in 2008. On top of that, a bunch of attacks on the TLS protocol were being discovered on a regular basis, some of them limited to TLS 1.0 and others applying to the most up-to-date deployments.
The TLS community finally mobilized. Browser and server vendors and standards bodies such as the IETF worked together to (1) increase adoption of TLS 1.2, (2) ensure that TLS 1.2 is used securely, and (3) come up with a successor for TLS 1.2, namely TLS 1.3.
RFC 7525, published in 2015, is a “best current practices” document that goes into the technical details of what a secure deployment of TLS 1.2 actually means. It covers a lot of ground, including TLS version negotiation, allowed and disallowed ciphersuites (cryptographic algorithms), TLS features like renegotiation and session resumption, and a lot more. It is not the only document that makes recommendations on the secure use of TLS, but it is very comprehensive and was published by the IETF, the same standards organization that defines the protocol itself. As a result, this document has been an important catalyst for the industry adoption of TLS 1.2 and the move to more secure TLS configurations.
Then the IETF went on to create a brand new version of TLS, TLS 1.3. This version is very different from TLS 1.2 and is a lot more secure. In fact, at some point, there was debate around whether it should be named TLS 2.0, and perhaps it should have been. Version numbers aside, TLS 1.3 (published in 2018) was adopted much more quickly than previous versions.
So, here we are today: TLS 1.0 and 1.1 are dead, for all intents and purposes. TLS 1.2 is still important, with roughly 40% of internet traffic still reliant on it. The majority of traffic has migrated to TLS 1.3. The situation is so different from what it was in 2015 that we felt a new set of guidelines is required, coming in the form of the brand new RFC 9325.
RFC 9325 provides guidance on the use of TLS 1.2 and 1.3. (Spoiler: TLS 1.2 is a MUST while 1.3 is still only a SHOULD because the IETF cares greatly about interoperability.) There’s the old stuff about TLS 1.2 ciphersuites dos and don'ts. This is largely irrelevant if you’re only using TLS 1.3, which has but a few ciphersuites that are all top-notch, but many new systems still rely on TLS 1.2.
Since 2015, there have been a few new attacks on TLS 1.2, though not as many as in the bad old days. The good news is that attack names are getting better and better. These new attacks are documented in the new RFC, and mitigations are suggested.
TLS 1.3 is not perfect either, with the 0-RTT feature widely seen as dangerously trading off security for performance (fast connection setup). Here the RFC only needed to cite the warning from the document that defines TLS 1.3.
Sadly, the situation around certificate revocation is still murky due to a lot of conflicting standards, some with minimal industry support. The document bravely wades into these waters and comes up with a general recommendation.
We incorporated recent work done at the CFRG on cipher limits — how much data one is allowed to encrypt with each particular cipher before security is impacted. The limits are high but still reachable with a long-lived connection on a high-bandwidth network. If this is your network, please review Section 4.4 to make sure you rekey your connections often enough.
The bibliography consists of 98 entries and spans 20+ years across multiple domains — basic math and crypto, protocol and software vulnerability research, standardization, and implementation experience. We tried hard to distill that huge pile of information into simple and actionable text.
Moving forward, there is always new work being done to improve the security of the internet. The TLS working group is developing an Encrypted Client Hello spec whose goal is to eliminate the cleartext Server Name Indication (SNI) field that’s heavily used in TLS but is a privacy hazard. This work is not ready yet, i.e., it is not yet published as an RFC, but keep an eye out!
We would like to thank the many IETF folks who passionately debated every last point in this document. It would be worthwhile if we improved, even a little, the security of everyone’s internet.