Architecting Post-Quantum DNSSEC: Challenges and Migration Strategies
This article details Cloudflare's initiative to integrate ML-DSA-44, a post-quantum signature algorithm, into 1.1.1.1 DNSSEC validation. It highlights critical system design challenges posed by the large size of post-quantum signatures and the complex migration strategy required to maintain compatibility while preventing security downgrades. The efforts demonstrate proactive architectural planning for future cryptographic landscapes.
Read original on Cloudflare BlogThe Imperative for Post-Quantum DNSSEC
DNSSEC is crucial for authenticating DNS responses, preventing attackers from redirecting users to malicious sites. However, current cryptographic algorithms like RSA and ECDSA are vulnerable to future quantum computers. A successful quantum attack on DNSSEC could allow attackers to forge DNS records, leading to widespread redirection and 'break once, forge everywhere' scenarios. Cloudflare's adoption of ML-DSA-44 is a proactive step to secure DNS infrastructure against this future threat, aiming for full post-quantum security by 2029.
Key Architectural Challenges with Large Signatures
Integrating post-quantum signatures, such as ML-DSA-44 (2,420 bytes), into DNSSEC presents significant architectural hurdles, primarily due to their much larger size compared to conventional signatures (e.g., ECDSA P-256 at 64 bytes). This size increase impacts DNS packet handling:
- UDP Packet Limits: ML-DSA-44 signatures often exceed common DNS-over-UDP limits (e.g., 1,232 bytes for IPv6 MTU, 1,400 bytes recommended by RFC 9715) on their own, before accounting for other DNS records.
- Protocol Shift: Sending fragmented UDP is unreliable. Large DNS responses necessitate a fallback to TCP, DNS over TLS (DoT), or DNS over HTTPS (DoH). While 1.1.1.1 already handles a significant portion of traffic over these protocols (40%), an increase in TCP retries for authoritative server communication could introduce latency and operational overhead.
- Key Rollovers: During migration, DNSKEY responses may contain both conventional and post-quantum keys and signatures for compatibility, further increasing response sizes.
Design Consideration: Transport Protocol Reliability
When designing systems that involve large data exchanges over protocols with strict packet size limits (like UDP), engineers must account for the overhead of alternative transport protocols (like TCP) and the potential for increased connection setup times and resource utilization. Implementing graceful degradation or protocol negotiation mechanisms is crucial.
Migration Strategy and Downgrade Prevention
A phased migration is necessary to maintain compatibility with older resolvers while introducing new post-quantum algorithms. This involves publishing both conventional and post-quantum keys and signatures. A critical security challenge is preventing downgrade attacks, where a quantum-capable resolver might fall back to a conventional, now-vulnerable signature path.
- Simultaneous Publication: Zones initially publish both conventional and ML-DSA-44 signatures to ensure compatibility across the ecosystem.
- Local Validation Policy: 1.1.1.1 implements a restrictive local validation policy. If a DS record in the parent zone indicates support for a post-quantum algorithm, 1.1.1.1 requires at least one valid post-quantum path. A conventional path alone is insufficient, thereby preventing downgrade attacks for clients that support post-quantum DNSSEC.
- Ecosystem-wide Coordination: Full post-quantum security requires widespread adoption, from cryptographic libraries and IANA assignments to authoritative servers, registrars, registries, and eventually the DNS root, as any unmigrated level becomes a potential downgrade point.