]> Akamai Technologies

rsalz@akamai.com

nimrod.aviram@gmail.com

Security Transport Layer Security TLS features 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 new features will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only. About This Document Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Use of TLS 1.3 is growing, and it fixes most known deficiencies with TLS 1.2 , such as encrypting more of the traffic so that it is not readable by outsiders and removing most cryptographic primitives now considered weak. Importantly, TLS 1.3 enjoys robust security proofs. Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, and the exceptions listed in , no new features will be approved for TLS 1.2. This prescription does not pertain to DTLS (in any DTLS version); it pertains to TLS only.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Implications for post-quantum cryptography Cryptographically relevant quantum computers, once available, will have a huge impact on RSA, FFDH, and ECC which are currently used in TLS. In 2016, the US National Institute of Standards and Technology started a multi-year effort to standardize algorithms that will be "safe" once quantum computers are feasible . First IETF discussions happened around the same time . In 2024 NIST released standards for , , and . While industry was waiting for NIST to finish standardization, the IETF has had several efforts underway. A working group was formed in early 2023 to work on use of PQC in IETF protocols, . Several other working groups, including TLS , are working on drafts to support hybrid algorithms and identifiers, for use during a transition from classic to a post-quantum world. For TLS it is important to note that the focus of these efforts is TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2 WILL NOT be supported (see ).

IANA Considerations IANA will stop accepting registrations for any TLS parameters except for the following:

• TLS Exporter Labels
• TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs

Entries in any other TLS protocol registry should have an indication like "For TLS 1.3 or later" in their entry.

References Normative References This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] 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 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. Venafi sn3rd 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References n.d. n.d. n.d.