Internet-Draft | PQC-DNSSEC-RESEARCH-AGENDA | June 2024 |
Fregly, et al. | Expires 27 December 2024 | [Page] |
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.¶
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.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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:¶
NS RRs comprise nearly 100% of non-DNSSEC-related RRs¶
NS RRsets have an average of 2.4 NS RRs and an average record length of 53 bytes¶
For each domain, there is one RR for both DS and NSEC3 and one RRset for each¶
There is one RRSIG for each DS and NSEC3 RRset¶
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.¶
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:¶
Deployment Analytics: device types and characteristics; roles (stub, resolver, authoritative nameserver); algorithms; environmental constraints such as network limitations; software used for resolution and nameserver operations; resolver in-memory cache sizes; authoritative nameserver in-memory database sizes; zone sizes relative to memory impact; zone composition; supportable transports¶
UDP Networking Path MTU Analytics: stub to resolver; resolver to resolver; resolver to authoritative¶
Analyze DNS/DNSSEC Query and Response Traffic: stub to resolver; resolver to resolver; resolver to authoritative nameserver:¶
Query and Response Analytics: composition, size, and response times of DNS queries and responses including details for overall traffic and DNSSEC-related traffic; transport protocols¶
Caching: caching algorithms, cache composition, effectiveness¶
Truncation and Fragmentation Analysis: overall traffic; DNSSEC related traffic; failures; retries. This analysis is pertinent to understanding and modeling the impact failures and retries would have on DNS performance. For instance, retries over TCP result in a DNS query / response cycle requiring extra round trips with consequent increase in DNS resolution time.¶
DNS response time impact for common use cases (browsing, web services, mobile, IoT,...). It will likely take some creative approaches to broadly assess this so that results are reflective of “real” user experience.¶
Session Based Protocols: percentage of traffic; response times; session setup and teardown metrics; failures; session state/resource management including as a potential denial of service vector.¶
Analyze Zones Based on Domain Level (root, TLD, lower levels)¶
The research is designed to provide the data needed to answer questions such as the following:¶
What is the footprint of resolver software across the DNS ecosystem - metrics on what software and versions are deployed?¶
How can resolvers be categorized and identified according to how likely and quickly they might be updated to handle protocol changes? What are the factors that impact this: cost, administrative limitations, firmware limitations, device limitations?¶
What is the footprint of crypto libraries across the DNS ecosystem?¶
How can we categorize and identify DNS software across the DNS ecosystem relative to how it may be updated to handle protocol changes? What are the factors that impact this: cost, administrative limitations, firmware limitations, devices limitations?¶
What is the split between traffic sent to resolvers versus traffic sent to authoritative nameservers?¶
What is the footprint of forwarding resolver to resolver traffic?¶
Where are the network devices that constrain UDP MTUs - network borders, Internet routing infrastructure, resolvers, authoritative servers?¶
What would be the impact to legacy DNS components for various transition strategies (IoT/embedded devices, locations with a history of being slow to upgrade, locations where change control policies slow implementation of updates, resource constrained locations; locations with a lack of expertise,...)?¶
What are the networks that cannot be upgraded or for which network upgrades would be hard: embedded, IoT, wireless? What are the characteristics for how devices on these networks interact with resolvers?¶
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:¶
This document does not specify any instructions for IANA¶
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¶
Keep Alive Draft¶