rfc9851.original   rfc9851.txt 
Transport Layer Security R. Salz Internet Engineering Task Force (IETF) R. Salz
Internet-Draft Akamai Technologies Request for Comments: 9851 Akamai Technologies
Intended status: Standards Track N. Aviram Category: Standards Track N. Aviram
Expires: 5 October 2025 3 April 2025 ISSN: 2070-1721 January 2026
TLS 1.2 is in Feature Freeze TLS 1.2 is in Feature Freeze
draft-ietf-tls-tls12-frozen-08
Abstract Abstract
Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is
growing. This document specifies that outside of urgent security growing. This document specifies that no changes will be approved
fixes (as determine by TLS WG consensus), new TLS Exporter Labels, or for TLS 1.2 outside of urgent security fixes (as determined by TLS
new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no Working Group consensus), new TLS Exporter Labels, and new
changes will be approved for TLS 1.2. This prescription does not Application-Layer Protocol Negotiation (ALPN) Protocol IDs. This
pertain to DTLS (in any DTLS version); it pertains to TLS only. applies to TLS only; it does not apply to DTLS (in any DTLS version).
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/.
Discussion of this document takes place on the Transport Layer
Security Working Group mailing list (mailto:tls@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe
at https://www.ietf.org/mailman/listinfo/tls/.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/tls12-frozen.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9851.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 October 2025.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Implications for Post-Quantum Cryptography (PQC) . . . . . . 3 2. Implications for Post-Quantum Cryptography (PQC)
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. References
5.1. Normative References . . . . . . . . . . . . . . . . . . 5 5.1. Normative References
5.2. Informative References . . . . . . . . . . . . . . . . . 5 5.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses
1. Introduction 1. Introduction
Use of TLS 1.3 [TLS13] is growing, and it fixes most known TLS 1.3 [TLS13] fixes most known deficiencies with TLS 1.2 [TLS12]
deficiencies with TLS 1.2 [TLS12]. Examples of this include and its use is growing. Some examples of the fixes include
encrypting more of the traffic so that it is not readable by encrypting more of the traffic so that it is not readable by
outsiders and removing most cryptographic primitives now considered outsiders and removing most cryptographic primitives that are now
weak. Importantly, TLS 1.3 enjoys robust security proofs. considered weak. Importantly, TLS 1.3 enjoys robust security proofs.
Both versions have several extension points. Items like new Both versions have several extension points. Items like new
cryptographic algorithms, new supported groups (formerly "named cryptographic algorithms, new supported groups (formerly "named
curves"), etc., can be added without defining a new protocol. This curves"), etc., can be added without defining a new protocol. This
document specifies that outside of urgent security fixes (as document specifies that no changes will be approved for TLS 1.2
determine by TLS WG consensus), and the exceptions listed in outside of urgent security fixes (as determined by TLS Working Group
Section 4, no changes will be approved for TLS 1.2. consensus) and the exceptions listed in Section 4.
This prescription pertains to TLS only. As such, it does not pertain This applies to TLS only. As such, it does not apply to DTLS, in any
to DTLS, in any DTLS version. DTLS version.
2. Implications for Post-Quantum Cryptography (PQC) 2. Implications for Post-Quantum Cryptography (PQC)
Cryptographically relevant quantum computers, once available, are Cryptographically relevant quantum computers, once available, are
likely to greatly lessen the time and effort needed to break RSA, likely to greatly lessen the time and effort needed to break RSA,
finite-field-based Diffie-Hellman (FFDH), or Elliptic Curve finite-field-based Diffie-Hellman (FFDH), or Elliptic Curve
Cryptography (ECC) which are currently used in TLS. In 2016, the US Cryptography (ECC) which are currently used in TLS. In 2016, the US
National Institute of Standards and Technology (NIST) started a National Institute of Standards and Technology (NIST) started a
multi-year effort to standardize algorithms that will be "safe" once multi-year effort to standardize algorithms that will be "safe" once
quantum computers are feasible [PQC]. First discussions in the IETF quantum computers are feasible [PQC]. Initial discussions in the
community happened around the same time [CFRGSLIDES]. IETF community happened around the same time [CFRGSLIDES].
In 2024 NIST released standards for [ML-KEM], [ML-DSA], and In 2024, NIST released standards for [ML-KEM], [ML-DSA], and
[SLH-DSA]. Many other countries and organizations are publishing [SLH-DSA]. Many other countries and organizations are publishing
their roadmaps, including the multi-national standards organization their roadmaps, including the multi-national standards organization
ETSI, [ETSI]. ETSI [ETSI].
While the industry was waiting for NIST to finish standardization, While the industry was waiting for NIST to finish standardization,
the IETF has had several efforts underway. A working group was the IETF has had several efforts underway. A working group was
formed in early 2023 to work on use of Post-Quantum Cryptography formed in early 2023 to work on the use of Post-Quantum Cryptography
(PQC) in IETF protocols [PQUIPWG]. Several other working groups, (PQC) in IETF protocols [PQUIPWG]. Several other working groups,
including TLS [TLSWG], are working on specifications to support including TLS [TLSWG], are working on specifications to support
hybrid algorithms and identifiers, for use during a transition from hybrid algorithms and identifiers, for use during a transition from
classic to a post-quantum world. classic to a post-quantum world.
It is important to note that the focus of efforts within the TLS It is important to note that effort within the TLS Working Group is
Working Group is exclusively TLS 1.3 or later. Put bluntly, PQC for focused exclusively on TLS 1.3 or later. Put bluntly, PQC for TLS
TLS 1.2 will not be specified (see Section 4) at any time and anyone 1.2 will not be specified (see Section 4) at any time; anyone wishing
wishing to deploy PQC should expect to be using TLS 1.3. to deploy PQC should expect to use TLS 1.3.
3. Security Considerations 3. Security Considerations
This entire document is about security, and provides post-quantum This entire document is about security and provides post-quantum
concerns as an additional reason to upgrade to TLS 1.3. security concerns as an additional reason to upgrade to TLS 1.3.
4. IANA Considerations 4. IANA Considerations
No TLS registries [TLS13REG] are being closed by this document. No TLS registries [TLS13REG] are being closed by this document.
Rather, this document modifies the instructions to IANA and the TLS Rather, this document modifies the instructions to IANA and the TLS
Designed Experts to constrain what type of entries can be added to Designated Experts to constrain the type of entries that can be added
existing registries. to existing registries.
This document does not introduce any new limits on the registrations This document does not introduce any new limitations on the
for either of the following two registries: registrations for either of the following two registries:
* TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs * TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs
* TLS Exporter Labels * TLS Exporter Labels
All other TLS registries should have this Note added to them: Any
TLS entry added after the IESG approves publication of {THIS RFC}
is intended for TLS 1.3 or later, and makes no similar requirement
on DTLS. Such entries should have an informal indication like
"For TLS 1.3 or later" in that entry, such as the "Comment"
column.
At the time of publication, the list of other TLS registries is as The following note has been added to the other TLS registries:
follows:
| Any TLS entry added after the IESG approves publication of RFC
| 9851 is intended for TLS 1.3 or later, and makes no similar
| requirement on DTLS. Such entries should have an informal
| indication like "For TLS 1.3 or later" in that entry, such as the
| "Comment" column.
At the time of publication, the note has been added to the following
TLS registries:
* TLS Alerts * TLS Alerts
* TLS Authorization Data Formats * TLS Authorization Data Formats
* TLS CachedInformationType Values * TLS CachedInformationType Values
* TLS Certificate Compression Algorithm IDs * TLS Certificate Compression Algorithm IDs
* TLS Certificate Status Types * TLS Certificate Status Types
skipping to change at page 5, line 4 skipping to change at line 173
* TLS Heartbeat Message Types * TLS Heartbeat Message Types
* TLS Heartbeat Modes * TLS Heartbeat Modes
* TLS KDF Identifiers * TLS KDF Identifiers
* TLS PskKeyExchangeMode * TLS PskKeyExchangeMode
* TLS SignatureAlgorithm * TLS SignatureAlgorithm
* TLS SignatureScheme * TLS SignatureScheme
* TLS Supplemental Data Formats (SupplementalDataType) * TLS Supplemental Data Formats (SupplementalDataType)
* TLS Supported Groups * TLS Supported Groups
* TLS UserMappingType Values * TLS UserMappingType Values
Any TLS registry created after this document is approved for Any TLS registry created after this document is approved for
publication should indicate whether the actions defined here are publication should indicate whether the actions defined here are
applicable. applicable.
5. References 5. References
5.1. Normative References 5.1. Normative References
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/rfc/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft- Version 1.3", RFC 9846, DOI 10.17487/RFC9846, January
ietf-tls-rfc8446bis-12, 17 February 2025, 2026, <https://www.rfc-editor.org/info/rfc9846>.
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-12>.
[TLS13REG] Salowey, J. A. and S. Turner, "IANA Registry Updates for [TLS13REG] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
TLS and DTLS", Work in Progress, Internet-Draft, draft- and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
ietf-tls-rfc8447bis-11, 11 March 2025, <https://www.rfc-editor.org/info/rfc9847>.
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8447bis-11>.
5.2. Informative References 5.2. Informative References
[CFRGSLIDES] [CFRGSLIDES]
McGrew, D., "Post Quantum Secure Cryptography Discussion", McGrew, D., "Post Quantum Secure Cryptography Discussion",
n.d., <https://www.ietf.org/proceedings/95/slides/slides- IETF 95 Proceedings, April 2016,
95-cfrg-4.pdf>. <https://www.ietf.org/proceedings/95/slides/slides-95-
cfrg-4.pdf>.
[ETSI] "CYBER; Migration strategies and recommendations to [ETSI] ETSI, "CYBER; Migration strategies and recommendations to
Quantum Safe schemes", n.d., Quantum Safe schemes", Version 1.1.1, ETSI TR 103 619,
<https://www.etsi.org/deliver/ July 2020, <https://www.etsi.org/deliver/
etsi_tr/103600_103699/103619/01.01.01_60/ etsi_tr/103600_103699/103619/01.01.01_60/
tr_103619v010101p.pdf>. tr_103619v010101p.pdf>.
[ML-DSA] "Module-Lattice-Based Key Digital Signature Standard", [ML-DSA] NIST, "Module-Lattice-Based Digital Signature Standard",
August 2024, <https://csrc.nist.gov/pubs/fips/204/final>. NIST FIPS 204, DOI 10.6028/NIST.FIPS.204, August 2024,
<https://csrc.nist.gov/pubs/fips/204/final>.
[ML-KEM] "Module-Lattice-Based Key-Encapsulation Mechanism [ML-KEM] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", August 2024, Standard", NIST FIPS 203, DOI 10.6028/NIST.FIPS.203,
<https://csrc.nist.gov/pubs/fips/203/final>. August 2024, <https://csrc.nist.gov/pubs/fips/203/final>.
[PQC] "Post-Quantum Cryptography", January 2017, [PQC] NIST, "Post-Quantum Cryptography (PQC)", January 2017,
<https://csrc.nist.gov/projects/post-quantum- <https://csrc.nist.gov/projects/post-quantum-
cryptography>. cryptography>.
[PQUIPWG] "Post-Quantum Use in Protocols", n.d., [PQUIPWG] IETF, "Post-Quantum Use in Protocols",
<https://datatracker.ietf.org/wg/pquip/about/>. <https://datatracker.ietf.org/wg/pquip/about/>.
[SLH-DSA] "Stateless Hash-Based Key-Digital Signature Standard", [SLH-DSA] NIST, "Stateless Hash-Based Digital Signature Standard",
August 2024, <https://csrc.nist.gov/pubs/fips/205/final>. NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, August 2024,
<https://csrc.nist.gov/pubs/fips/205/final>.
[TLSWG] "Transport Layer Security", n.d., [TLSWG] IETF, "Transport Layer Security",
<https://datatracker.ietf.org/wg/tls/about/>. <https://datatracker.ietf.org/wg/tls/about/>.
Acknowledgments Acknowledgments
We gratefully acknowledge Amanda Baber, David Dong, and Sabrina We gratefully acknowledge Amanda Baber, David Dong, and Sabrina
Tanamal of IANA for their help in revising and clarifying Section 4. Tanamal of IANA for their help in revising and clarifying Section 4.
Authors' Addresses Authors' Addresses
Rich Salz Rich Salz
 End of changes. 35 change blocks. 
110 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.48.