非官方中文译本声明：本页为 IETF RFC 7672《SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7672。

RFC 7672：通过 TLS 的 SMTP 安全（SMTP Security via TLS）

V. Dukhovni（Two Sigma）、W. Hardaker（Parsons）· 2015 年 10 月 · 类别：Standards Track（标准跟踪）· ISSN: 2070-1721

摘要

本备忘录描述了一种用于邮件传输代理（MTA）之间 SMTP 传输安全的抗降级协议，该协议基于"基于 DNS 的命名实体认证"（DANE）TLSA DNS 记录。采用本协议能够推动 Internet 电子邮件骨干网逐步过渡到使用加密且经过认证的传输层安全（TLS）。

本备忘录的状态

本文档是一份 Internet 标准跟踪（Standards Track）文档。

本文档是互联网工程任务组（IETF）的产物。它代表了 IETF 社区的共识。它已经过公开评审，并由互联网工程指导组（IESG）批准发布。有关 Internet 标准的更多信息，参见 RFC 5741 第 2 节。

关于本文档当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc7672 获取。

Copyright (c) 2015 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。从本文档中提取的代码组件必须包含《信托法律规定》第 4.e 节所述的简化 BSD 许可文本，并按该简化 BSD 许可的描述在不提供担保的情况下提供。

目录

1. 引言

本备忘录为邮件传输代理（MTA）规定了一种新的连接安全模型。该模型由域间 SMTP 投递的关键特征所驱动，主要是：目标服务器是通过 DNS 邮件交换（MX）记录间接选定的，并且电子邮件地址和 MX 主机名都不表示需要安全传输或明文传输。因此，除了少数手动配置的例外，SMTP 传输安全必然是机会性的（关于"机会性安全"的定义，见 [RFC7435]）。

本规范利用 DANE TLSA 记录的存在来安全地通告对 TLS 的支持，并发布 SMTP 客户端据以成功认证合法 SMTP 服务器的方式。这即成为"机会性 DANE TLS"，并且能抵御降级攻击与中间人（MITM）攻击。它使得电子邮件骨干网能够逐步过渡到经过认证的 TLS 投递，并且随着采用范围的扩大而获得更强的全局保护。

在采用机会性 DANE TLS 时，从 SMTP 客户端发往那些按照本备忘录发布"可用"DANE TLSA 记录的域的流量会被认证并加密。来自遗留客户端或发往未发布 TLSA 记录的域的流量，将继续以与从前相同的方式发送，即通过手动配置的安全、（前 DANE 的）机会性 TLS，或者仅仅是明文 SMTP。

现有 MTA 到 MTA 的 SMTP 中 TLS 使用方式所存在的问题，正是制定本规范的动机，这些问题在 1.3 节中描述。规范本身紧随其后，在 2、3 两节中分别描述如何为 SMTP 定位并使用 DANE TLSA 记录。在第 6 节，我们讨论将 DANE TLS 应用于那些信道完整性与机密性为强制要求的目的地。在第 7 节，我们简要评述本规范对邮件用户代理（MUA）潜在的可适用性。

1.1. 术语

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"NOT RECOMMENDED（不建议）"、"MAY（可以）"和"OPTIONAL（可选）"应按照 [RFC2119] 中的描述进行解释。

本文档通篇使用以下术语或概念：

中间人（MITM）攻击（Man-in-the-middle attack）： 由能够据此破坏数据保密性或完整性的攻击者主动修改网络流量。

降级攻击（Downgrade attack）： （出自 [RFC4949]。）一类 MITM 攻击，攻击者能够使得双方在协商安全关联时，达成比双方本都可支持的最高保护级别更低的保护级别。

抗降级（Downgrade-resistant）： 如果某协议采用有效的对策来抵御降级攻击，则该协议是"抗降级的"。

"Secure（安全）"、"bogus（伪造）"、"insecure（不安全）"、"indeterminate（不确定）： DNSSEC 验证结果，定义见 [RFC4035] 第 4.3 节。

可验证的安全感知存根解析器与不可验证的安全感知存根解析器： 所用存根解析器的能力，定义见 [RFC4033]；注意本规范要求使用一个安全感知的存根解析器。

（前 DANE 的）机会性 TLS（(Pre-DANE) opportunistic TLS）： 对 TLS 尽最大努力的使用，通常易受 DNS 伪造与 STARTTLS 降级攻击。当 TLS 加密信道不可用时，报文以明文传输。即便 TLS 可用，MX 记录的间接寻址通常也排除了认证的可能。

机会性 DANE TLS（Opportunistic DANE TLS）： 对 TLS 尽最大努力的使用，对于拥有经 DNSSEC 验证的 TLSA 记录的目的地而言，能够抵御降级攻击。当确定机会性 DANE TLS 不可用时，客户端应当回退到前 DANE 的机会性 TLS。机会性 DANE TLS 在客户端要求支持 DNSSEC、DANE 与 STARTTLS，在服务器端要求支持 STARTTLS 以及发布一条经 DNSSEC 的 TLSA 记录。

引用标识符（Reference identifier）： （[RFC6125] 定义的特例。）SMTP 客户端为对服务器证书执行名称检查而与该目的 SMTP 服务器相关联的域名之一。当名称检查适用时，至少一个引用标识符必须与服务器证书的某个 [RFC6125] DNS-ID（或者，若不存在，则 [RFC6125] CN-ID）相匹配（见 3.2.3 节）。

MX 主机名（MX hostname）： MX 记录的 RRDATA 由一个 16 位的优先级后跟一个邮件交换域名组成（见 [RFC1035] 第 3.3.9 节）。我们将使用术语"MX 主机名"来指代后者，即 MX 记录中优先级值之后找到的 DNS 域名。因此，"MX 主机名"特指引用一个 DNS 域名，而非承载该名称的任何主机。

延迟投递（Delayed delivery）： 电子邮件投递是一个多跳存储转发过程。当某个 MTA 无法转发一封之后可能变得可投递的邮件时，该邮件被排入队列并定期重试投递。某些 MTA 可能被配置一个备选下一跳目的地，用于处理那些原本会被排队并重试的邮件。当配置了备选下一跳目的地时，原本不得不延迟的邮件可能会被改发往该备选下一跳目的地。该备选目的地本身也可能像原始邮件目的地一样，受到机会性或强制 DANE TLS 的约束（见第 6 节）。

原始下一跳目的地（Original next-hop destination）： 邮件投递的逻辑目的地。默认情况下，它是收件人地址的域部分，但 MTA 可能被配置为经由指定的中继为部分或所有收件人转发邮件。原始下一跳目的地相应地要么是收件人域，要么是对应的已配置中继。

MTA： 邮件传输代理（[RFC5598] 第 4.3.2 节）。

MSA： 邮件提交代理（[RFC5598] 第 4.3.1 节）。

MUA： 邮件用户代理（[RFC5598] 第 4.2.1 节）。

RR： 一条 DNS 资源记录，定义见 [RFC1034] 第 3.6 节。

RRset： 一个 RRset（[RFC2181] 第 5 节）是一组共享相同标签、类别与类型的 DNS 资源记录。

1.2. 背景

域名系统安全扩展（DNSSEC）为域名系统（DNS）增加了数据源认证、数据完整性与数据不存在证明。DNSSEC 定义于 [RFC4033]、[RFC4034] 与 [RFC4035]。

正如 [RFC6698] 引言中所描述，通过现有公共证书颁发机构（CA）PKI 进行的 TLS 认证，苦于存在过多能够为其自选的任何域颁发证书的受信方。DANE 利用 DNSSEC 基础设施，借助"TLSA"DNS 记录类型发布用于传输层安全（TLS）[RFC5246] 协议的公钥与证书。借助 DNSSEC，每个域只能为其被授权的子域担保密钥。

TLS 协议实现安全的 TCP 通信。在本备忘录的语境下，假定信道安全由 TLS 提供。TLS 在未伴随认证使用时，仅提供针对窃听攻击的隐私保护。否则，TLS 还提供数据源认证以抵御 MITM 攻击。

1.3. SMTP 信道安全

在 HTTPS 中，TLS 使用随流行 Web 浏览器一同捆绑的众多 CA 之一所颁发的 X.509 证书 [RFC5280]，以允许用户认证其"安全"网站。在为本规范规定一个新的 SMTP DANE TLS 安全模型之前，我们将解释为何需要一个新的安全模型。在此过程中，我们将解释为何人们熟悉的 HTTPS 安全模型不足以保护域间 SMTP 流量。

下文的小节概述了将传统 Web PKI [RFC7435] 应用于 SMTP 时的四个关键问题；本规范正是针对这些问题而制定。由于 SMTP 信道安全策略既未在收件人地址中显式指定，也未在 MX 记录中指定，因此需要一个全新的信令机制来指示何时信道安全是可行的且应当被使用。发布 TLSA 记录使得服务器运营者能够安全地向 SMTP 客户端通告 TLS 可用且应当被使用。DANE TLSA 使得同时发现哪些目的域支持经由 TLS 的安全投递、以及如何验证相关 SMTP 服务的真实性成为可能，从而为无处不在的 SMTP 信道安全指明了一条前进道路。

1.3.1. STARTTLS 降级攻击

SMTP [RFC5321] 是多跳存储转发电子邮件投递过程中的一个单跳协议。一个 SMTP 信封收件人地址并不对应于某个特定的传输层端点地址；相反，在每一跳中继处，传输层端点都是下一跳中继，而信封收件人地址通常保持不变。不同于 HTTP 及其对应的安全版本 HTTPS（其中 TLS 的使用由 URI 方案来信令），电子邮件收件人地址并不直接信令传输安全策略。事实上，没有任何此类信令能与 SMTP 良好配合，因为 SMTP 的 TLS 加密是以逐跳方式保护电子邮件流量，而电子邮件地址只能表达端到端策略。

由于没有任何可用的机制来信令传输安全策略，SMTP 中继对 TLS 采用一种尽最大努力的"机会性"安全模型。一个单一的 SMTP 服务器 TCP 监听端点可以同时满足 TLS 客户端与非 TLS 客户端；TLS 的使用通过 SMTP STARTTLS 命令 [RFC3207] 协商。服务器通过明文 SMTP 连接向客户端通告对 TLS 的支持，而如果客户端也支持 TLS，它就可以协商一条用于电子邮件传输的 TLS 加密信道。服务器对 TLS 支持的通告很容易被 MITM 攻击者抑制。因此，前 DANE 的 SMTP TLS 安全可以通过简单地将连接降级为明文而被颠覆。没有任何 TLS 安全特性能够阻止这一点。攻击者可以简单地禁用 TLS。

1.3.2. 缺乏 DNSSEC 的不安全服务器名

在 SMTP 中，DNS MX 记录抽象出下一跳传输端点，并允许管理员为给定域指定一组应当将 SMTP 流量定向至的目标服务器。

除非 TLS 客户端验证服务器的证书将公钥绑定到一个与客户端某个引用标识符相匹配的名称，否则它易受 MITM 攻击。一个自然的引用标识符选择是服务器的域名。然而在 SMTP 中，服务器名并不直接编码在收件人地址中；相反，它们是经由 MX 记录间接获得的。在没有 DNSSEC 的情况下，MX 查找易受 MITM 与 DNS 缓存投毒攻击。主动攻击者可以用伪造的 MX 记录伪造 DNS 应答，并将电子邮件重定向到其所选名称的服务器。因此，在没有 DNSSEC 的情况下，安全验证与服务器名匹配的 SMTP TLS 证书是不可能的。

有人可能试图通过将信封收件人域用作引用标识符，并要求每个 SMTP 服务器都持有一张针对信封收件人域而非 MX 主机名的受信证书，从而使 SMTP 的 TLS 抵御 DNS 攻击。遗憾的是，这是不切实际的，因为许多域的邮件由第三方处理，而这些第三方并不处于能够获取它们所服务的所有域的证书的位置。部署服务器名称指示（SNI）TLS 扩展（见 [RFC6066] 第 3 节）并非万灵药，因为除电子邮件服务提供商同时也是该域的注册商及其证书颁发者的情况外，SNI 的密钥管理在运维上充满挑战；而对于电子邮件而言，这种情况很少见。

既然收件人域名不能被用作 SMTP 服务器的引用标识符，而 MX 主机名在没有 DNSSEC 的情况下也不能，那么在大规模上部署经认证的 SMTP TLS 就要求 DNS 是安全的。

由于 SMTP 安全关键性地依赖于 DNSSEC，必须指出，也因此采用 DANE 的 SMTP 是尽可能保守的信任模型。它只信任必须信任的，绝不多信任。向其中加入任何其他受信参与者只会降低 SMTP 的安全性。发送方可以选择通过为选定的高价值接收域配置显式信任锚，而非依赖来自根域的信任链，来进一步强化这些域的 DNSSEC。然而，关于 DNSSEC 安全实践的详细讨论超出了本文档的范围。

1.3.3. 发送方策略无法扩展

在某些情况下，发送系统被显式配置为对发往选定对等域的邮件使用 TLS，但这要求为发送 MTA 配置来自其对等域的适当主体名或证书内容摘要。由于由此带来的管理负担，此类静态配置的 SMTP 安全信道很少被使用（一般仅存在于与其业务伙伴达成双边安排的域之间）。另一方面，Internet 电子邮件需要定期联系新的域，而针对这些域的安全配置无法预先建立。

经由 DNS MX 记录（往往跨越组织边界）对 SMTP 传输端点的抽象，将公共 CA PKI 与 SMTP 结合使用的范围限制在一小组由发送方配置的对等域。由于几乎没有机会使用 TLS 认证，发送 MTA 很少被配置一份全面的受信 CA 列表。支持 STARTTLS 的 SMTP 服务常常部署自签名或由私有 CA 颁发的 X.509 证书。

1.3.4. 过多的证书颁发机构

即便通常能够确定一个安全的服务器名，SMTP 客户端仍然需要验证服务器的证书链是由某个受信 CA（一个信任锚）颁发的。MTA 并非交互式应用，在没有用户能够（明智地或欠考虑地）在证书链验证失败时选择性地禁用 TLS 安全策略。由于没有用户来"点击确定"，MTA 的公有 CA 信任锚列表必须是全面的，以避免弹回那些使用未知 CA 的站点的邮件。

另一方面，每一个受信 CA 都能为任何域颁发证书。即便已配置的 CA 中有一个被攻破或由对手运作，它也能破坏所有目的地的 TLS 安全。任何一组 CA 同时既是过于包容的、又是不够包容的。

2. 确定适用的 TLSA 记录

2.1. DNS 考量

2.1.1. DNS 错误、"Bogus（伪造）"响应与"Indeterminate（不确定）"响应

按照本规范实现机会性 DANE TLS 的 SMTP 客户端，关键性地依赖于 DNSSEC 查找的完整性，正如 1.3.2 节所讨论的。本节列出了在使用机会性 DANE TLS 时避免降级攻击所需的 DNS 解析器要求。

一次 DNS 查找可能发出错误信号，或返回一个确定的应答。本规范必须使用一个安全感知的解析器。安全感知解析器将用 [RFC4035] 第 4.3 节定义的四种可能值之一来指示一个 DNS RRset 的安全状态："secure（安全）"、"insecure（不安全）"、"bogus（伪造）"和"indeterminate（不确定）"。在 [RFC4035] 中，"indeterminate"安全状态的含义是：

一个 RRset，解析器无法确定该 RRset 是否应当被签名，因为解析器无法获得必要的 DNSSEC RR。这可能发生在安全感知解析器无法联系到相关区的安全感知名称服务器时。

注意，"indeterminate"安全状态在 [RFC4033] 第 5 节有一个相互冲突的定义：

不存在会指示树的某个特定部分是安全的信任锚。

在本文档中，术语"indeterminate"将专以 [RFC4035] 的意义使用。因此，获得"indeterminate"查找结果是一种（暂时的）失败状况，即无法定位相关的 DNS 记录。在 [RFC4035] 意义上会被归类为"indeterminate"的 DNS 记录，被简单地归类为"insecure"。

我们不需要区分那些缺少合适祖先信任锚的区，与（最终）来自某个信任锚、并将某个子区指定为"insecure"的委派。所有"insecure"RRset 都必须以相同方式处理：无论哪种情况，查询域的未经验证的数据都是且只能是可得的，并且使用该数据进行认证是不可能的。由于 DNS 根区已经签名，我们预期面向 Internet 的 MTA 所使用的验证解析器会配置根区的信任锚数据，因此，在大多数部署中不可能存在没有祖先信任锚的域。

如 [RFC4035] 第 4.3 节所述，一个安全感知的 DNS 解析器必须能够确定给定的非错误 DNS 应答是"secure"、"insecure"、"bogus"还是"indeterminate"。预期大多数安全感知存根解析器不会向应用发出"indeterminate"安全状态信号（以 [RFC4035] 的意义），而会改为发出"bogus"或错误结果。如果一个解析器确实发出了 [RFC4035] 的"indeterminate"安全状态信号，SMTP 客户端必须将其视为仿佛返回了一个"bogus"或错误结果。

使用不可验证的安全感知存根解析器的 MTA，可以使用该存根解析器的能力（若可用）来基于其从上游验证递归解析器学到的信息发出 DNSSEC 验证状态信号。安全盲存根解析器 [RFC4033] 不得被使用。依据 [RFC4035] 第 4.9.3 节：

……一个安全感知存根解析器不得信赖据称代表它执行的签名验证，除非该安全感知存根解析器是经由一个安全信道从某个受信的安全感知递归名称服务器获得所涉数据的。

为避免下文过多重复，我们先在此解释对"bogus"或"indeterminate"DNSSEC 查询响应的处理。这些响应未必是恶意行为者的结果；例如，它们可能发生在网络分组在传输中被损坏或丢失时。因此，在本备忘录中，"bogus"或"indeterminate"应答等同于查找失败。

除了 DNS 客户端获得所请求类型的非空"secure"或"insecure"RRset 这一明显情况外，我们还需要强调一个重要的非失败状况。即，当为所请求的数据确定了"secure"或"insecure"的不存在性时，这并非错误。当验证状态为"secure"或"insecure"的 DNSSEC 应答报告没有所请求类型的记录、或查询域不存在时，该应答并非 DNS 错误状况。DNS 客户端并非没有得到答案；它已经得知所请求类型的记录不存在。

当然，安全感知存根解析器也会在其他情况下发出 DNS 查找错误信号，例如，在处理"SERVFAIL"[RFC2136] 响应码（RCODE）[RFC1035] 时，该响应码不会有相关联的 DNSSEC 状态。本规范对所有查找错误都以相同方式处理，无论它们来自"bogus"或"indeterminate"的 DNSSEC 状态，还是来自更一般的 DNS 错误：此时安全感知解析器无法获得所请求的信息。因此，查找错误要么是未能获得相关的 RRset（当该 RRset 存在时），要么是在该 RRset 不存在时未能确定其不存在。

与"bogus"响应或"indeterminate"响应相反，"insecure"的 DNSSEC 响应并非错误；相反，如上所述，它指示目标 DNS 区要么被委派为某个"secure"父区的一个"insecure"子区，要么不是 SMTP 客户端所使用的任何已配置 DNSSEC 信任锚的后代。"Insecure"结果会使 SMTP 客户端处于降级的信道安全，但不会阻碍邮件投递。详见 2.2 节。

2.1.2. DNS 错误处理

当一次 DNS 查找失败（如上定义的错误、"bogus"或"indeterminate"）阻止 SMTP 客户端确定它应当连接到的 SMTP 服务器时，邮件投递必须被延迟。这自然包括例如这样的情况：在 MX 解析过程中遇到了"bogus"或"indeterminate"响应。当从一次成功的 MX 查找获得了多个 MX 主机名，但后续的一次 DNS 查找失败阻止了对给定 MX 主机名的网络地址解析时，投递可以经由任何其余的 MX 主机继续进行。

当一个特定的 SMTP 服务器被安全地识别为投递目的地时，必须执行一组 DNS 查找（2.2 节）以定位任何相关的 TLSA 记录。如果用于定位 TLSA 记录的任何 DNS 查询失败（由于"bogus"或"indeterminate"记录、超时、畸形应答、SERVFAIL 响应等），那么 SMTP 客户端必须将该服务器视为不可达，并且不得经由该服务器投递邮件。如果没有任何服务器可达，则投递被延迟。

在下文的叙述中，我们将只描述当所有相关 DNS 查询都成功时发生的情况。如果发生了任何 DNS 失败，SMTP 客户端必须按照本节所述的行为，通过"跳过"有问题的 SMTP 服务器或目的地来处理。对候选 TLSA 记录的查询明确地属于"所有相关 DNS 查询"的一部分，并且 SMTP 客户端不得继续连接到一个其 TLSA 记录查找失败的 SMTP 服务器或目的地。

2.1.3. 存根解析器考量

关于 DNAME 别名的一点说明：对一个祖先域是 DNAME 别名的域名进行查询，会返回该祖先域的 DNAME RR，以及一条将该查询域名映射到该 DNAME 别名目标域对应子域的 CNAME [RFC6672]。因此，每当我们提及 CNAME 别名时，我们都隐式允许所涉别名是某个祖先域 DNAME 记录结果的可能性。因此，SMTP 软件中不需要对 DNAME 记录的显式支持；处理所产生的 CNAME 别名就足够了。DNAME 记录只需要在校验组合 DNAME + CNAME 应答完整性的验证存根解析器库中进行特殊处理。当 DNSSEC 验证由本地缓存解析器而非 MTA 自身处理时，连 DNAME 支持逻辑的那一部分也在 MTA 之外。

当存根解析器返回一个包含 CNAME 别名、但又不包含该别名目标对应查询结果的应答时，SMTP 客户端将需要在该别名的目标处重复查询，并应当递归地如此进行，直到某个已配置的或实现相关的递归上限。如果在 CNAME 展开的任何阶段检测到错误，则原始所请求记录的查找必须被视为已经失败。

无论一条 CNAME 记录链是在单个存根解析器应答中返回的，还是通过 SMTP 客户端的显式递归返回的，如果在递归展开的任何阶段遇到了一条"insecure"的 CNAME 记录，那么它及其所有后续结果（特别是最终结果）都必须被视为"insecure"，无论导致该"insecure"记录的任一更早 CNAME 记录是否为"secure"。

注意，一个不可验证的安全感知存根解析器可能向 SMTP 客户端返回一个从验证递归解析器收到的"insecure"应答，其中包含一条 CNAME 记录，以及从 CNAME 目标开始递归获得的附加应答。在这种情况下，唯一可能的结论是所返回记录集中的某条记录是"insecure"，而事实上，初始 CNAME 记录及后续记录的一个子集是"secure"也是可能的。

如果 SMTP 客户端需要确定包含初始 CNAME 记录的 DNS 区的安全状态，它将需要发起一个类型为"CNAME"的独立查询，该查询只返回初始 CNAME 记录。具体而言，如 2.2.2 节所讨论，当经由 CNAME 别名为一个 SMTP 服务器找到"insecure"的 A 或 AAAA 记录时，SMTP 客户端将需要执行一次额外的 CNAME 查询，以确定该别名所发布的 DNS 区是否经过 DNSSEC 签名。

2.2. TLS 发现

如前所述（在 1.3.1 节），与那些通过 STARTTLS 通告 TLS 支持的 SMTP 服务器之间的机会性 TLS，易受 MITM 降级攻击。此外，某些实际上不具备 TLS 能力的 SMTP 服务器默认错误地通告 STARTTLS，而客户端需要准备好在 STARTTLS 失败后重试明文投递。相比之下，对于不支持 TLS 的服务器，不得发布经 DNSSEC 验证的 TLSA 记录。客户端可以安全地将它们的存在解释为服务器运营者实施 TLS 与 STARTTLS 的承诺。

本备忘录规定了在查找 TLSA 记录返回"secure"可用结果、"secure"不可用结果、"insecure"或无结果、或一个错误信号之后所应采取的四种动作。此处的术语"usable（可用）"是 [RFC6698] 第 4.1 节意义上的。具体而言，如果针对 TLSA 记录的 DNS 查找返回：

一个 SMTP 客户端可以被配置为对某些目的地强制要求经 DANE 验证的投递。对于强制 DANE TLS（第 6 节），只有当使用"secure"TLSA 记录与 SMTP 服务器建立了加密且经过认证的 TLS 信道时，投递才继续进行。

当原始下一跳目的地是一个地址字面量而非 DNS 域时，DANE TLS 不适用。投递使用 MTA 管理员配置的任何相关安全策略进行。类似地，当一个 MX RRset 错误地列出了网络地址而非 MX 主机名时，如果某个 MTA 选择连接到该不符规范的 MX 记录中的网络地址，则 DANE TLSA 对此类连接不适用。

在随后的小节中，我们解释如何为给定的下一跳目的地域定位 SMTP 服务器及其关联的 TLSA 记录。我们还解释在 SMTP 服务器证书的身份检查中应当使用哪个或哪些名称。

2.2.1. MX 解析

在本节中，我们考虑受 MX 解析约束且拥有 MX 记录的下一跳域。TLSA 记录及其关联基域是针对每个被用于尝试邮件投递的 MX 主机名分别派生的。只有当 MX 记录是通过 DNSSEC 验证的查找安全地获得时，DANE TLS 才能对发往预期下一跳域的邮件投递进行认证。

MX 记录必须按优先级排序；一个带有更差（数值更高）MX 优先级且拥有 TLSA 记录的 MX 主机名，不得抢占一个带有更好（数值更低）优先级但没有 TLSA 记录的 MX 主机名。换言之，通过遵从 MX 优先级来防止投递环，必须优先于信道安全考量。即便有两条等优先级的 MX 记录，MTA 也没有义务选择提供更高安全性的 MX 主机名。希望获得安全入站邮件投递的域，需要确保其所有 SMTP 服务器和 MX 记录都做了相应配置。

用 [RFC5321] 第 5.1 节的说法，原始下一跳域是"初始名"。如果初始名的 MX 查找导致一个 CNAME 别名，MTA 会用所得名称替换初始名，并用新名称执行一次新的查找。MTA 通常支持 CNAME 展开中的递归，因此这一替换会重复进行（直到 MTA 的递归上限），直到找到最终的非 CNAME 域。

如果 MX RRset（或导向它的任何 CNAME）是"insecure"的（见 2.1.1 节），并且给定目的地的 DANE TLS 是强制的（第 6 节），则投递必须被延迟。如果 MX RRset 是"insecure"的且 DANE TLS 不是强制的，SMTP 客户端可以自由使用前 DANE 的机会性 TLS（甚至可能是明文）。

由于本备忘录中的协议是一种机会性安全协议 [RFC7435]，SMTP 客户端可以选择使用 DANE TLS（如下文 2.2.2 节所述），即便 MX 主机是通过"insecure"的 MX RRset 获得的。例如，当一个托管提供商拥有一个签名的 DNS 区并为其 SMTP 服务器发布 TLSA 记录时，那些未签名的托管域仍可能受益于该提供商的 TLSA 记录。当发送 SMTP 客户端选择使用该提供商的 TLSA 记录时，经由该提供商 SMTP 服务器的投递将不会受到主动攻击（当然，在此情况下篡改"insecure"MX RRset 的主动攻击仍是可能的）。

当 MX 记录未经（DNSSEC）签名时，主动攻击者可以将 SMTP 客户端重定向到其所选的 MX 主机。当经由"insecure"MX 记录找到的 SMTP 服务器以其原始（而非 CNAME 展开的）形式记录在 MTA 投递日志中作为下一跳中继时，此类重定向是防篡改可见的。发送 MTA 应当在这些源于"insecure"MX 查找的情况下记录未展开的 MX 主机名。任何经由不安全确定的 MX 主机的成功认证，都不得在邮件日志中被错误地表示为对预期下一跳域的安全投递。

在没有 DNS 查找错误的情况下（2.1.1 节），如果 MX RRset 不是"insecure"，那么它就是"secure"，并且 SMTP 客户端必须按 2.2.2 节所述处理每个 MX 主机名。当对于给定的 MX 主机名，没有找到 TLSA 记录或只找到"insecure"的 TLSA 记录时，DANE TLSA 对该所涉 SMTP 服务器不适用，并且投递如同前 DANE 机会性 TLS 那样继续发往该主机。为避免降级攻击，TLSA 查找期间的任何错误都必须（如 2.1.2 节所解释）导致所涉 SMTP 服务器被视为不可达。

2.2.2. 非 MX 目的地

本节描述用于为以下输入域定位 TLSA 记录及其关联 TLSA 基域的算法：该域不受 MX 解析约束、它代表来自一个"secure"MX RRset 的主机名、或者它缺少 MX 记录。此类域包括：

注意，类型为 TLSA 的 DNS 查询会被某些大型电子邮件提供商的负载均衡名称服务器错误处理，这些名称服务器服务于其 MX 主机名。这些名称服务器所服务的 DNS 区未签名，且不含有 TLSA 记录。这些名称服务器应当提供指示 TLSA 记录不存在的"insecure"否定应答，但它们却以完全不响应、或响应以 NXDOMAIN 之外的某个 DNS RCODE [RFC1035]（例如 SERVFAIL 或 NOTIMP [RFC2136]）而失败。

为避免向那些 SMTP 服务器由这些有问题名称服务器服务的域投递邮件时出问题，SMTP 客户端必须在尝试定位关联 TLSA 记录之前，先执行针对该目的地的任何 A 和/或 AAAA 查询。无论如何都需要此查找，以确定（1）目的地域是否可达，以及（2）到达最终地址记录所需的 CNAME 查询链的 DNSSEC 验证状态。

如果未找到地址记录，则该目的地不可达。如果找到了地址记录，但首次查询响应的 DNSSEC 验证状态为"insecure"（见 2.1.3 节），则 SMTP 客户端不应继续搜索任何关联的 TLSA 记录。对于这些有问题的域，TLSA 查询会导致 DNS 查找错误，并导致邮件被持续延迟并最终退回给发送方。我们不期望在某个位于未签名 DNS 区中的 TLSA 基域上找到任何"secure"的 TLSA 记录。因此，在这种情况下跳过 TLSA 查找也将降低延迟，且对安全性没有任何不利影响。

如果初始名的 A 和/或 AAAA 查找产生一个 CNAME，我们将其替换为所得名称（仿佛它就是初始名），并使用新名称再次执行查找。这一替换以递归方式进行（直到 MTA 的递归上限）。

我们考虑以下用于处理 A 或 AAAA DNS 查找的 DNS 应答的情况：

综上，如果有可能安全地获得输入域的完整、CNAME 展开、经 DNSSEC 验证的地址记录，那么该名称就是首选的 TLSA 基域。否则，未展开的输⼊域是候选 TLSA 基域。当在 CNAME 展开的域或未展开的域上均未找到"secure"的 TLSA 记录时，DANE TLS 不适用于经由所涉输入域的邮件投递。并且，一如既往，过程中任何查询的错误、"bogus"结果或"indeterminate"结果都必须导致延迟或放弃投递。

2.2.3. TLSA 记录查找

当 SMTP 服务器的主机名不是 CNAME 或 DNAME 别名时，关联的候选 TLSA 基域列表（见下文）仅由该服务器主机名组成。

当该主机名是一个带有"secure"（在每一阶段）完整展开的别名时，候选 TLSA 基域列表（见下文）是一对域：先是完整展开的服务器主机名，其次是未展开的服务器主机名。

每个候选 TLSA 基域（别名展开后的或原始的）依次被加上形如"_<port>._tcp"的服务标签前缀。所得域名被用于发起一个查询类型设为 TLSA 的 DNSSEC 查询（[RFC6698] 第 7.1 节）。

这些候选域中第一个产生"secure"TLSA RRset 的，成为实际的 TLSA 基域。

对于 SMTP，目标 TCP 端口通常是 25，但在 MTA 管理员指定的自定义路由下这可能不同，在这种情况下 SMTP 客户端必须在"_<port>"前缀中使用适当的数字来替代"_25"。例如，如果候选基域是"mx.example.com"且 SMTP 连接指向端口 25，则 TLSA RRset 经由如下形式的 DNSSEC 查询获得：

      _25._tcp.mx.example.com. IN TLSA ?

该查询响应可能是一条 CNAME 或实际的 TLSA RRset。如果响应是一条 CNAME，SMTP 客户端（通过使用其安全感知存根解析器）在目标域重新发起 TLSA 查询，适当地跟随 CNAME，并跟踪整个链是否"secure"。如果遇到了任何"insecure"记录或 TLSA 记录不存在，则改为尝试下一个候选 TLSA 基域。

如果最终响应是一个"secure"的 TLSA RRset，那么该候选 TLSA 基域将成为实际的 TLSA 基域，并且该 TLSA RRset 将构成该目的地的 TLSA 记录。如果没有任何候选 TLSA 基域产生"secure"的 TLSA 记录，那么 SMTP 客户端可以自由使用前 DANE 机会性 TLS（甚至可能是明文）。

TLSA 记录的发布者可以利用 CNAME 来引用一条单一的权威 TLSA RRset，它指定一个供多个 TLS 服务使用的公共 CA 或公共终端实体证书。此类 CNAME 展开不会改变 SMTP 客户端对 TLSA 基域的认知；因此，当 _25._tcp.mx.example.com 是一条 CNAME 时，基域仍然是 mx.example.com，并且这仍然是与下一跳域一起用于对等证书名称检查的引用标识符。

注意，共享的终端实体证书关联使发布域暴露于替换攻击，其中 MITM 攻击者可以将流量重新路由到共享同一终端实体证书的另一台服务器。应当避免此类共享终端实体的 TLSA 记录，除非所涉服务器在功能上等价或采用互不兼容的协议（主动攻击者将客户端流量从这样一台服务器转移到另一台得不到任何好处）。

一个更好的例子使用了共享信任锚而非共享终端实体证书，由以下经 DNSSEC 验证的记录说明：

      example.com.                IN MX 0 mx1.example.com.
      example.com.                IN MX 0 mx2.example.com.
      _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
      _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
      tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c149a...

SMTP 服务器 mx1.example.com 和 mx2.example.com 将被期望拥有在某个公共信任锚下颁发的证书，但尽管有上述 CNAME 记录，每个 MX 主机名的 TLSA 基域保持不变。相应地，每个 SMTP 服务器都将与一对引用标识符相关联，该对标识符由其主机名加上下一跳域"example.com"组成。

如果在 TLSA 解析（包括可能的 CNAME 间接）期间，找到了至少一条"secure"的 TLSA 记录（即便不可用，因为它不被实现支持或支持被管理上禁用），那么该相应主机就已经发出了实施 TLS 的承诺信号。除非经由 STARTTLS 协商出一条 TLS 会话，否则 SMTP 客户端不得经由相应主机投递邮件。这是为避免 MITM STARTTLS 降级攻击所必需的。

如前所述（在 2.2.2 节），当在完整 CNAME 展开名上未找到"secure"的 TLSA 记录时，必须改为尝试原始的未展开名。这支持这样一些托管提供商的客户：提供商的区无法用 DNSSEC 验证，但客户已与托管提供商共享了适当的密钥材料以通过 SNI 启用 TLS。在 CNAME 展开过程中产生的、既非原名也非最终名的中间名，永远不是候选 TLSA 基域，即便它是"secure"的。

3. DANE 认证

本节描述哪些 TLSA 记录适用于 SMTP 机会性 DANE TLS，以及如何应用这些记录来认证 SMTP 服务器。借助机会性 DANE TLS，由 DANE TLSA 记录的存在所隐含的 TLS 支持、以及认证 TLS 对等方所需的验证参数，是一起获得的。与那些信道安全策略完全由客户端设定的协议相比，经由本协议的认证预期更不容易因客户端与服务器配置不兼容而导致连接失败。

3.1. TLSA 证书用法

DANE TLSA 规范 [RFC6698] 通过三个数值参数的组合定义了多种 TLSA RR 类型。这些参数的数值后来在 [RFC7218] 中被赋予了符号名。TLSA 记录的其余部分是"证书关联数据字段"，它指定证书或公钥的完整值或摘要值。

由于机会性 DANE TLS 将被非交互式 MTA 使用，在认证失败时没有用户来"点击确定"，因此对等认证的可靠性至关重要。建议服务器运营者发布那些最不可能因互操作性或运维问题而导致认证失败的 TLSA 记录。因为 DANE TLS 依赖于对 DNS 与 SMTP 服务器设置的协调变更，所以发布何种记录的最佳选择将取决于站点特定的实践。

TLSA 记录的证书用法元素在决定如何使用相应的证书关联数据字段来认证服务器的证书链方面起着关键作用。3.1.1 节和 3.1.2 节分别解释了证书用法 DANE-EE(3) 和 DANE-TA(2) 的处理过程。3.1.3 节简要解释了为何证书用法 PKIX-TA(0) 和 PKIX-EE(1) 不适用于机会性 DANE TLS。

总之，我们推荐使用"DANE-EE(3) SPKI(1) SHA2-256(1)"，并以"DANE-TA(2) Cert(0) SHA2-256(1)"TLSA 记录作为次选，具体取决于站点需要。更多细节见 3.1.1 节和 3.1.2 节。TLSA 参数的其他组合要么（1）被明确不支持，要么（2）相较这两者几乎没有什么可取之处。

3.1.1. 证书用法 DANE-EE(3)

通过证书用法 DANE-EE(3) 的 TLSA 记录进行认证，只需检查服务器的叶证书是否与 TLSA 记录匹配。特别地，服务器公钥与其名称的绑定完全基于 TLSA 记录关联。即便证书中的任何名称都与客户端对该服务器的引用标识符不匹配，该服务器也必须被视为已认证。

必须忽略服务器证书的过期日期：TLSA 记录密钥绑定的有效期由该 TLSA 记录 DNSSEC 签名的生效区间决定。

对于 DANE-EE(3)，服务器无需采用 SNI（它们可以忽略客户端的 SNI 消息），即便该服务器以原本需要独立证书的不同名称为人所知。取而代之，所涉所有域的 TLSA RRset 都与服务器的默认证书相匹配便已足够。当然，对于 SMTP 服务器而言，为所有托管域发布同一个 MX 主机名就更简单了。

对于那些在 SMTP 服务器密钥轮换期间能够切实地对 DNS TLSA 记录进行协调变更的域，通常最好发布终端实体 DANE-EE(3) 证书关联。当叶证书或中间证书过期时，DANE-EE(3) 证书不会突然停止工作；当服务器运营者疏忽而未能在服务器证书链中配置所有必需的颁发者证书时，它们也不会失败。

为 SMTP 服务器发布的 TLSA 记录在大多数情况下应当是"DANE-EE(3) SPKI(1) SHA2-256(1)"记录。由于所有 DANE 实现都被要求支持 SHA2-256，此记录类型对所有客户端都有效，并且在同一密钥下续期证书时无需更改。

3.1.2. 证书用法 DANE-TA(2)

某些域可能倾向于避免为每个 TLS 服务发布唯一 TLSA RR 的运维复杂性。如果该域采用一个公共颁发 CA 为多个 TLS 服务创建证书，那么将该颁发机构作为所有相关服务证书链的信任锚（TA）发布可能更简单。由同一 TA 颁发的每个服务的 TLSA 查询域（带有端口与协议前缀标签的 TLSA 基域）于是可以被设为一个指向匹配该 TA 的公共 TLSA RRset 的 CNAME 别名。例如：

      example.com.                IN MX 0 mx1.example.com.
      example.com.                IN MX 0 mx2.example.com.
      _25._tcp.mx1.example.com.   IN CNAME tlsa201._dane.example.com.
      _25._tcp.mx2.example.com.   IN CNAME tlsa201._dane.example.com.
      tlsa201._dane.example.com.  IN TLSA 2 0 1 e3b0c44298fc1c14....

对于用法 DANE-TA(2)，服务器证书将需要拥有与客户端某个引用标识符相匹配的名称（见 [RFC6125]）。服务器可以采用 SNI 来选择呈现给客户端的适当证书。

依赖证书用法 DANE-TA(2) 的 TLSA 记录进行 TLS 认证的 SMTP 服务器，必须将 TA 证书作为 TLS 握手服务器证书消息中所呈现证书链的一部分包含在内，即便它是一个自签名根证书。许多 SMTP 服务器并未配置一份全面的信任锚列表，并且预期它们在将来任何时刻也不会配置。某些 MTA 在处理用法 DANE-TA(2) 的 TLSA 记录时会忽略所有本地受信证书。因此，即便该 TA 恰好是 SMTP 客户端所知的一个公共 CA，除非 TA 证书被包含在 TLS 服务器证书消息中，否则认证很可能失败。

在某些 SMTP 服务器软件中，无法将服务器配置为在服务器证书链中包含自签名（根）CA 证书。此类服务器要么必须为一个中间证书发布 DANE-TA(2) 记录，要么必须改用 DANE-EE(3)TLSA 记录。

不鼓励使用匹配类型为 Full(0) 的 TLSA 记录。虽然这些记录有可能免去在 TLS 服务器证书消息中传输 TA 证书的需要，但客户端实现可能无法用从 DNS 获得的数据来补充服务器证书链，尤其是当 TLSA 记录提供的是一个裸密钥（选择器 SPKI(1)）时。由于服务器无论如何都需要传输 TA 证书，服务器运营者应当发布匹配类型不是 Full(0) 的 TLSA 记录，并避免含有完整证书或密钥的大型 TLSA 记录可能带来的互操作性问题。

采用 DANE-TA(2) 记录的 TLSA 发布者应当发布选择器为 Cert(0) 的记录。此类 TLSA 记录关联的是整个信任锚证书，而不仅仅是信任锚公钥。特别地，SMTP 客户端应当随后应用来自信任锚证书的任何相关约束，例如路径长度约束。

虽然也可以采用 SPKI(1) 选择器，但所得的 TLSA 记录将不会指定完整的信任锚证书内容，并且信任锚证书中除公钥以外的要素将变得可变。例如，这可能允许某个附属 CA 签发一条违背信任锚路径长度或名称约束的链。

3.1.3. 证书用法 PKIX-TA(0) 与 PKIX-EE(1)

注意，本节适用于 MTA 到 MTA 的 SMTP，这通常位于端口 25——即适用于作为一个或多个目的地域的 SMTP 服务器的那些服务器。SMTP 的其他用途，例如在端口 587 或 465 上的 MUA 到 MSA 提交，不在本文档范围内。当那些其他用途也机会性地采用 TLS 和/或由于基于 DNS 的服务位置发现而依赖 DNSSEC 时，相关规范应当酌情得出类似的结论。

如 1.3.1 节和 1.3.2 节所述，发送 MTA 若非依赖 DNSSEC 获取"secure"MX 记录、并依赖 DANE 进行 STARTTLS 支持信令，就无法执行服务器身份验证或阻止 STARTTLS 降级攻击。使用 PKIX CA 不提供额外的安全性，因为一个能够攻破 DNSSEC 的攻击者可以随意将任何 PKIX-TA(0) 或 PKIX-EE(1) TLSA 记录替换为带有任何方便的非 PKIX 证书用法的记录。最后，如 1.3.4 节所解释，不存在一个所有 MTA 都认同的受信 CA 列表，并且在服务器的 CA 不被客户端信任时没有用户来"点击确定"。

因此，供客户端 MTA 使用的端口 25 SMTP 服务的 TLSA 记录，不应包含证书用法为 PKIX-TA(0) 或 PKIX-EE(1) 的 TLSA RR。不能期望 SMTP 客户端 MTA 被配置一份足够完整的受信公共 CA 集合。缺少完整的公共 CA 集合，MTA 客户端将无法验证那些颁发根 CA 不被客户端信任的 SMTP 服务器的证书。

机会性 DANE TLS 需要在客户端与服务器系统之间没有安全设置的双边协调也能互操作。因此，在缺乏双边协调时脆弱的参数选择是不被支持的。这并没有损失什么；既然 PKIX 证书用法无法助益 SMTP TLS 安全，它们只会妨碍 SMTP TLS 互操作。

SMTP 客户端对证书用法为 PKIX-TA(0) 或 PKIX-EE(1) 的 TLSA RR 的处理是未定义的。与任何其他不受支持的证书用法一样，SMTP 客户端可以将此类记录视为"不可用"。

3.2. 证书匹配

当找到至少一条可用的"secure"TLSA 记录时，SMTP 客户端必须使用 TLSA 记录来认证 SMTP 服务器。如果认证失败，不得经由该 SMTP 服务器投递邮件；否则，SMTP 客户端易受 MITM 攻击。

3.2.1. DANE-EE(3) 名称检查

对于证书用法 DANE-EE(3)，SMTP 客户端不得执行证书名称检查（见 3.1.1 节）。

3.2.2. DANE-TA(2) 名称检查

为了经由证书用法为 DANE-TA(2) 的 TLSA 记录匹配服务器，客户端必须执行名称检查，以确保它到达了正确的服务器。在所有 DANE-TA(2) 情况下，SMTP 客户端必须将 TLSA 基域用作匹配服务器证书的主要引用标识符。

除了 MX 主机名之外还接受带有原始下一跳域的证书，使得拥有多个 MX 主机名的域能够在所有 SMTP 服务器上使用一张带有单一域名（即电子邮件域）的证书。这也有助于与那些配置为在服务器证书中查找电子邮件域名的、前 DANE 的 SMTP 客户端互操作——例如，使用如下所示"secure"DNS 记录：

      exchange.example.org.            IN CNAME mail.example.org.
      mail.example.org.                IN CNAME example.com.
      example.com.                     IN MX    10 mx10.example.com.
      example.com.                     IN MX    15 mx15.example.com.
      example.com.                     IN MX    20 mx20.example.com.
      ;
      mx10.example.com.                IN A     192.0.2.10
      _25._tcp.mx10.example.com.       IN TLSA  2 0 1 ...
      ;
      mx15.example.com.                IN CNAME mxbackup.example.com.
      mxbackup.example.com.            IN A     192.0.2.15
      ; _25._tcp.mxbackup.example.com. IN TLSA ? (NXDOMAIN)
      _25._tcp.mx15.example.com.       IN TLSA  2 0 1 ...
      ;
      mx20.example.com.                IN CNAME mxbackup.example.net.
      mxbackup.example.net.            IN A     198.51.100.20
      _25._tcp.mxbackup.example.net.   IN TLSA  2 0 1 ...

对于经由任何关联 SMTP 服务器向 exchange.example.org 投递邮件的证书名称检查，必须至少接受名称"exchange.example.org"和"example.com"，它们分别是原始和完整展开的下一跳域。当 SMTP 服务器是 mx10.example.com 时，名称检查必须接受 TLSA 基域"mx10.example.com"。如果尽管 MX 主机名按规定不得是别名，MTA 仍支持经由"mx15.example.com"或"mx20.example.com"投递，那么名称检查必须接受相应的 TLSA 基域"mx15.example.com"和"mxbackup.example.net"。

3.2.3. 引用标识符匹配

当名称检查适用时（证书用法 DANE-TA(2)），如果服务器证书包含一个至少带有一个 DNS-ID [RFC6125] 的主题备用名称（Subject Alternative Name）扩展 [RFC5280]，则只将 DNS-ID 与客户端的引用标识符进行匹配。CN-ID [RFC6125] 仅在没有 DNS-ID 存在时才被考虑。当服务器证书所呈现的标识符 [RFC5280] 之一与客户端任一引用标识符匹配时，该服务器证书被视为匹配。

通配符在 DNS-ID 或 CN-ID 中（适用时）是有效的。通配符字符必须是 DNS-ID 或 CN-ID 的整个第一个标签。因此，"*.example.com"是有效的，而"smtp*.example.com"和"*smtp.example.com"则不是。SMTP 客户端必须支持匹配引用标识符第一个标签、其余标签逐字匹配的通配符。例如，DNS-ID"*.example.com"匹配引用标识符"mx1.example.com"。SMTP 客户端可以（受本地策略约束）允许通配符匹配引用标识符的多个标签，但服务器不能期望对此类策略有广泛的支持。因此，服务器证书中的任何通配符应当恰好匹配 TLSA 基域或下一跳域中的一个标签。

4. 服务器密钥管理

在使用新的 EE 或 TA 公钥或证书之前，必须发布两条 TLSA 记录：一条匹配当前部署的密钥，另一条匹配计划替换它的新密钥。一旦过了足够长的时间使所有 DNS 缓存都过期了先前的 TLSA RRset 及相关签名 RRset，就可以将服务器配置为使用新的 EE 私钥及关联的公钥证书，或者采用由新信任锚签名的证书。

一旦新的公钥或证书投入使用，匹配已退役密钥的 TLSA RR 就可以从 DNS 中移除，只留下匹配正在使用的密钥或证书的 RR。

如 3.1.2 节所述，当服务器证书经由 DANE-TA(2) 信任锚验证、并采用 CNAME 记录将 TA 关联数据存储在单一位置时，更新 TLSA RRset 的责任就转移到信任锚的运营者身上。在新的信任锚被用于签发任何新的服务器证书之前，其证书（摘要）被加入相关的 TLSA RRset。在过了足够长时间使原始 TLSA RRset 从 DNS 缓存中老化出去之后，新的信任锚就可以开始签发新的服务器证书。一旦在先前信任锚下签发的所有证书都已过期，其关联的 RR 就可以从 TLSA RRset 中移除。

在 DANE-TA(2) 密钥管理模型中，服务器运营者通常在最初创建一条引用集中运营的 DANE-TA(2) RRset 的 CNAME 记录之后，一般无需更新 DNS TLSA 记录。如果某台特定服务器的密钥被攻破，其 TLSA CNAME 应当被替换为一条 DANE-EE(3) 关联，直到被攻破密钥的证书过期，届时它可以恢复使用 CNAME 记录。如果中央信任锚被攻破，所有服务器都需要由一个新的 TA 签发新密钥，并且需要发布一个仅含新 TA 的、更新后的 DANE-TA(2) TLSA RRset。

SMTP 服务器不能期望从 SMTP 客户端获得广泛的证书吊销列表（CRL）或在线证书状态协议（OCSP）支持。如上所述，借助 DANE，被攻破的服务器或信任锚密钥可以通过从 DNS 中移除它们来"吊销"，而无需客户端侧对 OCSP 或 CRL 的支持。

5. 摘要算法敏捷性

虽然 [RFC6698] 规定了多种摘要算法，但它没有规定一个协议来让 SMTP 客户端与 TLSA 记录发布者就最强共享算法达成一致。这样一个协议将允许客户端与服务器避免暴露于为兼容能力较弱的客户端而发布的、已弃用的较弱算法。当更强的算法是一个选项时，应当避免使用已弃用的算法。这样一个协议在 [RFC7671] 中规定。实现本规范的 SMTP 客户端与服务器必须遵守 [RFC7671] 第 9 节概述的要求。

6. 强制 TLS 安全

实现本协议的 MTA 在向选定的目的地发送电子邮件时，可能要求更强的安全保证。发送组织可能需要发送敏感电子邮件，和/或可能有保护其内容的管理义务。本协议与此类要求并不冲突，事实上，它常常能简化到此类目的地的认证投递。

具体而言，对于那些为其 MX 主机名发布 DANE TLSA 记录的域，可以将发送 MTA 配置为使用该接收域的 DANE TLSA 记录来认证相应的 SMTP 服务器。经由 DANE TLSA 记录的认证更易于管理，因为接收方期望的证书属性的变更是在接收方一端做出的，不需要手工传达的配置变更。对于强制 DANE TLS，当找不到可用的 TLSA 记录时，邮件投递被延迟。因此，只有与远程 SMTP 服务器建立了经过认证的 TLS 信道时，邮件才会被发送。

采用强制 DANE TLS 的邮件服务器管理员需要仔细监控其邮件日志与队列。如果一个伙伴域无意中错误配置了它的 TLSA 记录、禁用了 DNSSEC，或错误配置了 SMTP 服务器证书链，邮件将被延迟，并且如果问题未及时解决，可能会被弹回。

7. 关于 DANE 用于邮件用户代理的说明

我们注意到，SMTP 也被用于邮件用户代理（MUA）与邮件提交代理（MSA）之间 [RFC6409]。在 [RFC6186] 中，规定了一个协议，使得 MUA 能够基于用户的电子邮件地址动态定位 MSA。实现 [RFC6186] 的 MUA 的 SMTP 连接安全考量，在很大程度上类似于对 MTA 的连接安全要求，并且本规范在将 DNS MX 记录替换为相应的 DNS 服务（SRV）记录 [RFC7673] 之后，几乎可以逐字套用。

然而，在 MUA 开始采用 [RFC6186] 的动态配置机制之前，它们已被更传统的静态 TLS 安全策略充分服务。针对 MUA 到 MSA 的 SMTP 规定 DANE TLS，留待未来那些专门聚焦于 MUA 与 MSA 之间 SMTP 安全的文档处理。

8. 互操作性考量

8.1. SNI 支持

为确保服务器发送正确的证书链，SMTP 客户端必须发送包含 TLSA 基域的 TLS SNI 扩展。这就排除了 SMTP 客户端使用与 SSL 2.0 兼容的安全套接字层（SSL）HELLO。

每个 SMTP 服务器必须呈现一条至少匹配一条 TLSA 记录的证书链（见 [RFC5246] 第 7.4.2 节）。服务器可以依靠 SNI 来决定向客户端呈现哪条证书链。未发送 SNI 信息的客户端可能看不到预期的证书链。

如果服务器的 TLSA 记录匹配服务器的默认证书链，则服务器无需支持 SNI。无论哪种情况，服务器都无需在其 TLS HELLO 中包含 SNI 扩展，因为仅仅返回一个匹配的证书链就足够了。服务器不得强制客户端使用 SNI，因为客户端可能正在使用未认证的机遇性 TLS，并且可能不期望来自服务器的任何特定证书。如果客户端没有发送 SNI 扩展，或者发送了一个针对不受支持域的 SNI 扩展，服务器必须简单地发送它所选择的某个回退证书链。不强制严格匹配所请求的 SNI 主机名的原因是，DANE TLS 客户端通常愿意接受多个服务器名，但在 SNI 扩展中只能发送一个名字。服务器的回退证书可能匹配客户端可接受的不同名字，例如原始下一跳域。

8.2. 匿名 TLS 密码套件

由于许多 SMTP 服务器要么不支持、要么不启用任何匿名 TLS 密码套件，SMTP 客户端的 TLS HELLO 消息应当主动提出协商一组与此类服务器互操作所需的典型非匿名密码套件。采用前 DANE 机会性 TLS 的 SMTP 客户端也可以在其 TLS HELLO 中包含一个或多个匿名 TLS 密码套件。需要与机会性 TLS 客户端互操作的 SMTP 服务器，应当准备好通过始终选择一个双方都支持的非匿名密码套件、或正确处理协商了匿名密码套件的客户端连接，来与此类客户端互操作。

注意，虽然 SMTP 服务器运营者没有义务启用匿名密码套件，但向会忽略它们的客户端发送证书并不能获得任何安全性。事实上，服务器对匿名密码套件的支持使审计线索信息更丰富。记录采用了匿名密码套件的连接的日志条目，记录了客户端并不关心认证服务器这一事实。

9. 运维考量

9.1. 客户端运维考量

发送方或接收方一侧无法及时纠正的运维错误，有时会导致对时效性电子邮件的持续投递失败。发送 MTA 管理员可能不得不在允许电子邮件排队直到错误解决、与针对一个或多个目的地禁用机会性或强制 DANE TLS（第 6 节）之间做出选择。禁用 DANE TLS 安全这一选择不应轻率做出。应当尽一切合理努力来确定邮件投递问题是由运维错误而非攻击造成的。一种回退策略可能是，如果发送 MTA 支持，则配置显式的带外 TLS 安全设置。

SMTP 客户端可以通过仅为选定站点启用，来渐进地部署机会性 DANE TLS；或者可能偶尔需要针对那些因任一端配置错误或软件缺陷而无法互操作的伙伴，禁用机会性 DANE TLS。某些实现可能支持"仅审计"（audit only）模式的 DANE TLS，在该模式下，未能达到所需安全级别会被记录为一条警告，并以降低的安全级别继续投递。除非本地策略指定了"仅审计"，或指定不对某个特定目的地使用机会性 DANE TLS，否则当为某服务器找到了可用的 TLSA 记录、而该服务器的证书链未能匹配至少一条 TLSA 记录时，SMTP 客户端不得经由该服务器投递邮件。

9.2. 发布方运维考量

某些 MTA 有选择地启用 STARTTLS。例如，它们可能只与支持"得当 MTA 行为"（proper MTA behavior）的客户端一起使用 STARTTLS，例如通过重试延迟邮件的投递（灰名单）。如果此类 MTA 发布了 DANE TLSA 记录，实现本规范的发送 MTA 将不会尝试建立"得当 MTA 行为"所需的初始明文 SMTP 事务，因为它们无法建立所需的信道安全。如果服务器运营者也想支持 DANE TLSA，就不得实施选择性 STARTTLS。

TLSA 发布者必须遵守 [RFC7671] 第 8 节的指南。

TLSA 发布者应当遵循 [RFC7671] 第 10.1 节中的 TLSA 发布规模指南。

TLSA 发布者应当遵循 [RFC7671] 第 13 节中的 TLSA 记录 TTL 与签名寿命建议。

10. 安全考量

本协议利用 DANE TLSA 记录为 SMTP 实现抗 MITM 的机会性安全 [RFC7435]。对于那些对其 MX 记录进行签名、并为其 MX 主机名发布经签名的 TLSA 记录的目地域，本协议允许发送 MTA 安全地同时发现 TLS 的可用性与如何认证该目的地。

本协议并不旨在保护所有 SMTP 流量，因为在 DNSSEC 与 DANE 的采用普及之前这是不切实际的。遵循本规范所提供的渐进式部署，是保护 SMTP 的最佳可行路径。本协议与现有的不安全 Internet 电子邮件骨干网共存并互操作。

本协议不排除现有的非机会性 SMTP TLS 安全安排，那些安排可以继续像从前一样，经由手动配置以及协商好的带外密钥与 TLS 配置交换来使用。

机会性 SMTP TLS 关键性地依赖于 DNSSEC 来实现降级抵抗与目的地名称的安全解析。如果 DNSSEC 被攻破，就不可能回退到公共 CA PKI 来阻止 MITM 攻击。一次成功的 DNSSEC 突破使攻击者能够发布 TLSA 用法 3 的证书关联，从而绕过合法域所有者在发布用法 0 或用法 1 的 TLSA RR 时可能希望获得的任何安全收益。鉴于现有 MTA 部署中缺乏对公共 CA PKI 的支持，避免证书用法 0 和 1 简化了实现与部署，且没有任何不利的安全后果。

实现必须严格遵循本规范的 2.1.2、2.1.3、2.2、2.2.1、2.2.2、2.2.3、3.2 与 9.1 节；这些节指出了何时适合发起与 SMTP 服务器的未认证连接或明文连接。具体而言，为防止针对本协议的降级攻击，当本规范指示某个特定 SMTP 服务器必须被视为不可达时，实现不得发起连接。

11. 参考文献

11.1. 规范性参考文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <http://www.rfc-editor.org/info/rfc3207>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <http://www.rfc-editor.org/info/rfc5598>.

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.

[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.

[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <http://www.rfc-editor.org/info/rfc6186>.

[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <http://www.rfc-editor.org/info/rfc6672>.

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.

[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.

11.2. 资料性参考文献

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <http://www.rfc-editor.org/info/rfc2181>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.

[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <http://www.rfc-editor.org/info/rfc6409>.

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.

[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.

致谢

作者谨向 Tony Finch 致以深切谢意，他启动了 DANE SMTP 文档的最初版本。他的工作深受赞赏，并已被纳入本文档。作者还要额外感谢 Phil Pennock 对本文档的评论与建议。

来自 Viktor 的致谢：感谢 Paul Hoffman，他促使我开始着手本备忘录的工作，并对本文档的早期草案版本提供了反馈。感谢 Patrick Koetter、Perry Metzger 和 Nico Williams 宝贵的评审意见。还要感谢创建了 Postfix 的 Wietse Venema，他的建议与反馈对于 Postfix DANE 实现的开发至关重要。

作者地址

Viktor Dukhovni
Two Sigma
Email: ietf-dane@dukhovni.org

Wes Hardaker
Parsons
P.O. Box 382
Davis, CA 95617
United States
Email: ietf@hardakers.net