Skip to main content
  • IETF 116 Yokohama registration now open

    Registration is now open for IETF 116 Yokohama

    • Jay DaleyIETF Executive Director
    24 Nov 2022
  • IETF 115 post-meeting survey

    IETF 115 London was held 5-11 November 2022

    • Jay DaleyIETF Executive Director
    22 Nov 2022
  • Catching up on IETF 115

    Recordings are now available for sessions held during the IETF 115 meeting and the IETF Hackathon, where more than 1500 participants gathered in London and online 5-11 November 2022.

      13 Nov 2022
    • Opportunities for university researchers and students during IETF 115

      The upcoming IETF 115 meeting in London on 5-11 November 2022 is a unique opportunity for networking researchers to learn how RFCs are written, to engage with the Internet standards community to begin to develop research impact, and to meet more than 1,000 leading technologists from around the world currently working in industry, academia, and other organizations.

        1 Nov 2022
      • Suggested IETF 115 Sessions for Getting Familiar with New Topics

        These IETF 115 meeting sessions are likely to include discussions and new proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.

          24 Oct 2022

        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