1. 引言
"DNS Security Extensions (DNSSEC)" [RFC9364] 用于为 DNS 数据提供认证. DNSSEC 签名算法由多份 RFC 定义, 包括 [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605], 和 [RFC8080].
为确保互操作性, [RFC8624] 定义了一组 "mandatory-to-implement" DNS Public Key (DNSKEY) 算法. 为使算法的当前状态更易访问和理解, 并使这些建议未来的变更更易发布, 本文档将算法的权威状态从 [RFC8624] 移至 IANA DNSSEC algorithm registries. 本文档还纳入了 [RFC9157] 中修订后的 IANA DNSSEC considerations. 此外, 作为给运营者的建议, 本文档增加了关于部署和使用这些算法的建议.
这类似于 "TLS Cipher Suites" registry [TLS-ciphersuites] 所采用的流程, 其中密码套件的权威列表位于 IANA registry 中, RFC 则引用该 IANA registry.
1.1. 文档受众
添加到 IANA "DNS Security Algorithm Numbers" [DNSKEY-IANA] 和 "Digest Algorithms" [DS-IANA] registries 的列面向 DNSSEC 运营者和实现者.
实现需要满足较高的安全预期, 同时在不同实现之间以及不同版本之间提供互操作性.
密码学领域持续演进. 新的, 更强的算法会出现, 现有算法也可能被发现没有最初认为的那样安全. 因此, 算法实现要求和使用指导需要不时更新, 以反映新的现实, 并允许平滑过渡到更安全的算法, 同时弃用被认为不再安全的算法.
实现需要在选择所实现的算法时保持保守, 以同时最小化代码复杂度和攻击面.
实现者的视角可能不同于希望仅使用最安全算法来部署和配置 DNSSEC 的运营者. 因此, 本文档还增加了关于哪些算法应被部署的新建议, 这些建议独立于实现状态. 一般而言, 预期在实现停止支持老化算法之前, 应先逐步减少这些算法的部署.
1.2. 更新算法要求级别
当某个 DNSSEC 密码算法被设为 mandatory to implement 时, 它应已在大多数实现中可用. 本文档定义了一项 IANA registration 修改, 以允许未来文档为每个算法指定实现建议, 因为每个 DNSSEC 密码算法的建议状态预期会随时间变化. 例如, 新引入的算法并不保证未来会成为 mandatory to implement. 同样, 已发布的算法会持续遭受密码分析攻击, 可能变得过弱, 甚至被完全攻破, 并将在未来需要弃用.
预期算法的弃用会逐步进行. 这为实现更新其已实现算法留出时间, 同时保持互操作性. 除非存在强安全理由, 否则预期算法会从 MUST 降级为 NOT RECOMMENDED 或 MAY, 而不是直接从 MUST 降级为 MUST NOT. 类似地, 尚未被列为 mandatory to implement 的算法预期会先以 RECOMMENDED 引入, 而不是以 MUST 引入.
由于使用未知 DNSKEY 算法的效果是将区域视为不安全, 因此建议已被降级为 NOT RECOMMENDED 或更低级别的算法不应由权威名称服务器和 DNSSEC 签名者用于创建新的 DNSKEY. 这可确保被弃用算法的使用随时间减少. 一旦某个算法的部署水平足够低, 就可以将其标记为 MUST NOT, 以便递归解析器移除对其验证的支持.
鼓励验证型递归解析器保留对所有未标记为 MUST NOT 的算法的支持.
1.3. 要求用语
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 在且仅在以此处所示的全大写形式出现时, 应按 BCP 14 [RFC2119] [RFC8174] 中的描述解释.
[RFC2119] 将术语 SHOULD 视为等同于 RECOMMENDED, 将 SHOULD NOT 视为等同于 NOT RECOMMENDED. 本文档选择使用术语 RECOMMENDED 和 NOT RECOMMENDED, 因为这能更清晰地表达给实现者的建议.