TLS 1.3: One Year Later

A measure of success for an IETF protocol is the extent to which it is deployed and used. The IETF published TLS 1.3 as RFC 8446 in August 2018. As we near the end of the first full year after publication, it is worth looking at how TLS 1.3 is now in use on the Internet. This article provides an overview of the protocol and its path through the standardization process, including how “running code” was integral to its development. To recap, TLS 1.3 updates the most important security protocol on the Internet, delivering superior security, performance, and privacy. Here are a few key ways TLS 1.3 does this: 

• Safer cryptographic primitives,
• Simplified negotiation,
• Fewer round trips,
• Early application data (or 0-RTT) support,
• Design backed up by formal security analysis, and
• More handshake encryption.

For these reasons and others, TLS 1.3 has seen already seen tremendous uptake in clients and servers. 

Current deployment statistics

One interesting way to look at deployment is that there was more TLS 1.3 use in the first five months after RFC 8446 was published than in the first five years after the last version of TLS was published as an RFC. And that growth has continued, including web browsers, mobile operating systems, embedded devices and, more generally, TLS implementations. 

Table 1 below lists the percentage of connections that negotiate TLS 1.3 from major web browser implementations as of August 2019.

Measurements of TLS 1.3 adoption from iOS clients in June reveal some additional interesting insights. For example, server support of TLS 1.3 is strongly correlated with servers that provide support for other modern protocols like IPv6 and HTTP/2. Nearly 36% of servers that are accessible over IPv6 also support TLS 1.3, and 40% of servers that support HTTP/2 also support TLS 1.3. From a performance perspective, the aggregated iOS client data shows demonstrable improvement in reducing round-trips for a TLS handshake. Connections which use TLS 1.3 are twice as likely to complete their TLS handshakes in under 100 milliseconds when compared to TLS 1.2 connections.

Growth on the server side is also increasing steadily, as evidenced by the growth trend seen by Cloudflare in Figure 1. 

In the embedded space, WolfSSL, which provides secure communication for Internet of Things (IoT), smart grid, connected home, routers, applications, games, phones, and more estimates that roughly 20% of their TLS consumers have moved to TLS 1.3, with many more moving to TLS 1.3 during their next upgrade cycle.

Summary of implementations, library support, and protocol integration

Much of TLS 1.3's uptake is due to widespread support for the protocol being added to existing TLS implementations. Major TLS implementations such as NSS, BoringSSL, OpenSSL, GnuTLS, wolfSSL have all added support for TLS 1.3, in addition to TLS 1.2 and earlier versions of the protocol. 

However, we have also seen stacks with only TLS 1.3 support emerge. These include production implementations such as Facebook's Fizz. Popular languages and system frameworks such as Go, Swift, Java, rustls, and Apple's Network.framework also include support for TLS 1.3 by default. And, of course, all major browsers, including Chrome, Firefox, and Safari support TLS 1.3 by default. (If you are running on a different browser, you can check out SSL-labs to test for TLS 1.3 support.)

Several experimental, i.e., not production ready, TLS 1.3 implementations used mainly for protocol interop and ease-of-use also exist. These include Tris, Mint, picotls, and rusttls. These implementations are important, especially with the ongoing development of QUIC.

TLS 1.3 and other protocols

TLS 1.3 is also being considered in the development of other IETF protocols. QUIC uses TLS 1.3 as its (authenticated) key exchange protocol. The integration with QUIC raised interesting questions around how TLS best fits into the context of other protocols. Early QUIC designs used TLS wholesale, i.e., by transporting well-formed TLS records inside a dedicated QUIC stream.

Beyond the need for double encryption—one pass from the TLS record layer, and another from the QUIC packet protection layer—this design added complexity to implementations that was not otherwise necessary. Since then, the QUIC working group modified the design to use QUIC packet protection in place of the TLS record layer, avoiding double encryption while more tightly coupling the two protocols.

While the development of the TLS 1.3 protocol was accompanied by significant work at IETF Hackathons and elsewhere on running code, there have been some obstacles found during deployment. Implementation bugs, such as those in Java JDK 11, as well as those surrounding KeyUpdate messages, have impeded or stalled deployment of TLS 1.3 and some of its desirable features. The good news, beyond implementation bugs from which the ecosystem can likely recover over time and with software updates, is that TLS 1.3 has encountered only one published issue since its publication: the Selfie attack. 

Selfie relies on a misuse of the (external) PSK interface. In particular, it may affect deployments where nodes can act as both client and server. At a high level, if such nodes do not verify server identities, i.e., names, during handshakes with PSK-based authentication, an attacker can cause a node to establish a connection with itself, thereby acting as both client and server. Nir Drucker and Shay Gueron, finders of this problem, recommend that “A PSK MUST NOT be shared between more than one client and one server.”

Ongoing and Future Work for the TLS WG

Looking ahead, TLS 1.3 has a bright future. Several critical extensions are already underway and approaching standardization, including:

• Certificate compression: reduce bytes in flight for TLS 1.3 and QUIC.
• Exported authenticators: help build application-layer authentication mechanisms that are superior to post-handshake authentication in TLS 1.3.
• GREASE: help prevent version-specific network ossification of TLS.
• Delegated credentials: support short-lived server credentials and help promote leaf certificate management safety and isolation of long-term private signing keys.
  
  

Moreover, while the core protocol is finalized, there still remains several open problems to address, and the TLS working group (TLS WG) is actively working on them. These include, among others, encrypted SNI and safe external PSK support for TLS 1.3. Beyond extensions focused on TLS 1.3, the TLS WG is in the process of publishing a document that deprecates TLS 1.0 and TLS 1.1.

Check out the TLS WG website for more information about working group and its ongoing work to improve one of the more critical security protocols used on the Internet.