Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Informational 19 July 2026 Expires: 20 January 2027 Considerations for Selecting Post-Quantum Algorithms for DNSSEC draft-hoffman-pq-dnssec-considerations-00 Abstract This draft lists many of the considerations that the DNS community needs to balance when it is deciding which post-quantum algorithms to standardize for DNSSEC. This draft is definitely not meant to become an RFC. 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 20 January 2027. Copyright Notice Copyright (c) 2026 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. Hoffman Expires 20 January 2027 [Page 1] Internet-Draft Selecting PQ DNSSEC July 2026 Table of Contents 1. Considerations for Selecting Post-Quantum Algorithms for DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Standardization . . . . . . . . . . . . . . . . . . . . . 2 1.2. Size of Records . . . . . . . . . . . . . . . . . . . . . 2 1.3. CPU Usage other than TCP . . . . . . . . . . . . . . . . 3 1.4. Changes Needed to the DNS Protocol . . . . . . . . . . . 3 1.5. Likelihood of Inclusion in HSMs . . . . . . . . . . . . . 3 1.6. Amount and Assuredness of Cryptanalysis . . . . . . . . . 3 2. Additional Resources . . . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Considerations for Selecting Post-Quantum Algorithms for DNSSEC This document lists many of the considerations that the DNS community needs to balance when it is deciding which post-quantum algorithms to standardize for DNSSEC. The list here is not meant to be exhaustive, nor are the items listed in any particular order. The various considerations are not all equal, and different parts of the DNS community may find some considerations more important than others. This list is a brief summary, and does not contain all the details of each consideration that might be important to each part of the DNS community. It is meant to help the DNS community remember the significant tradeoffs that need to be made when picking a post- quantum algorithm for DNSSEC. 1.1. Standardization Does an algorithm have to be standardized by the US NIST? If an algorithm isn't standardized by US NIST, what other standards bodies are aceptable? 1.2. Size of Records Some proposals have big public keys but acceptable-sized signatures. Some proposals have big signtures but acceptable-sized public keys. Some proposals have big signtures and big public keys. Proposed terminology for sizes of signatures: * Tiny: <400 bytes (three fit comfortably in a UDP packet for NXDOMAIN responses) * Small: 400-1400 bytes (one or two fit comfortably in a UDP packet) Hoffman Expires 20 January 2027 [Page 2] Internet-Draft Selecting PQ DNSSEC July 2026 * Large: 1400-3000 bytes (forces TCP) * Jumbo: >3000 bytes (causes noticeable traffic size) 1.3. CPU Usage other than TCP Some proposals take much more effort than current algorithms to sign. Some proposals take much more effort than current algorithms to validate. Some proposals take much more effort than current algorithms both to sign and validate. 1.4. Changes Needed to the DNS Protocol Some proposals require changes to how resolvers get keys and/or signatures in order to be efficient. These changes require protocol changes that have to be rolled out with the proposed algorithms. 1.5. Likelihood of Inclusion in HSMs Some proposals are difficult to implement in HSM hardware. Some zones are required by policy to use hardware HSMs. 1.6. Amount and Assuredness of Cryptanalysis Some proposals are considered likely to be secure but have some worrisome aspects. For example, some proposals require very careful implementation of signing in order to not leak the private key. Determining the assuredness is very hard to quantify across the cryptographic community. 2. Additional Resources The following may be useful for comparing many post-quantum signature schemes against each other. Post-Quantum Signature Schemes from PQShield (https://pqshield.github.io/nist-sigs-zoo/) Why we cannot wait for better post-quantum signature algorithms from Cloudflare (https://blog.cloudflare.com/ml-dsa-will-have-to-do/) Author's Address Paul Hoffman ICANN Email: paul.hoffman@icann.org Hoffman Expires 20 January 2027 [Page 3]