Transport Layer Security (tls) Internet Drafts

      
 TLS Encrypted Client Hello
 
 draft-ietf-tls-esni-22.txt
 Date: 15/09/2024
 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-14.txt
 Date: 13/09/2024
 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-11.txt
 Date: 07/10/2024
 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 all but one of the component algorithms is broken. 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. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design.
 The Transport Layer Security (TLS) Protocol Version 1.3
 
 draft-ietf-tls-rfc8446bis-11.txt
 Date: 14/09/2024
 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-12.txt
 Date: 24/09/2024
 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. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc.
 IANA Registry Updates for TLS and DTLS
 
 draft-ietf-tls-rfc8447bis-10.txt
 Date: 03/11/2024
 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 "Comments" column to all active registries. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, 7301, and 8447.
 Deprecating Obsolete Key Exchange Methods in TLS 1.2
 
 draft-ietf-tls-deprecate-obsolete-kex-05.txt
 Date: 03/09/2024
 Authors: Carrick Bartle, Nimrod Aviram
 Working Group: Transport Layer Security (tls)
 This document deprecates the use of RSA key exchange and Diffie Hellman over a finite field in TLS 1.2, and discourages the use of static elliptic curve Diffie Hellman cipher suites. Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and 1.1 are deprecated by RFC 8996 and TLS 1.3 either does not use the affected algorithm or does not share the relevant configuration options. 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-06.txt
 Date: 01/10/2024
 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. The data can include Encrypted ClientHello (ECH) configurations, allowing the origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Note This note is to be removed before publishing as an RFC. The source for this draft is in https://github.com/sftcd/wkesni/ Issues and PRs are welcome there too.
 Abridged Compression for WebPKI Certificates
 
 draft-ietf-tls-cert-abridge-02.txt
 Date: 16/09/2024
 Authors: Dennis Jackson
 Working Group: Transport Layer Security (tls)
 This draft defines a new TLS Certificate Compression scheme which uses a shared dictionary of root and intermediate WebPKI certificates. The scheme smooths the transition to post-quantum certificates by eliminating the root and intermediate certificates from the TLS certificate chain without impacting trust negotiation. It also delivers better compression than alternative proposals whilst ensuring fair treatment for both CAs and website operators. It may also be useful in other applications which store certificate chains, e.g. Certificate Transparency logs.
 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
 
 draft-ietf-tls-svcb-ech-06.txt
 Date: 21/10/2024
 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 record.
 TLS 1.3 Extension for Using Certificates with an External Pre-Shared Key
 
 draft-ietf-tls-8773bis-02.txt
 Date: 07/07/2024
 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 a combination of a certificate and an external pre-shared key (PSK).
 Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
 
 draft-ietf-tls-tls13-pkcs1-02.txt
 Date: 18/11/2024
 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.
 TLS 1.2 is in Feature Freeze
 
 draft-ietf-tls-tls12-frozen-05.txt
 Date: 20/12/2024
 Authors: Rich Salz, Nimrod Aviram
 Working Group: Transport Layer Security (tls)
 Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. This document specifies that outside of urgent security fixes, 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-01.txt
 Date: 10/09/2024
 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-03.txt
 Date: 21/10/2024
 Authors: Hannes Tschofenig, Michael Tuexen, Tirumaleswar Reddy.K, Steffen Fries, Yaroslav Rosomakho
 Working Group: Transport Layer Security (tls)
 The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy.
 SSLKEYLOGFILE Extension for Encrypted Client Hello (ECH)
 
 draft-ietf-tls-ech-keylogfile-01.txt
 Date: 21/10/2024
 Authors: Yaroslav Rosomakho, Hannes Tschofenig
 Working Group: Transport Layer Security (tls)
 This document specifies an extension to the SSLKEYLOGFILE format to support the logging of information about Encrypted Client Hello (ECH) related secrets. Two new labels are introduced, namely ECH_SECRET and ECH_CONFIG, which log the Hybrid Public Key Encryption (HPKE)- derived shared secret and the ECHConfig used for the ECH, respectively. This extension aims to facilitate debugging of TLS connections employing ECH.
 Large Record Sizes for TLS and DTLS with Reduced Overhead
 
 draft-ietf-tls-super-jumbo-record-limit-00.txt
 Date: 12/11/2024
 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.
 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
 
 draft-rescorla-tls-rfc9147bis-00.txt
 Date: 24/11/2024
 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.
 The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
 
 draft-ietf-tls-rfc9147bis-00.txt
 Date: 14/12/2024
 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.

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
Nov 2021 Submit "Hybrid key exchange in TLS 1.3" to the IESG draft-stebila-tls-hybrid-design
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
Mar 2021 Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG draft-ietf-tls-esni
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 "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)