A Quantum-Safe Cryptography DNSSEC Testbed

DNSSEC was created to provide authentication and integrity for the DNS, an important piece of Internet infrastructure. DNSSEC relies on cryptography to guarantee those properties. With research making considerable progress in designing quantum computers, it is time to consider the scenario that usable quantum computing becomes a reality in the future. In this blog, we discuss the testbed that we are setting up to empirically evaluate the impact of quantum-safe cryptography algorithms on DNSSEC.

Quantum computers and DNSSEC

Currently, quantum computers are experimental and not very powerful. However, in the next 10 or 15 years, quantum computers may become powerful enough to be a threat to many cryptographic functions used in Internet security. Even though it could take significantly longer for quantum computers to become sufficiently powerful to threaten current cryptography, we have to be prepared for a worst-case scenario. In the context of DNS, DNSSEC may no longer guarantee authentication and integrity when powerful quantum computers become available. For the end user, this means that they can no longer be sure that when they browse to example.nl they will end up at the correct website (spoofing). They may also receive more spam and phishing e-mails, since modern e-mail security protocols rely on DNSSEC as well.

Fortunately, cryptographers are working on creating cryptographic algorithms that are resistant to quantum computer attacks: so-called quantum-safe cryptographic algorithms. However, those quantum-safe algorithms often have very different characteristics than their non-quantum-safe counterparts, such as signature sizes, computation time requirements, memory requirements and, in some cases, key management requirements. As a consequence, those quantum-safe algorithms are not drop-in replacements for today's algorithms.

For DNSSEC, it is already known that there are stringent requirements when it comes to, for example, signature sizes and validation speed. But other factors, such as the size of the zone file, also have implications for the suitability of algorithms.

PATAD: A quantum-safe cryptography DNSSEC testbed

To empirically investigate the impact of quantum-safe algorithms on DNSSEC, we started the project PATAD (Post-quantum Algorithm Testing and Analysis for the DNS). Its goal is to develop a testbed that enables us to protype, evaluate, and benchmarkvarious quantum-safe algorithms in DNSSEC, not just for SIDN, but for other organisations as well.

Figure 1 liststhe components of the PATAD testbed. It takes a zone file as input, which contains the DNS zone. Up next is the zone file signer (part 1), which is capable of generating DNSSEC signatures. Then, in order to publish the zone, we need an authoritative DNS server (part 2) capable of loading and serving the generated zone file. That concludes the publishing part of the setup. We can then continue to the consuming part, where a recursive resolver (part 3) should be capable of validating the retrieved signatures. Finally, there is the stub resolver (part 4), which can act as an intermediary between the recursive resolver and any application requesting a DNS lookup.

The most important items in that list, which need to be quantum-safe are the zone file signer that generates the signatures and the recursive resolver that needs to validate the signatures. The authoritative DNS server also needs to be modified to support the new algorithms, but those changes will not relate to the cryptographic operations. Initially, we have started with one algorithm (Falcon), but this work enables us to add more algorithms later, which we indeed plan to do. We use PowerDNS as the authoritative name server in our first version of the testbed.

The PATAD testbed for instance enables us to create topologies to perform experiments. A sample topology would simulate the root zone, a top-level domain and a second-level domain.

Use of the testbed by operators and researchers

To identify which other organisations would benefit from our testbed, we asked experts from different target groups how they could benefit from such a testbed.

The experts we asked were Simona Samardjiska, a cryptographic researcher and assistant professor at Radboud University, Roland van Rijswijk-Deij, network researcher and professor at University of Twente, and Joeri de Ruiter, technical specialist security and privacy at SURF.

Our first question to the three experts was how the PATAD testbed could help them in their work, and what they expect to learn from using the testbed. "A well-designed testbed can be a vital tool for evaluating the performance of new algorithms and new implementations of algorithms in a realistic setting that echoes the requirements imposed by the real Internet," says Van Rijswijk-Deij. For DNS operators too, having an idea of the performance of new algorithms would be very attractive, according to De Ruiter. De Ruiter further stresses that knowing how quantum-safe algorithms perform is important "to be able to determine how the [quantum-safe] algorithms would affect us." Samardjiska adds that it is important to be able to perform many simulations of different scenarios.

The PATAD testbed has inputs (such as algorithms or DNS zone files) and outputs (such as metrics). When asked what inputs would be relevant, Samardjiska says that she would like to evaluate various algorithms in the testbed, examples being Falcon, UOV and Mayo. Furthermore, she mentions various types of statistics that could be analysed, such as the amount of traffic between resolvers, response times, failure rates, signature verification times, memory usage and zone file sizes. Monitoring the internal state of the testbed is also important, according to Van Rijswijk-Deij, stating that a testbed should record "both externally observable traffic (DNS packets exchanged by the nodes that make up the testbed), and the internal state and decisions of software (i.e. re-use of cached items on a resolver, how many actual signature validations take place, etc.)". Van Rijswijk-Deij adds that such output "gives us a clear picture of the impact of implementing algorithms and policies, and allows us to experiment with different parameters."

Samardjiska further notes ideas on different scenarios that should be evaluated using the PATAD testbed, such as testing the possibility of sending public keys out of band or in fragmented form. Hybrid algorithms (example), the simulation of scenarios where different resolvers have different capabilities, and denial-of-service attacks are relevant to support, according to Samardjiska. Simulating the real-world situation as closely as possible would be nice as well, adds Van Rijswijk-Deij, stating that "this means also implementing simulations involving very large zones such as .com." Additionally, Van Rijswijk-Deij continues, "it would be nice if the testbed can be taken to extremes. For example, what if every domain was DNSSEC-signed?" Looking ahead to the future of the PATAD testbed, Van Rijswijk-Deij suggests "experimenting with alternative transports in the testbed (e.g. TLS, QUIC, or transporting key and signature material out of band)."

Overall, the PATAD testbed could help organisations prepare for the future. Knowing how quantum-safe algorithms affect organisations "allows us to prepare for the change in requirements and enables us to inform our members," De Ruiter says. Moreover, "this could be helpful for determining the possible impact on other services we run," he concludes.

Next steps

Our interaction with the experts confirms that the PATAD testbed serves a useful purpose. The experts shared a wide range of ideas on how the testbed could be used.

We have created a first version of the PATAD testbed in which we integrated one quantum-safe algorithm into a DNS software stack. To make the testbed suitable for performing measurements such as the ones outlined above, next steps include integrating more quantum-safe algorithms, and using the experts' input to extend the testbed so that the relevant metrics can be measured. This will enable not just us to use the testbed, but other researchers as well.

Would you like to collaborate? Please let us know! Send an email to sidnlabs@sidn.nl.

This article was originally published over on the SIDN Labs blog.