Internet-Draft PQC-DNSSEC-RESEARCH-AGENDA June 2024
Fregly, et al. Expires 27 December 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-fregly-research-agenda-for-pqc-dnssec-01
Published:
Intended Status:
Informational
Expires:
Authors:
A.M. Fregly
Verisign Labs
R. van Rijswijk-Deij
DACS group, EEMCS, University of Twente
M. Müller
SIDN Labs
P. Thomassen
deSEC, SSE
C. Schutijser
SIDN Labs
T. Chung
Virginia Tech

Research Agenda for a Post-Quantum DNSSEC

Abstract

This document describes a notional research agenda for collaborative multi-stakeholder research related to a future post-quantum DNSSEC ecosystem. It is inspired by the anticipation that adoption of Post-Quantum signature algorithms will have enough operational impact on DNSSEC that either DNS protocol enhancements will be needed, or DNS will move away from UDP as the prevalent DNS transport, or a combination of both will be needed. Some members of the DNS technical community have even suggested evaluating alternatives to DNSSEC and potentially adopting an alternative protocol or practices to assure the integrity of DNS responses. Given the potential impact of such changes on the DNS ecosystem, the authors believe collaborative multi-stakeholder research into the impact of proposed changes should be performed to inform adoption and standardization activities.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 December 2024.

Table of Contents

1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Introduction

3. Issues Post-Quantum Signature Algorithms Present to DNSSEC

The currently selected NIST PQC digital signature algorithms have characteristics that will present challenges for adoption into DNSSEC. These challenges seem likely to inspire changes to DNS and DNSSEC related protocols, network infrastructure, hardware capacities, and operational practices due to:

Of these challenges, signature size is perhaps the most challenging. In DNSSEC, signatures typically comprise by far the majority of DNSSEC related response data and consequently their size has a larger impact than public key sizes. Large signatures are an issue due to UDP being the prevalent transport for DNS and relative to DNS response sizes, especially over IPv6. Per [DNSFLAG2020], "An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current networks. This is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers and the aforementioned research." Signed NSEC and NSEC3 responses containing two or three signatures respectively and signed with the NIST selected algorithm with the smallest signature size, FALCON 512 (at 666 bytes per signature), would result in packets whose size exceeds the required minimum MTU for IPv6, resulting in fragmented or truncated responses for networks that support no more than the minimum.

There are methods of dealing with responses that are too big, such as sending fragmented responses or having a DNS query retried over TCP. Research has shown that these methods, designed for "slightly oversized" messages, increase latency, are prone to failure, lack universal support, and their suitability for responses that are (possibly) O(10^2) times a classical DNS message is unclear. Besides, there are other potential transport options such as TLS and QUIC. However, given the massive footprint of DNS and need for transport support across that footprint, a move away from plain UDP as the prevalent transport should be carefully considered due to a number of factors including an expected extended transition period, operational considerations and costs.

In addition to transport impact, larger signature sizes will have significant impact on in-memory caches of resolvers and in-memory databases used by authoritative nameservers for large zones. In an example using a fully signed TLD with the following characteristics:

In this example, if the zone was signed with SPHINCS+ 128s, signatures would comprise over 99% of the size of the zone file. This would increase the zone file size by a factor of 67 relative to a zone signed with ECDSA-256 and by a factor of 37 relative to a zone signed with RSA 1280.

CPU processing requirements may also increase significantly for some PQC algorithms though this issue is of less concern than the issues presented by signature sizes. For example, in DNSSEC signatures are not typically generated "on the fly", but rather are generated in batches by a provisioning system. It can be anticipated that by the time PQC algorithms have been deployed, advances in CPUs, GPUs, and specialized processors should address the performance impacts of PQC algorithms. In some cases such as for verification on legacy low-powered devices with limited CPU capacity, CPU processing may be a consideration.

Taking into consideration the above factors, addressing the impact on DNSSEC of PQC signature sizes on DNSSEC should be a primary focus for algorithm research, impact analysis, transition planning, and standardization activities.

4. Notional Changes to DNSSEC to Address the Impact of Post-Quantum Algorithms

5. Proposed Research Activities

The described notional approaches plus others that may come to light could have significant impact on: devices; DNSSEC-related protocols; software used in devices; software used in resolvers; software used in authoritative nameservers; network considerations; performance; transition planning; operational considerations; resources needed for DNSSEC-related processing. It would be prudent to gain a detailed understanding of these impacts prior to creating and adopting standards or beginning a transition to a PQC DNSSEC. This understanding could be gained by means of a collaborative multi-stakeholder research agenda. This agenda might be comprised of:

6. Research Questions

The research is designed to provide the data needed to answer questions such as the following:

7. Research Driven Modeling

This described research agenda would provide answers to the research questions and lead to a baseline understanding of the overall DNSSEC ecosystem that would be impacted by DNSSEC-related standards and technology changes to support PQC algorithm adoption. This understanding could then enable modeling of the impacts of various approaches for a PQC DNSSEC. Desirable modeling might include:

8. IANA Considerations

This document does not specify any instructions for IANA

9. Security Considerations

TBD

10. References

10.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[DNSFLAG2020]
dns-violations, "DNS Flag Day 2020", , <https://dnsflagday.net>.
[FRAG]
Goertzen, J. and D. Stebila, "Post-Quantum Signatures in DNSSEC via Request-Based Fragmentation", , <https://s3.amazonaws.com/files.douglas.stebila.ca/files/research/papers/EPRINT-GoeSte22.pdf>.
[MTLMODEID]
Harvey, J., Kaliski, B., Fregly, A.M., and S. Sheth, "Merkle Tree Ladder Mode (MTL) Signatures", , <https://datatracker.ietf.org/doc/draft-harvey-cfrg-mtl-mode/>.
[NEGOTIATION]
Huque, S., Kerr, S., and H. Shulman, "Algorithm Negotiation in DNSSEC", , <https://datatracker.ietf.org/doc/draft-huque-dnssec-alg-nego/03/>.
[RFC7696]
Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, , <https://www.rfc-editor.org/info/rfc7696>.

Appendix A. Acknowledgements

The authors would like to acknowledge the following individuals for their contributions to the development of this document: Sofía Celi, Paul Hoffman, Scott Hollenbeck, Russ Housley, Geoff Huston, Burt Kaliski, Sean Turner, Duane Wessels

Appendix B. Change Log

Keep Alive Draft

Authors' Addresses

Andrew Fregly
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Roland Martijn van Rijswijk-Deij
DACS group, EEMCS, University of Twente
DRIENERLOLAAN 5
7522 NB ENSCHEDE
Netherlands
Moritz Müller
SIDN Labs
Meander 501
6825 MD Arnhem
Netherlands
Peter Thomassen
deSEC, SSE
Kyffhäuserstraße 5
10781 Berlin
Germany
Caspar Schutijser
SIDN Labs
Meander 501
6825 MD Arnhem
Netherlands
Taejoong Chung
Virginia Tech
2228 KnowledgeWorks II
Blacksburg, Virginia 24061
United States of America