| RFC 9852 | 使用 TLS 的新协议必须要求使用 TLS | 2026年7月 |
| Salz & Aviram | 当前最佳实践 | [页] |
TLS 1.3 已得到广泛使用，经过了全面的安全性证明，并且 改善了 TLS 1.2 在安全性和隐私方面的缺陷。因此，使用 TLS 的新协议 必须要求使用 TLS 1.3。由于 DTLS 1.3 尚未广泛可用或 部署，因此本规定不适用于 DTLS（任何 DTLS 版本）； 它仅适用于 TLS。¶
本文档更新了 RFC 9325。文中讨论了后量子密码学以及 TLS 1.3 在安全性和隐私方面的改进，以此作为此次更新的理由。¶
本备忘录记录了一项互联网当前最佳实践。¶
本文档是互联网工程任务组 （IETF）的产物。它代表了 IETF 社区的共识。本文档已经 过公开评审，并经互联网工程指导组 （IESG）批准发布。有关 BCP 的更多信息 请参阅 RFC 7841 第 2 节。¶
有关本文档的当前状态、任何 勘误以及如何提供反馈的信息，可从 https://www.rfc-editor.org/info/rfc9852获取。¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
本文档规定，使用 TLS 的新协议 必须假定 TLS 1.3 可用并要求使用它。 由于 DTLS 1.3 尚未广泛可用或 部署，因此本规定不适用于 DTLS（任何 DTLS 版本）； 它仅适用于 TLS。¶
TLS 1.3 [TLS13] 已得到广泛 使用，并修复了 TLS 1.2 的大多数已知缺陷。其示例包括加密更多流量，使其 无法被外部人员读取，以及移除目前被认为较弱的大多数密码学原语。 重要的是，该协议已经过全面的 安全性证明，并且无需任何额外 配置即可提供出色的安全性。¶
TLS 1.2 [TLS12] 仍在使用，并且可以 配置为提供良好的 安全属性。但是，如第 6 节所述， TLS 1.2 存在若干缺陷。解决这些缺陷 通常需要 专门配置。¶
本文档更新了 [RFC9325]。 文中讨论了后量子密码学 以及 TLS 1.3 在安全性和隐私方面的改进，以此作为此次更新的理由。请参阅第 5 节。¶
本文档中的关键词“必须”、“不得”、“必需”、“须”、“不得”、 “应该”、“不应该”、“建议”、“不建议”、 “可以”和“可选”，仅当它们以如此处所示的 全部大写形式出现时，才应按照 BCP 14 [RFC2119] [RFC8174] 中的说明进行解释。¶
一旦密码学相关量子计算机（CRQC）可用， 它们将对 TLS 流量产生巨大影响（例如，参见 [RFC9958] 的第 3 节）。 为了减轻这种影响，TLS 应用将 需要迁移到后量子密码学（PQC）[PQC]。关于 应用何时需要 PQC，或者 CRQC 何时会成为 应用需要防范的威胁等详细考量，超出了本文档的 范围。¶
需要特别指出的是， TLS 工作组正将工作重点放在 TLS 1.3 或更高版本上；TLS 1.2 将不再得到支持（参见 [TLS12FROZEN]）。 这也是新协议要求 TLS 默认使用 TLS 1.3 的另一个原因， 因为 PQC 正在该版本中积极进行标准化，这使新应用 可以选择使用 PQC。¶
任何使用 TLS 的新协议都必须将 TLS 1.3 指定为其 默认版本。 例如，QUIC [QUICTLS] 要求使用 TLS 1.3，并 规定，如果使用了较旧版本，端点 必须终止连接。¶
如果需要考虑部署问题，协议可以 将 TLS 1.2 指定为 一个额外的非默认选项。 作为反例，基于 TLS 的 DNS 使用配置文件 [DNSTLS] 将 TLS 1.2 指定为默认版本，同时也允许使用 TLS 1.3。 对于选择支持 TLS 1.2 的较新规范，这些优先级 应当反过来。¶
初始 TLS 握手允许客户端指定其支持的 TLS 版本，而服务器应选择其同样支持的最高 版本。这称为“TLS 版本 协商”；协议和协商细节在 [TLS13] 的第 4.2.1 节 和 [TLS12] 的附录 E中讨论。 许多 TLS 库都提供一种方式， 让应用指定其所需的版本范围，包括 仅指定最低版本或最高版本的开放区间。¶
如果应用使用的是支持 TLS 版本协商的 TLS 实现， 并且它知道该 TLS 实现将使用所支持的最高版本， 那么 客户端应该仅指定其所需的最低版本。 根据上述段落所述的具体情况，该版本必须为 TLS 1.3 或 TLS 1.2。¶
[RFC9325] 提供了相关建议， 用于确保已部署的 TLS 服务以及与本文档不同的 DTLS 服务的安全性。 [RFC9325] 将 TLS 1.3 描述为“广泛可用”，并且自该文档发布以来，向 TLS 1.3 的迁移程度进一步提高。 因此，本文档对 [RFC9325] 的第 3.1.1 节中的建议作出两项更改：¶
该节指出，TLS 1.3 应该得到 支持；本文档规定， 对于使用 TLS 的新协议，TLS 1.3 必须得到支持。¶
该节指出，TLS 1.2 必须得到支持； 本文档则指出， 可以按照上述说明支持 TLS 1.2。¶
再次强调，这些更改仅适用于 TLS，而不适用于 DTLS。¶
TLS 1.2 规定了若干密码学原语和设计选择， 而随着时间推移，它们已经显著变弱。本节旨在 简要概述影响该协议的若干突出问题。 但应当指出，TLS 1.2 可以安全地进行配置； 只是与使用其现代后继版本 TLS 1.3 相比， 安全配置 TLS 1.2 要困难得多。有关 安全部署 TLS 1.2 的 更全面指南，请参阅 [RFC9325]。¶
首先，在不使用任何扩展的情况下，TLS 1.2 容易受到 重新协商攻击（参见 [RENEG1] 和 [RENEG2]）以及 三重握手攻击（参见 [TRIPLESHAKE]）。 概括而言，这些攻击 利用协议对重新协商的支持，将攻击者 选择的前缀注入明文流。实际上，这通常是一种破坏性极强的 威胁（例如，它允许攻击者在 Web 环境中获取机密 Cookie）。 鉴于 上述问题，[RFC5746] 规定了一种 防止此类攻击的扩展。为了安全地部署 TLS 1.2，必须 完全禁用重新协商，或者必须使用此扩展。此外，客户端 不得允许服务器在连接期间重新协商证书。¶
其次，最初为 TLS 1.2 规定的密钥交换方法，即 RSA 密钥交换和有限域 Diffie-Hellman，存在若干 弱点。为了安全地部署该协议， 必须禁用其中 大多数密钥交换方法。 有关详细信息，请参阅 [RFC10015]。¶
第三，TLS 1.2 中广泛使用的对称密码，即 RC4 和密码分组链接（CBC）密码套件，存在若干弱点。RC4 的 密钥流中存在可利用的偏差；请参阅 [RFC7465]。多年来，CBC 密码套件一直是 漏洞的来源。这些密码套件的直接 实现本质上容易受到 Lucky13 计时 攻击 [LUCKY13]。首次尝试以 常量时间实现这些密码套件时， 引入了一个更加严重的漏洞 [LUCKY13FIX]。 有关 CBC 密码套件漏洞的另一个示例以及类似研究的概述， 请参阅 [CBCSCANNING]。¶
此外，TLS 1.2 还受到其他若干攻击的影响， 而 TLS 1.3 不受这些攻击影响： BEAST [BEAST]、Logjam [WEAKDH]、FREAK [FREAK] 和 SLOTH [SLOTH]。¶
最后，尽管 TLS 1.2 中的应用层流量始终经过加密，但握手 消息的大部分内容并未加密。因此，其提供的隐私保护并不理想。 这是一个无法通过配置解决的协议问题。¶