Two problems
Based on our operational experience, we studied two problems in detail, in order to improve our own operational practice and to create awareness in the Internet community. The first problem we looked at was packet fragmentation. DNSSEC messages include digital signatures to prove the authenticity and integrity of DNS records. These digital signatures form a large part of DNSSEC-signed DNS messages, and can – in some cases – make DNS responses so large that they no longer fit in a single IP packet. This causes these DNSSEC messages to be fragmented before they are transmitted over the Internet. Unfortunately, a large proportion of hosts on the Internet may be unable to receive these fragmented responses. This is usually because a firewall is misconfigured to block fragmented messages, as the figure below shows.
We performed a study into the extent of this problem and found that up to 10% of hosts on the Internet may have this problem, which can have serious consequences for the availability and performance of DNSSEC-signed domains. Fortunately, as we explained in presentations, there are ways to deal with this problem, for instance by configuring authoritative name servers to return minimal responses. While this solves most occurrences of fragmentation, as the graph below shows, it doesn’t completely prevent them. A small fraction of DNS responses sent out by SURFnet’s authoritative name servers are still fragmented, and all of these are DNSSEC-signed.
Another serious problem with DNSSEC is that DNSSEC-signed domains can be abused for so-called amplification attacks. This type of attack relies on the fact that DNS requests are much smaller than DNS responses. An attacker sends requests to a DNS server in which he falsifies the sender address, which means that responses will be sent to this falsified address (the victim of the attack). Because responses are much larger than requests, an attacker has to send relatively little traffic to achieve a large attack volume. As the figure below from a study we performed in 2014 shows, DNSSEC-signed domains can easily be used to achieve amplification factors (the response size divided by the request size) that are between 6 and 12 times higher than for domains that do not use DNSSEC.
Root cause: RSA
Unfortunately, the two problems discussed above still exist in DNSSEC today. In fact, earlier this year, Akamai sounded the alarm about the rise of DNSSEC-based amplification attacks. Arguably, the root cause of these problems is the default cryptographic signature algorithm that was chosen for DNSSEC, the RSA digital signature system. The keys used for RSA — and consequently the signatures — are rather large. The two most commonly used key sizes in DNSSEC currently are:
- RSA 2048-bits – for DNSSEC Key Signing Keys; signatures for this key size require 256 bytes in a DNSSEC packet and keys typically require 260 bytes.
- RSA 1024-bits – for DNSSEC Zone Signing Keys; signatures for this key size require 128 bytes in a DNSSEC packet and keys typically require 132 bytes.
Given that “classic” DNS packets used to have a maximum size of 512 bytes, and given that DNSSEC responses may contain multiple keys and signatures, it is easy to see how DNSSEC using RSA increases the size of DNS responses by a large amount. Add to this the fact that standardisation bodies recommend that 1024-bit RSA keys are no longer used and that users should switch to 2048-bit keys, it is easy to see that if we keep using RSA in DNSSEC, the problems are only going to get worse in the future.
An attractive alternative: Elliptic Curve Cryptography
This raises the question whether there are alternatives to RSA for use in DNSSEC. Luckily, this happens to be the case. Elliptic Curve Cryptography (ECC) is an attractive alternative and the Elliptic Curve Digital Signature Algorithm (ECDSA) was already standardised for use in DNSSEC in 2012. Until recently, however, there was very little uptake of ECDSA in DNSSEC. This is unfortunate, as a study we performed shows that the use of ECC can virtually eliminate fragmentation and amplification problems in DNSSEC. This is because ECC delivers more cryptographic strength than RSA with far smaller keys. For example, ECDSA P-256 signatures are 4 times smaller than RSA 2048-bit signatures but have a cryptographic strength equivalent to 3072-bit RSA.
But there are also disadvantages to using elliptic curve cryptography. Especially the fact that the validation of ECC signatures can be up to an order of magnitude slower than the validation of RSA signatures is a potentially an issue. In DNSSEC, validation is performed very frequently by DNS resolvers. This means that switching DNSSEC to ECC can result in a significant increase in CPU load for validating DNS resolvers. We wanted to know whether this could be a potential barrier to adoption, and asked Kaspar Hageman — a master student from the University of Twente — to study this. He found, based on real-world measurements on SURFnet’s DNS infrastructure, that while switching DNSSEC signing to ECC will increase the workload on validating DNS resolvers, this is not an increase that is likely to lead to problems for these validating resolvers (in terms of requiring extra CPU power to deal with the load), even if DNSSEC adoption would grow to 100% (currently, around 3% of domains globally are DNSSEC-signed). This is very good news!
Moving forward: SURFnet will switch to ECC in 2017
At SURFnet, we feel strongly about being good Internet citizens. That means that we want to improve our DNSSEC infrastructure to do away with fragmentation and amplification problems, and that we will share our journey towards this goal so others can benefit from what we learn in the process. In 2017, SURFnet will be upgrading its DNSSEC-signer infrastructure and in the process will switch to signing with ECDSA instead of RSA. This means quite a bit of pioneering is ahead of us, especially because we will:
- Perform a so-called algorithm rollover from RSA to ECDSA; this is a complex operation, intrepid souls may want to have a look at RFC 6781, section 4.1.4 to get a feeling for the complexity.
- Switch to a single key for signing, sometimes referred to as a “Combined Signing Key” (CSK); we do this to further reduce the complexity of our signer setup and to make DNSSEC responses as small as possible.
- Migrate to new Hardware Security Modules to perform the signing (you can read more about this type of migration in a document from 2012, in which we describe our previous migration).
We will be blogging about what we learn during our migration, so stay tuned for further updates!
Further reading
We presented the results of our studies on ECDSA in a presentation at the NANOG 67 meeting on June 13th, the presentation slides and a video are available online.
CloudFlare, a large operator of a DDoS Protection and Content Delivery Network has recently started support DNSSEC and uses ECDSA to sign domains. They have posted a series of articles on their site with background information about their choices.
0 Praat mee