DNSSEC实现算法敏捷性了吗？_今日热文

今天分享的论文主题为针对 Domain Name System Security Extensions（DNSSEC）算法敏捷性（algorithm agility）的研究，主要由来自荷兰特文特大学与NLnet实验室的研究人员共同完成。DNSSEC为域名系统增加了完整性和源身份验证，提高了域名系统的安全性。对于DNSSEC而言，随着密码学的发展采用新算法而废弃安全性不佳的旧算法是非常重要的。如果这一过程可以简单地执行，就称DNSSEC实现了“算法敏捷性”。这一过程可以细分为标准化、支持、部署、弃用四个阶段，作者通过结合定性、定量分析对这四个阶段做了研究，最终得出结论：DNSSEC仅部分实现了算法敏捷性。论文发表于2020年网络测量领域国际顶级会议ACM IMC（录用率：54 / 216 = 25%）。

(资料图)

01【背景介绍】

算法敏捷性

算法敏捷性是设计信息安全协议和标准的一种实践范式。很多Internet Engineering Task Force（IETF）协议使用加密算法提供机密性、完整性、身份验证以及数字签名。为了使这些机制正常工作，通信双方需要支持一个常用加密算法的集合。随着时间的流逝，如果一个协议可以简单地从一种加密算法套件迁移到另一种更优秀的加密算法套件，那么我们就称这个协议实现了RFC 7696[1]中提出的“算法敏捷性”，这份RFC为协议如何实现算法敏捷性提供了一些指导原则。

和其他互联网协议一样，算法敏捷性对DNSSEC非常关键，因为我们不知道针对加密算法的攻击演进得有多快，唯一可以确定的是，在未来的某一天，它们终究会被破解[1]。随着量子计算机的发展，算法敏捷性变得更加重要了。即便我们现在还不知道量子计算机什么时候可以普及，但是它们确实有破解目前DNSSEC所使用的所有加密算法的潜力。也就是说，将可被破解的算法简单、快速地替换为量子安全算法（Quantum-safe algorithm）的能力变得更关键了。

DNSSEC 算法

DNS提供商现在可以在12种签名算法中进行选择以签名其域名，同时可以在4种哈希算法中进行选择以生成DS记录中的公钥摘要，不过其中有些算法已被强烈建议不再使用。在DNSSEC刚被标准化的时候，它只提供了3种可选的加密算法[2]，但在过去十几年中，有9种新算法被支持，新算法拥有更高的安全性或效率（更小的密钥和签名）。为了确保互操作性，RFC 8624[3]规定了软件需要支持哪些算法，根据推荐的强度分为5档：MUST NOT， NOT RECOMMENDED， MAY，RECOMMENDED ， MUST。为避免在算法过渡过程中干扰正常的域名解析过程，保持兼容性，解析器必须支持一些不再被建议用来签名的算法，例如RSASHA1。如图表 1 所示，RFC 8624[3] 针对不同的算法给出了从“不得”、“不建议”、“可以”、“建议”到“必须”的指导方针。

图表1 被标准化的DNSSEC算法以及RFC 8624对它们的推荐程度

02【研究方法】

DNSSEC 算法的生命周期可以分为如下四个阶段：

标准化：被IETF标准化。

支持：得到DNS软件和注册商、注册局等实体支持。

部署：被实际部署到权威服务器和递归解析器上。

弃用：变得不安全，最终被弃用。

作者采用了定性与定量分析相结合的方法对这四个阶段进行了系统性的分析：

1）定性：例如，在研究算法标准化阶段时，作者主要研究了IETF邮件列表，并结合了他们的一手经验，旨在找到一些轶事证据（anecdotal evidence），从而确定促进或阻拦算法部署的一些因素；在研究顶级域对算法部署的影响时，作者采用了问卷的形式，询问了顶级域管理人员的一些想法。

2）定量：例如，为了研究域名上的算法部署，作者依赖OpenINTEL的每日活跃DNS测量[4]；为了研究解析器对于算法的支持情况，作者使用RIPE Atlas[5]测量DNSSEC验证的使用情况，研究对象即为RIPE测量网络中的节点预配置的DNS解析器。

03【主要发现】

作者针对算法生命周期的四个阶段做了系统的分析，限于篇幅这里主要介绍第三个阶段（即部署阶段）的主要发现，第三阶段主要涉及签名与验证两个环节。

一、签名

在签名方面，该论文主要关注基于ECDSA的算法ECDSAP256，因为其得到了广泛部署，而且该论文使用的数据集几乎完整地覆盖了其整个部署过程。相比于RSA，ECDSA使用更短的签名和密钥即可达到相同的安全等级。在提升性能的同时，这也降低了借助DNSSEC发起的拒绝服务攻击的威力。

（一）缓慢的采纳（slow uptake）

图表2 使用ECDSA256算法签名且可被解析器验证的域名数量

起初增长缓慢

如图表 2 所示，2012年ECDSAP256已经被标准化，同年，BIND9、UNBOUND、LDNS也支持了它。

然而，在2015年，仅有21个域名使用该算法进行签名。

到2015年底，已有11K个域名使用ECDSAP256进行签名，其中98%由Cloudflare运营。这是因为在15年9月，Cloudflare启动了公测，允许其客户使用ECDSAP256为其域名启用DNSSEC[7]。

2016年，Knot和PowerDNS Auth. 也开始支持ECDSA。不久之后，.com中使用ECDSAP256签名的域名数量显著增加，这些域名大都由注册商domainnameshop管理[10]。

自2019年起迅速增长

从2019年开始，.com中的ECDSAP256签名的域增长了三倍，.se甚至增长了12倍。

.se的极速增长主要是由分别在1月份和6月份的两次阶跃导致的。在1月份，有高达100k个域名一次性使用该算法进行签名，这些域名中的绝大多数（99%）由瑞典注册商Binero运营（此外，.com上ECDSAP256域的数量增加了26K，这也是Binero造成的）；在6月份，同样的情况再次发生，一个单独的运营商（one.com）占据了99%的新签名。

这些阶跃是由瑞典注册局对DNSSEC激励政策的调整导致的。调整之前，注册商已享受到了DNSSEC部署折扣[8]，只要部署DNSSEC，就能拿到奖励。但在2018年11月，.se宣布将调整其激励措施，要求域名必须使用基于ECDSAP256的算法、基于Edward Curve的算法或RSASHA256和RSASHA512（具有足够的密钥长度）[9]。2019年7月1日，新的激励措施生效。

（二）算法更换（algorithm rollover）

针对不同的顶级域，作者以天为粒度分析新出现的用ECDSA算法签名的域，并将它们分为三类：

新注册的域：一周前还未注册；

新签名的域：一周前已注册，但没有开启DNSSEC；

算法更换的域：一周前已注册，且开启DNSSEC，但没有使用ECDSA算法。

图表3 每周新出现的用ECDSA算法签名的域的数量

如图表3所示，主要发现如下：

新注册的域和新签名的域占了绝大部分，分别是69%和24%。

偶尔会有大量的域名从其他算法更换到ECDSAP256。例如，domainnameshop.com于2016年10月将10万个域名从RSASHA256更换到ECDSAP256；one.com于2019年7月对超过80K个域名进行了同样的处理。

在执行算法更换前，运营商可能会先关闭DNSSEC。因为如果算法更换没有被正确执行，可能会导致域名不可解析。例如，在Binero于2019年1月开始用ECDSA签名其.se域名之前，它们关闭了DNSSEC。从图表 3 中间中可以看到2019年1月后有一个新签名域的小波峰。

新签名的域，往往是因为改变了DNS服务商导致的。作者比较了.net中新签名的域一周前后的DNS服务商，发现其中33%发生了改变。运营商的改变很少导致算法更换，少于1%的算法更换现象伴随DNS运营商的改变。

二、验证

在验证方面，作者使用RIPE Atlas测试DNSKEY算法的解析器支持情况。对于每种算法，发送两个DNS查询：一个是被正确签名的域名，另一个是签名错误的域名。当前者成功而后者失败时，解析器被视为支持某个算法。如果对于两个域名都收到了包含答案的响应，则认为解析器未进行验证。

测量结果如图表 4 所示，纵坐标代表的是某种算法相对于RSASHA256算法的相对支持比例。部分算法的支持情况几乎完全一致，例如DSA-NSEC3-SHA1和DSA、RSASHA256和RSASHA512、RSASHA1-NSEC3-SHA1和RSASHA1、ECDSAP384SHA384和ECDSAP256SHA256，因此在图中并未列出。

图表4 DNSSEC验证解析器支持DNSSEC算法的整体进程

可以看到ED25519与ED448两种算法的支持比例在不断地增长，在论文撰写时，近70%的DNSSEC验证解析器支持ED25519，近17%支持ED448。对于RFC 8624标记为“MUST NOT”的三种算法RSAMD5、DSA-NSEC3-SHA1、DSA以及标记为“MAY”的一种算法“ECC-GOST”，支持比例在不断下降，这一过程在RFC 8624发布后开始加速。

04【结论】

基于以上的测量与分析，作者得出结论：DNSSEC仅部分实现了算法敏捷性。

ECDSA算法的引入说明新算法可以被标准化，可以获得软件、注册商、注册局以及解析器的支持，可以被部署在各个域上，但需要数年时间。同时，ECDSA的例子还说明，障碍并不在DNSSEC协议本身，而是 (1) 域名注册商采取新算法的过程过于漫长；(2) 缺乏开箱即用的软件；(3) DNS 运营者的犹豫不决。

然而，将已弃用算法替换为新算法很困难。算法更换很少发生，这既是因为更换操作的复杂性，也是因为缺乏足够的激励导致的，大多数正在使用的算法仍然足够安全。从上层来看，TLD的运营者很少实施算法更换；根区仅在2018年执行过一次KSK（Key-signing Key）更换，但未更换签名算法。

展望未来，量子计算机的威胁已近在眼前。基于他们的观察，作者认为量子安全的算法若想得到部署必须：(1) 得到DNS软件和域名注册通道的充分支持；(2) 运营者觉得需要更换算法（出于安全考虑或者因为财政激励）。无论如何，结果表示我们需要开始考虑向量子安全算法的过渡了，因为在DNSSEC中引入一种新的算法需要好多年的时间。

原文链接

https://dl.acm.org/doi/abs/10.1145/3419394.3423638

参考文献

[1] Housley, R., 2015. Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms(No. rfc7696).

[2] Arends, R., Austein, R., Larson, M., Massey, D. and Rose, S., 2005. Protocol modifications for the DNSsecurity extensions(No. rfc4035).

[3] Wouters, P. and Sury, O., 2019. Algorithm implementation requirements and usage guidance for dnssec(No. rfc8624).

[4] Roland van Rijswijk-Deij, Mattijs Jonker, Anna Sperotto, and Aiko Pras. 2016. A High-Performance, Scalable Infrastructure for Large-Scale Active DNS Measurements. IEEE Journal on Selected Areas in Communications 34, 6 (2016), 1877–1888.

[5] RIPE NCC Staff. 2015. RIPE Atlas: A Global Internet Measurement Network. Internet Protocol Journal (IPJ) 18, 3 (Sep 2015).

[6] Roland van Rijswijk-Deij, Anna Sperotto, and Aiko Pras. 2015. Making the case for elliptic curves in DNSSEC. ACM SIGCOMM computer communication review 45, 5 (2015), 13–19.

[7] Dani Grant. 2015. Announcing Universal DNSSEC: Secure DNS for Every Domain. https://blog.cloudflare.com/introducing-universal-dnssec/.

[8] Tho Le, Roland van Rijswijk-Deij, Luca Allodi, and Nicola Zannone. 2018. Economic Incentives on DNSSEC Deployment: Time to Move from Quantity to Quality. In NOMS 2018-2018 IEEE/IFIP Network Operations and Management Symposium. IEEE, 1–9.

[9] Wisser, Ulrich. 2020. Internetstiftelsen: .se incentives. private correspondence.

[10] Domainshop: A website for fast, cheap and easy domain name registration for everyone. https://domainname.shop/

薛镇青，编辑 & 审校 | 王一航、张一铭

标签： 加密算法 量子计算机