5. 适用性声明

本文档中的建议主要适用于当今 Internet 上最常与 TLS 和 DTLS 一起使用的应用协议的实现与部署. 示例包括但不限于:

• 希望使用 TLS 保护 HTTP 流量的 Web 软件和服务.

• 希望使用 TLS 保护 IMAP, Post Office Protocol version 3 (POP3) 或 SMTP 流量的电子邮件软件和服务.

• 希望使用 TLS 保护 Extensible Messaging and Presence Protocol (XMPP) 或 Internet Relay Chat (IRC) 流量的即时消息软件和服务.

• 希望使用 DTLS 保护 Secure Realtime Transport Protocol (SRTP) 流量的实时媒体软件和服务.

本文档不修改现有使用 TLS 或 DTLS 的应用协议所规定的实现与部署建议, 例如必须实现的密码套件. 如果使用此类应用协议的社区希望将其 TLS 或 DTLS 用法现代化, 使其与本文推荐的最佳实践保持一致, 则需要显式更新现有应用协议定义. 一个例子是 [RFC7590], 它更新了 [RFC6120].

通过 Internet Standards Process [RFC2026] 开发的新应用协议的设计者, 至少应符合本文推荐的最佳实践, 除非他们提供文档说明有令人信服的理由无法符合这些实践, 例如广泛部署在缺乏必要算法支持的受限设备上.

虽然 QUIC 使用 TLS 1.3 握手协议, 因而本文给出的许多建议也可能适用于 QUIC, 但 QUIC 和其他此类安全传输协议不在本文档范围内. 关于 QUIC, 读者可参见 [RFC9001] 的第 9.2 节.

本文档不讨论 TLS 在受限节点网络 [RFC7228] 中的使用. 对于在电力, 内存和处理资源严重受限的小型设备上裁剪 TLS 和 DTLS 的建议, 读者可参见 [RFC7925] 和 [IOT-PROFILE].

5.1. 安全服务

本文档面向希望使用 TLS 保护通信以实现以下目标的读者提供建议:

机密性 (Confidentiality): 所有应用层通信都经过加密, 目标是除预期接收方外, 任何一方都不应能够解密.

数据完整性 (Data integrity): 接收方能够检测到传输过程中对通信所做的任何更改.

认证 (Authentication): TLS 通信的端点被认证为预期要通信的实体.

关于认证, TLS 支持对通信中的一个端点或两个端点进行认证. 在机会式安全 (opportunistic security) [RFC7435] 的语境下, TLS 有时会在不进行认证的情况下使用. 如第 5.2 节所述, 机会式安全的相关考虑不在本文档范围内.

如果部署者偏离本文档给出的建议, 需要意识到他们可能会失去上述某项安全服务.

本文档仅适用于需要机密性的环境. 它要求使用能够强制保护传输中数据保密性的算法和配置选项.

本文档还假定数据完整性保护始终是部署目标之一. 在不需要完整性的场景中, 一开始就没有使用 TLS 的意义. 有些针对仅提供机密性保护的攻击会利用缺乏完整性这一点, 进而破坏机密性本身. 例如, 可参见 IPsec 语境下的 [DegabrieleP07].

本文档面向 Internet 上最常与 TLS 和 DTLS 一起使用的应用协议. 通常, TLS 客户端和 TLS 服务器之间的所有通信都需要上述三种安全服务. 当 TLS 客户端是 Web 浏览器或电子邮件客户端等用户代理时尤其如此.

本文档不处理较少见的部署场景, 即不希望具备上述三种属性中的某一种, 例如第 5.2 节描述的用例. 另一个不需要机密性的场景是受监控网络: 负责相应流量域的机构要求完全访问未加密的明文流量, 且用户协同配合并以明文发送其流量.

5.2. 机会式安全

在若干重要场景中, TLS 的使用是可选的, 即客户端会动态地 ("机会式地") 决定是与特定服务器使用 TLS, 还是以明文连接. 这种实践通常称为 "机会式安全", [RFC7435] 对其有详细描述, 其动机往往是希望与旧有部署保持向后兼容.

在这些场景中, 本文档中的某些建议可能过于严格, 因为遵循这些建议可能导致回退到明文, 这比使用过时协议版本或密码套件的 TLS 更糟.