Skip to main content
  • Public side meetings at IETF meetings

    The feedback provided in post-meeting surveys frequently references the public side meetings that are held during or alongside IETF meetings. Some feedback is about how those meetings are run, while other feedback is about the level of IETF support for side meetings.

    • Lars EggertIETF Chair
    21 Jun 2021
  • QUIC working group looks to bring more security to Internet traffic

    Lucas Pardue serves as co-chair of the IETF QUIC Working Group, which focuses on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. The IETF blog recently asked Pardue about the QUIC standards project.

    • Grant GrossIETF Blog Reporter
    14 Jun 2021
  • Q&A with our new Director of Development

    Lee-Berkeley Shaw joins the IETF Administration LLC today as Director of Development. She will focus on designing and delivering the strategy to achieve the IETF’s goals for financial sustainability, with a focus on growing the IETF Endowment. We asked her questions about her plans for the IETF and her background.

    • Grant GrossIETF Blog Reporter
    7 Jun 2021
  • A new era in Internet transport

    The IETF’s Transport and Services (TSV) area is developing several potentially transformative technologies while it continues to maintain many of the foundational protocols of the Internet.

    • Martin DukeTransport Area Director
    • Zaheduzzaman SarkerTransport Area Director
    • Magnus Westerlund
    3 Jun 2021
  • Innovative New Technology for Sending Data Over the Internet Published as Open Standard

    Already broadly deployed and used, QUIC provides lower delay, improved security, and more robust delivery of data.

      3 Jun 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