DNSSEC is a complicated topic, and making things even more confusing is the availability of several standard security algorithms for signing DNS records, defined by IANA. Algorithm 13 is a variant of the Elliptic Curve Digital Signing Algorithm (ECDSA). While currently used by less than 0.01% of domains, we’d like to argue that ECDSA helped us eliminate the final two barriers for widespread DNSSEC adoption: zone enumeration and DDoS amplification.
After reading this article you will be able to:
Copy article link
DNSSEC is a complicated topic, and making things even more confusing is the availability of several standard security algorithms for signing DNS records, defined by IANA. Algorithm 13 is a variant of the Elliptic Curve Digital Signing Algorithm (ECDSA). While currently used by less than 0.01% of domains, we’d like to argue that ECDSA helped us eliminate the final two barriers for widespread DNSSEC adoption: zone enumeration and DDoS amplification.
Zone enumeration is prevented by live signing, and this is only computationally efficient with the fast signature generation of ECDSA. Elliptic curves also produce significantly smaller keys and signatures than their RSA counterparts, which means responses to DNS queries are smaller. This greatly reduces the amplification factor of DNS-based DDoS attacks.
DNSSEC introduces authenticated denial-of-existence via NSEC and NSEC3 records. However, as we discussed in DNSSEC Complexities and Considerations, both NSEC and NSEC3 allow attackers to walk the zone. The solution is a clever technique called “DNSSEC white lies” (described in RFCs 4470 and 4471), but it can only be implemented if DNSSEC records are signed on-the-fly.
RSA is the most widespread signing algorithm is DNSSEC, partly because it’s the only required algorithm defined by the protocol. Unfortunately, live signing with RSA is prohibitively expensive.
The performance gains of ECDSA are dramatic. It’s 10x less computationally expensive to generate an ECDSA signature than a comparable RSA signature. This makes live signing (and DNSSEC white lies) feasible, even at scale.
During our DNSSEC beta (with less than a 1,000 domains signed), Cloudflare has been answering tens of thousands of DNSSEC queries per second. That comes out to over 1 billion queries a day, and we sign all of the necessary RRSIG records on-the-fly. Having a signing algorithm that’s 10x faster than RSA makes a big difference when it comes to load on our DNSSEC servers.
When we started working with ECDSA, the OpenSSL implementation we used was in Go. Considering all the signing that we’re doing, optimizing signature generation was a serious priority. So, we re-wrote the ECDSA implementation is low-level assembly, and now it’s over 20x faster than it was in Go. That code is open sourced and will make it into Go 1.7 so that the entire crypto community can take advantage of our optimizations. Learn more
Cloudflare is the largest managed DNS provider in the world. What we really don’t want is to turn our DNSSEC servers into an amplification vector for distributed denial-of-service (DDoS) attacks. Every time you request a record from a DNSSEC server, it also returns the signature associated with that record, as well as the public key used to verify that signature. That’s potentially a lot of information.
Making the response size for DNSSEC queries as small as possible is an important requirement to prevent abuse of our DNS infrastructure by would-be attackers. The small size of ECDSA keys and signatures goes a long way towards that end.
Achieving 128-bit security with ECDSA requires a 256-bit key, while a comparable RSA key would be 3072 bits. That’s a 12x amplification factor just from the keys. You can read more about why cryptographic keys are different sizes in this blog post.
But, most RSA keys are not 3072 bits, so a 12x amplification factor may not be the most realistic figure. Let’s take a look at a worst-case real-world scenario for DDoS amplification, which is a negative response (NSEC record). For a domain behind Cloudflare (which uses ECDSA signatures and DNSSEC white lies), a typical DNSSEC response is 377 bytes. Compare this to 1075 bytes for a domain not using ECDSA or DNSSEC white lies.
When you consider the fact that every other large-scale DNSSEC implementation relies on RSA signatures, it’s unappealing for an attacker to leverage our DNSSEC infrastructure as a DDoS vector.
ECDSA solves major problems in DNSSEC, but it’s barely leveraged by the global DNSSEC community. We took a brief look at ECDSA adoption in the root DNS zone and the Alexa one million.
First, we examined the root DNS zone to see which DNSSEC algorithms the top level domains are using. The following table shows the security algorithms specified by the DS records in the root zone file:
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
We performed a similar analysis for the Alexa one million, which gives us a decent cross section of global Internet traffic:
| Algorithm | Number of DS records signed |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (ECDSA Curve P-256 with SHA-256) | 23 |
The most striking revelation is that only 15,643 of the 1,000,000 websites are DNSSEC-enabled in any capacity. Of that 1.5%, only 23 zones are signed with Algorithm 13. And, over half of those Algorithm 13 zones are behind the Cloudflare network. That means there’s less than a dozen zones in the Alexa one million using ECDSA outside of Cloudflare. This supports Roland van Rijswijk-Deij et al.’s findings that 99.99% of signed domains in .com, .net, and .org use RSA.
So, why is Algorithm 13 usage so low, especially given the fact that it solves such major problems in DNSSEC? Well, RSA was introduced with DNSSEC from the very beginning of the protocol. ECDSA is a new cryptographic algorithm, and resolvers, registrars, and registries are still catching up.
ECDSA is not without its trade-offs. According to Roland van Rijswijk-Deij et al., only 80% of resolvers support ECDSA validation. This number is growing, but it means that if we switched the entire DNSSEC Internet onto ECDSA right now, DNSSEC validation would fail for millions of Internet users everyday and fall back to returning unverified DNS records.
Furthermore, while ECDSA signature creation is faster than RSA, signature validation is actually much slower. Roland van Rijswijk-Deij et al. showed that, even with the ECDSA optimizations that we contributed to OpenSSL, ECDSA is still 6.6 times slower than 1024-bit RSA (which is the most common algorithm used for zone-signing keys). This is a serious problem, because overloading DNS resolvers could potentially slow down the entire Internet.
There’s one very important caveat to all this Algorithm 13 discussion: only 1.5% of web properties support DNSSEC in any capacity. Not all registrars support DNSSEC, and adding support is not trivial. They need to allow their users to upload DS records, which, in turn, need to be uploaded to the registry by the registrar. We’re working to make this an automated process so the registrant doesn’t even need to upload the DS record, but it still requires intervention by the registrar.
The good news is, we’re trending in the right direction. Over the last 12 months, DNSSEC in general has seen a decent amount of growth. And, in the three weeks between our public DNSSEC beta and our Universal DNSSEC announcement, Hover, OVH, Metaname, Internet.bs, and the .NZ registry have added support for Algorithm 13.
We believe that DNSSEC is an essential technology for the modern web and that ECDSA makes global DNSSEC adoption a real possibility. Hopefully, we’ll continue seeing support for Algorithm 13 from registrars and registries, big and small.