Considerations for Selecting Post-Quantum Algorithms for DNSSEC

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.

Standardization Does an algorithm have to be standardized by the US NIST? Does it have to be instantiated in a FIPS document, or possibly an SP? If an algorithm isn't standardized by US NIST, what other standards bodies are aceptable?

Speed of Deployment Some governments have have mandated that all important security systems must be capable of using post-quantum algorithms within a small number of years from now. The web ecosystem has rapidly rolled out post-quantum algorithms in order to meet these deadlines. The DNS community may feel pressure to do the same.

Size of Records In order to prevent falling back from UDP to TCP, responses must fit in the size specified by the receiver. Proposed terminology for sizes of signature records: 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) Large: 1400-3000 bytes (forces TCP) Jumbo: >3000 bytes (causes noticeable traffic size) Some proposals for post-quantum algorithms have: large or jumbo public keys but tiny or small signatures. large or jumbo signtures but tiny or small public keys. large or jumbo signtures and big public keys. Different queries will get a different number of signature RRsets, based on (for example) the RCODE, the number of keys signing the zone, the presence of CNAMEs, and so on. Thus, a small signature record that is 650 bytes will not cause a fallback if it is the only signature record in a response, but it might trigger a fallback if there are multiple signatures of this size.

CPU Usage other than TCP Some proposed post-quantum algorithms have tradeoffs where smaller keys require much more time to create signatures, and/or where smaller signatures take much more time to validate. 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.

Changes Needed to the DNS Protocol Some proposals require changes to how validating resolvers get the full keys and/or signatures. The goal is that some signatures can be validated using only UDP for the response, but other signatures might require more queries over UDP or possibly TCP. These changes require protocol changes that have to be rolled out with the proposed algorithms.

Likelihood of Inclusion in HSMs Some proposals are difficult to implement in HSM hardware. Some zones are required by policy to use hardware HSMs.

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.

Patent Licensing The proponents of some proposals have issued intellectual property rights statements in the IETF's IPR disclosure list. Some of the are assertions of patents for which agreements must be made in order to use the technology associated with the proposal.