| rfc9851v1.txt | rfc9851.txt | |||
|---|---|---|---|---|
| skipping to change at line 12 ¶ | skipping to change at line 12 ¶ | |||
| Internet Engineering Task Force (IETF) R. Salz | Internet Engineering Task Force (IETF) R. Salz | |||
| Request for Comments: 9851 Akamai Technologies | Request for Comments: 9851 Akamai Technologies | |||
| Category: Standards Track N. Aviram | Category: Standards Track N. Aviram | |||
| ISSN: 2070-1721 January 2026 | ISSN: 2070-1721 January 2026 | |||
| TLS 1.2 is in Feature Freeze | TLS 1.2 is in Feature Freeze | |||
| 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 determined by TLS Working Group consensus), new TLS | for TLS 1.2 outside of urgent security fixes (as determined by TLS | |||
| Exporter Labels, and new Application-Layer Protocol Negotiation | Working Group consensus), new TLS Exporter Labels, and new | |||
| (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. This | Application-Layer Protocol Negotiation (ALPN) Protocol IDs. This | |||
| prescription pertains to TLS only; it does not pertain to DTLS (in | applies to TLS only; it does not apply to DTLS (in any DTLS version). | |||
| any DTLS version). | ||||
| Status of This Memo | Status of This Memo | |||
| This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
| This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
| (IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
| received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
| Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
| skipping to change at line 71 ¶ | skipping to change at line 70 ¶ | |||
| TLS 1.3 [TLS13] fixes most known deficiencies with TLS 1.2 [TLS12] | TLS 1.3 [TLS13] fixes most known deficiencies with TLS 1.2 [TLS12] | |||
| and its use is growing. Some examples of the fixes 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 that are now | outsiders and removing most cryptographic primitives that are now | |||
| considered 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 | |||
| determined by TLS Working Group consensus) and the exceptions listed | outside of urgent security fixes (as determined by TLS Working Group | |||
| in 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]. Initial discussions in the | quantum computers are feasible [PQC]. Initial discussions in the | |||
| End of changes. 3 change blocks. | ||||
| 11 lines changed or deleted | 10 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||