Transport Layer Security (tls) Internet Drafts

      
 TLS Encrypted Client Hello
 
 draft-ietf-tls-esni-25.txt
 Date: 14/06/2025
 Authors: Eric Rescorla, Kazuho Oku, Nick Sullivan, Christopher Wood
 Working Group: Transport Layer Security (tls)
 This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).
 A Flags Extension for TLS 1.3
 
 draft-ietf-tls-tlsflags-16.txt
 Date: 14/09/2025
 Authors: Yoav Nir
 Working Group: Transport Layer Security (tls)
 A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8.
 Hybrid key exchange in TLS 1.3
 
 draft-ietf-tls-hybrid-design-16.txt
 Date: 07/09/2025
 Authors: Douglas Stebila, Scott Fluhrer, Shay Gueron
 Working Group: Transport Layer Security (tls)
 Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if a way is found to defeat the encryption for all but one of the component algorithms. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3.
 The Transport Layer Security (TLS) Protocol Version 1.3
 
 draft-ietf-tls-rfc8446bis-14.txt
 Date: 13/09/2025
 Authors: Eric Rescorla
 Working Group: Transport Layer Security (tls)
 This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations.
 Return Routability Check for DTLS 1.2 and DTLS 1.3
 
 draft-ietf-tls-dtls-rrc-20.txt
 Date: 14/07/2025
 Authors: Hannes Tschofenig, Achim Kraus, Thomas Fossati
 Working Group: Transport Layer Security (tls)
 This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Implementations offering the CID functionality described in RFC 9146 and RFC 9147 are encouraged to also provide the return routability check functionality described in this document. For this reason, this document updates RFC 9146 and RFC 9147.
 IANA Registry Updates for TLS and DTLS
 
 draft-ietf-tls-rfc8447bis-15.txt
 Date: 21/07/2025
 Authors: Joseph Salowey, Sean Turner
 Working Group: Transport Layer Security (tls)
 This document updates the changes to TLS and DTLS IANA registries made in RFC 8447. It adds a new value "D" for discouraged to the Recommended column of the selected TLS registries and adds a "Comment" column to all active registries that do not already have a "Comment" column. Finally, it updates the registration request instructions. This document updates RFC 8447.
 Deprecating Obsolete Key Exchange Methods in (D)TLS 1.2
 
 draft-ietf-tls-deprecate-obsolete-kex-06.txt
 Date: 23/06/2025
 Authors: Nimrod Aviram
 Working Group: Transport Layer Security (tls)
 For (D)TLS 1.2, this document deprecates the use of two key exchanges, namely Diffie-Hellman over a finite field and RSA, and it discourages the use of static elliptic curve Diffie-Hellman cipher suites. These prescriptions apply only to (D)TLS 1.2 since (D)TLS 1.0 and TLS 1.1 are deprecated by RFC 8996 and (D)TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. (There is no DTLS version 1.1.) This document updates RFCs 9325, 4346, 5246, 4162, 6347, 5932, 5288, 6209, 6367, 8422, 5289, 5469, 4785, 4279, 5487, 6655, and 7905.
 A well-known URI for publishing service parameters
 
 draft-ietf-tls-wkech-09.txt
 Date: 02/09/2025
 Authors: Stephen Farrell, Rich Salz, Benjamin Schwartz
 Working Group: Transport Layer Security (tls)
 We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service bindng data such as information about TLS supported groups is unlikely to change quickly, but the origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record.
 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
 
 draft-ietf-tls-svcb-ech-08.txt
 Date: 16/06/2025
 Authors: Benjamin Schwartz, Mike Bishop, Erik Nygren
 Working Group: Transport Layer Security (tls)
 To use TLS Encrypted ClientHello (ECH) the client needs to learn the ECH configuration for a server before it attempts a connection to the server. This specification provides a mechanism for conveying the ECH configuration information via DNS, using a SVCB or HTTPS resource record (RR).
 TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key
 
 draft-ietf-tls-8773bis-13.txt
 Date: 05/09/2025
 Authors: Russ Housley
 Working Group: Transport Layer Security (tls)
 This document specifies a TLS 1.3 extension that allows TLS clients and servers to authenticate with certificates and provide confidentiality based on encryption with a symmetric key from the usual key agreement algorithm and an external pre-shared key (PSK). This Standards Track RFC (once approved) obsoletes RFC 8773, which was an Experimental RFC.
 Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
 
 draft-ietf-tls-tls13-pkcs1-04.txt
 Date: 15/09/2025
 Authors: David Benjamin, Andrei Popov
 Working Group: Transport Layer Security (tls)
 This document allocates code points for the use of RSASSA-PKCS1-v1_5 with client certificates in TLS 1.3. This removes an obstacle for some deployments to migrate to TLS 1.3.
 The SSLKEYLOGFILE Format for TLS
 
 draft-ietf-tls-keylogfile-05.txt
 Date: 09/06/2025
 Authors: Martin Thomson, Yaroslav Rosomakho, Hannes Tschofenig
 Working Group: Transport Layer Security (tls)
 A format that supports logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. This format is intended for use in systems where TLS only protects test data.
 TLS 1.2 is in Feature Freeze
 
 draft-ietf-tls-tls12-frozen-08.txt
 Date: 03/04/2025
 Authors: Rich Salz, Nimrod Aviram
 Working Group: Transport Layer Security (tls)
 Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. This document specifies that outside of urgent security fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.
 TLS Key Share Prediction
 
 draft-ietf-tls-key-share-prediction-03.txt
 Date: 29/08/2025
 Authors: David Benjamin
 Working Group: Transport Layer Security (tls)
 This document defines a mechanism for servers to communicate key share preferences in DNS. Clients may use this information to reduce TLS handshake round-trips.
 Extended Key Update for Transport Layer Security (TLS) 1.3
 
 draft-ietf-tls-extended-key-update-05.txt
 Date: 07/07/2025
 Authors: Hannes Tschofenig, Michael Tuexen, Tirumaleswar Reddy.K, Steffen Fries, Yaroslav Rosomakho
 Working Group: Transport Layer Security (tls)
 TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie- Hellman key exchange during the initial handshake, protecting past communications even if a party's long-term keys are later compromised. While the built-in KeyUpdate mechanism allows traffic keys to be refreshed during a session, it does not introduce new forward-secret key material. This limitation can pose a security risk in long-lived sessions, such as those found in industrial IoT or telecommunications environments. To address this, this specification defines an extended key update mechanism that performs a fresh Diffie-Hellman exchange within an active session, thereby re-establishing forward secrecy beyond the initial handshake. By forcing attackers to exfiltrate new key material repeatedly, this approach mitigates the risks associated with static key compromise. Regular renewal of session keys helps contain the impact of such compromises. The extension is applicable to both TLS 1.3 and DTLS 1.3.
 Large Record Sizes for TLS and DTLS with Reduced Overhead
 
 draft-ietf-tls-super-jumbo-record-limit-01.txt
 Date: 28/05/2025
 Authors: John Mattsson, Hannes Tschofenig, Michael Tuexen
 Working Group: Transport Layer Security (tls)
 TLS 1.3 records limit the inner plaintext (TLSInnerPlaintext) size to 2^14 + 1 bytes, which includes one byte for the content type. Records also have a 3-byte overhead due to the fixed opaque_type and legacy_record_version fields. This document defines a TLS extension that allows endpoints to negotiate a larger maximum inner plaintext size, up to 2^32 - 256 bytes, while reducing overhead.
 TLS Trust Anchor Identifiers
 
 draft-ietf-tls-trust-anchor-ids-02.txt
 Date: 15/09/2025
 Authors: Bob Beck, David Benjamin, Devon O'Brien, Kyle Nekritz
 Working Group: Transport Layer Security (tls)
 This document defines the TLS Trust Anchors extension, a mechanism for relying parties to convey trusted certification authorities. It describes individual certification authorities more succinctly than the TLS Certificate Authorities extension. Additionally, to support TLS clients with many trusted certification authorities, it supports a mode where servers describe their available certification paths and the client selects from them. Servers may describe this during connection setup, or in DNS for lower latency.
 Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
 
 draft-ietf-tls-ecdhe-mlkem-00.txt
 Date: 23/03/2025
 Authors: Kris Kwiatkowski, Panos Kampanakis, Bas Westerbaan, Douglas Stebila
 Working Group: Transport Layer Security (tls)
 This draft defines three hybrid key agreements for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024 which combine a post-quantum KEM with an elliptic curve Diffie-Hellman (ECDHE).
 ML-KEM Post-Quantum Key Agreement for TLS 1.3
 
 draft-ietf-tls-mlkem-04.txt
 Date: 22/07/2025
 Authors: Deirdre Connolly
 Working Group: Transport Layer Security (tls)
 This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as a standalone NamedGroups for use in TLS 1.3 to achieve post-quantum key agreement.
 Use of ML-DSA in TLS 1.3
 
 draft-ietf-tls-mldsa-00.txt
 Date: 16/05/2025
 Authors: Tim Hollebeek, Sophie Schmieg, Bas Westerbaan
 Working Group: Transport Layer Security (tls)
 This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3.
 A Password Authenticated Key Exchange Extension for TLS 1.3
 
 draft-ietf-tls-pake-00.txt
 Date: 04/09/2025
 Authors: Laura Bauman, David Benjamin, Samir Menon, Christopher Wood
 Working Group: Transport Layer Security (tls)
 The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3.

data-group-menu-data-url="/group/groupmenu.json">

Transport Layer Security (tls)

WG Name Transport Layer Security
Acronym tls
Area Security Area (sec)
State Active
Charter charter-ietf-tls-06 Approved
Status update Show Changed 2018-11-07
Document dependencies
Additional resources Github
Home Page
IANA TLS Extension Registry
IANA TLS Parameter Registry
Wiki
Zulip Stream
Personnel Chairs Deirdre Connolly, Joseph A. Salowey, Sean Turner
Area Director Paul Wouters
Mailing list Address tls@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/tls
Archive https://mailarchive.ietf.org/arch/browse/tls/
Chat Room address https://zulip.ietf.org/#narrow/stream/tls

Charter for Working Group

The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5246], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites.

The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion.

The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials and Encrypted SNI. Security and privacy goals will place emphasis on the following:

  • Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation).

  • Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations.

The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items.

The working group will also place a priority in minimizing gratuitous changes to (D)TLS.

Milestones

Date Milestone Associated documents
Jul 2021 Submit "Semi-Static Diffie-Hellman Key Establishment for TLS 1.3" to the IESG draft-ietf-tls-semistatic-dh
Jul 2021 Submit "Compact TLS 1.3" to the IESG draft-rescorla-tls-ctls
Nov 2020 Submit "A Flags Extension for TLS 1.3" to the IESG draft-ietf-tls-tlsflags

Done milestones

Date Milestone Associated documents
Done Submit "Hybrid key exchange in TLS 1.3" to the IESG draft-stebila-tls-hybrid-design
Done Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG draft-ietf-tls-esni
Done Submit "Importing External PSKs for TLS" to the IESG rfc9258 (was draft-ietf-tls-external-psk-importer)
Done Submit "TLS Ticket Requests" to the IESG rfc9149 (was draft-ietf-tls-ticketrequests)
Done Submit "Delegated Credentials for TLS" to the IESG rfc9345 (was draft-ietf-tls-subcerts)
Done Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG rfc9155 (was draft-ietf-tls-md5-sha1-deprecate)