Transport Layer Security (tls) Internet Drafts

      
 A Flags Extension for TLS 1.3
 
 draft-ietf-tls-tlsflags-18.txt
 Date: 10/09/2026
 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.
 A well-known URI for publishing service parameters
 
 draft-ietf-tls-wkech-12.txt
 Date: 03/05/2026
 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 HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP 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.
 TLS Key Share Prediction
 
 draft-ietf-tls-key-share-prediction-04.txt
 Date: 19/03/2026
 Authors: David Benjamin
 Working Group: Transport Layer Security (tls)
 This document defines a mechanism for servers to communicate supported key share algorithms 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-13.txt
 Date: 04/07/2026
 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 (typically a private key with a corresponding certificate) are later compromised. While the built-in KeyUpdate mechanism allows application traffic keys to be refreshed during a session, it does not incorporate fresh entropy from a new key exchange and therefore does not provide post- compromise security. 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 execution of the key exchange negotiated during the initial handshake within an active session, thereby ensuring post-compromise security. 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-03.txt
 Date: 07/04/2026
 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. DTLS 1.3 uses the same plaintext size limit. This document defines a TLS extension that allows endpoints to advertise larger per-direction maximum inner plaintext sizes, up to 2^30 - 256 bytes, while reducing overhead in TLS 1.3 and DTLS 1.3 record headers.
 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
 
 draft-ietf-tls-rfc9147bis-02.txt
 Date: 06/07/2026
 Authors: Eric Rescorla, Hannes Tschofenig, Nagendra Modadugu
 Working Group: Transport Layer Security (tls)
 This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347.
 TLS Trust Anchor Identifiers
 
 draft-ietf-tls-trust-anchor-ids-05.txt
 Date: 14/09/2026
 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 a TLS client or server to select a certificate to present based on the peer's trusted certification authorities. It describes certification authorities more succinctly than the TLS Certificate Authorities extension.
 ML-KEM Post-Quantum Key Agreement for TLS 1.3
 
 draft-ietf-tls-mlkem-11.txt
 Date: 16/09/2026
 Authors: Deirdre Connolly
 Working Group: Transport Layer Security (tls)
 This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment.
 Use of ML-DSA in TLS 1.3
 
 draft-ietf-tls-mldsa-06.txt
 Date: 11/09/2026
 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-02.txt
 Date: 06/07/2026
 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 Deb Cooley
Mailing list Address [email protected]
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 rfc9849 (was 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)