Skip to main content
  • Applied Networking Research Prize presentations at IETF 112

    The Internet Research Task Force (IRTF) open session at the IETF 112 online meeting will feature presentations on research into routing protocols, the effects of third-party service dependencies, and censorship on the Internet. IETF 112 is scheduled for November 8 to 12.

    • Grant GrossIETF Blog Reporter
    27 Oct 2021
  • Fresh perspectives from IETF Administration LLC Board

    Two members of the IETF Administration LLC Board of Directors bring deep expertise and experience from outside the realm of developing technical standards, providing perspectives about the factors and priorities important to advancing the community’s work and IETF mission more broadly.

    • Grant GrossIETF Blog Reporter
    27 Sep 2021
  • IETF 111 Hackathon: Coding across time zones

    The IETF 111 Hackathon was held July 19-23, 2021. This was the 19th IETF Hackathon, and the 4th held as an online only event. For most people involved in the IETF the past several years, the IETF Hackathon marks the start of each IETF meeting.

    • Charles EckelIETF Hackathon Co-chair
    8 Sep 2021
  • IETF 111 post-meeting survey

    The results from our IETF 111 post-meeting survey are now available.

    • Jay DaleyIETF Executive Director
    22 Aug 2021
  • IETF Community Survey 2021

    In May 2021, the IETF Administration LLC (IETF LLC) on behalf of the IESG and in collaboration with the IAB distributed the first annual IETF community survey to all 56,000 addresses subscribed to IETF mailing lists. Its purpose was "To help better understand our community and its makeup, gather views on the IETF and how well it works for participants, and gain insight into how we compare to similar organisations".

    • Jay DaleyIETF Executive Director
    11 Aug 2021

Filter by topic and date

Filter by topic and date

TLS 1.3: One Year Later

  • Joseph A. SaloweyTLS Working Group Chair
  • Sean TurnerTLS Working Group Chair
  • Christopher A. WoodTLS Working Group Chair

17 Dec 2019

Just over a year after it was published as an RFC, TLS 1.3 adoption is growing rapidly.

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. 

TLS 1.3 Badge

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.

Browser Percentage of TLS 1.3
Chrome 30%
Firefox 27%
Safari 27%
Table 1: Percentage of TLS 1.3 connections amongst web browsers.


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. 

Figure 1: TLS version trends as seen by Cloudflare from May 2018 to May 2019.
Figure 1: TLS version trends as seen by Cloudflare from May 2018 to May 2019.

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 NSSBoringSSLOpenSSLGnuTLSwolfSSL 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 GoSwiftJavarustls, and Apple's Network.framework also include support for TLS 1.3 by default. And, of course, all major browsers, including ChromeFirefox, 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 TrisMintpicotls, 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.

QUIC-TLS-integration.png
Figure 2: Old style QUIC and TLS interaction. Both TLS and QUIC encrypt TLS handshake and application_data in transit.


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.

QUIC-TLS-integration.png
Figure 3: New style QUIC and TLS integration. QUIC encrypts TLS messages using keys derived from TLS secrets.


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.


Share this page