]> Akamai Technologies

rsalz@akamai.com

nimrod.aviram@gmail.com

Security Transport Layer Security TLS features TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and fixes some known deficiencies with TLS 1.2, such as removing error-prone cryptographic primitives and encrypting more of the traffic so that it is not readable by outsiders. 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, 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 TLS 1.2 is in widespread use and can be configured such that it provides good security properties. TLS 1.3 is also in widespread use and 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 and provides excellent security as-is. 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, 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 . While the industry is waiting for NIST to finish standardization, the IETF has 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. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process. This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. 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.

Acknowledgments None yet.