SIDN now also supports cryptographic DNSSEC algorithms 13 and 14

The DNSKEY records are used by SIDN to generate the DS records. A DS record contains a hash value (a digital extract) linking the public (KSK) keys for the relevant .nl domain to the .nl zone. Hence, the cryptographic chain of trust to the root zone is completed.

Public key algorithms

ECDSA (Elliptic Curve Digital Signature Algorithm) is an algorithm for implementation of the public key protocol, as are the more established DSA and RSA algorithms. As its name suggests, ECDSA is based on Elliptic Curve Cryptography (ECC), which has significant advantages in the context of DNSSEC.

The security of all three public key algorithms is based on the mathematical difficulty of calculating discrete logarithms (in complexity terms: 'not calculable in reasonable time'). However, there is a shortcut to cracking the RSA algorithm, namely by dividing the product (multiple) of two large prime numbers back into its factors (prime factorisation). Consequently, RSA is secure to use only if quite long keys are generated, which is undesirable in the context of DNSSEC. DSA was developed by the US government as a free alternative to the proprietary RSA algorithm. When using DSA, it is important to bear in mind that it is extremely vulnerable if a poor random generator is used. The mathematics behind elliptic curve cryptography is much harder to explain than prime factorisation, but for enthusiasts the thinking behind ECC is revealed here by Ars Technica in an accessible way.

Shorter

Of particular importance for DNSSEC is that, while the digital signatures created with ECDSA are the same length as DSA signatures, the public keys are much shorter. For example: a security level of 128 bits — implying that 2128brute force operations are needed to crack the encryption — is currently regarded as a secure minimum. To attain that security level, a public key of 256 bits is required with ECDSA (twice the desired level of security), whereas with DSA and RSA at least 2048 bits are required. With both ECDSA and DSA, the signature length is roughly four times the desired security level (i.e. 512 bits in this example), whereas with RSA it is more than 2048 bits.

For 128 bit security:

Furthermore, ECDSA signatures can be generated much more quickly than RSA signatures (by one order of magnitude) and DSA (by a multiple). Only when it comes to checking ('validating') the signatures is RSA much faster than the other two algorithms; indeed it is an order of magnitude faster than ECDSA. That is the sole (albeit significant) disadvantage of using ECDSA for DNSSEC.

Importance

The differences in algorithmic properties are important for DNSSEC in various ways. First, when ECDSA is used, the length of both the signatures (RRSIG records) and the public keys (DNSKEY records) can be kept to less than 512 bytes. Consequently, the records can be transmitted without switching from traditional DNS packages to (longer) EDNS packages.

Second, with ECDSA, there is only a small size difference between the DNS query (lookup query) and the response. That is significant, because DNSSEC's 'inflation factor' is often exploited in DDoS attacks.

Finally, the generation of a digital signature (signing) requires much less processing power with ECDSA than with RSA. That is a major advantage for registrars and other DNS operators that bulk-sign domains for their clients. The disadvantage on the client side is that it takes longer for a resolver to validate an ECDSA signature. That is significant mainly when DNSSEC is used on a mobile device, which typically has relatively limited computation power and battery capacity.

Recommendations

RFC 6944 makes a number of recommendations regarding the selection and use of the various DNSSEC algorithms. Number 1 (RSA/MD5) should definitely _not_ be used any longer, because the MD5 hash function is known to be insecure. In addition, algorithm number 13 (ECDSA Curve P-256 with SHA-256) and algorithm number 14 (ECDSA Curve P-384 with SHA-384) are recommended in the RFC, as are number 8 (RSA/SHA-256) and number 10 (RSA/SHA-512).

At the moment, there is no recommendation against the use of any of the algorithms based on the SHA-1 hash. Number 3 (DSA/SHA1) and number 6 (DSA-NSEC3-SHA1) are optional, number 5 (RSA/SHA-1) is mandatory, and number 7 (RSASHA1-NSEC3-SHA1) is actually recommended. However, it is inadvisable to use any of those four algorithms. "SHA-1 is too weak", according to Marc Stevens, cryptographer at CWI and famous for cracking MD5 and SHA-1. "The protocol has not been approved by NIST for use in digital signatures since 2011, and with good reason. It's therefore very important that a roadmap for phasing out the use of SHA-1 for DNSSEC is developed as soon as possible."

SHA-1

The authors of RFC 6944 actually recognise that SHA-1 should no longer be used, but mandatory implementation of algorithm number 5 (RSA/SHA-1) is part of the DNSSEC standard, as defined in RFC 4034. Number 5 is cryptographically the same as number 7 (RSASHA1-NSEC3-SHA1) — as are number 3 (DSA/SHA1) and number 6 (DSA-NSEC3-SHA1) — but it does not contain NSEC3 records: a signed denial of existence.

The following table shows that algorithms 5 and 7 together account for half a million keys, or 20 per cent of the total. The registrants in question are advised to switch to more secure alternatives as a matter of urgency.

'White lies'

In 'DNSSEC white lies' (RFCs 4470 and 4471), CDN provider Cloudflare proposes a dynamic successor to NSEC3, where the replies are signed on-the-fly. Cloudflare believes that on-the-fly signing would permanently resolve the issue of name walking. They say that the big difference in signing speed between ECDSA and RSA would make name walking practically impossible.

Cloudflare

According to Marco Davids, Research Engineer at SIDN, the shortness of ECDSA keys was the main reason why Cloudflare opted for algorithm number 13 right from the introduction of DNSSEC at the end of last year. It is because they are in practice standard elements of a DDoS-proof infrastructure that key length was seen as so important. As Cloudflare's DNS specialist Olafur Gudmundsson puts it: "We are fanatical about keeping DNS answers as small as possible."

"When we, SIDN, started offering DNSSEC as a service four years ago, algorithms 13 and 14 had only just become available, recalls Davids. "That's why we didn't adopt them right away. In my view, Cloudflare has made a very sensible choice. It means that they can keep their DNSSEC network packages to less than 512 bytes. What's more, research by Geoff Huston, Chief Scientist at APNIC, indicates that these relatively new algorithms already enjoy a reasonably good level of support from clients. Cloudflare is therefore ahead of most registries and registrars."

Cloudflare has actively promoted support for algorithms 13 and 14 by validating resolvers. Their biggest win has been getting Google to add ECDSA validation to its public DNS service.

Twenty thousand domains

According to Davids, it's estimated that a further twenty thousand Cloudflare-managed .nl domains can now be DNSSEC enabled. "That is the number of domains that Cloudflare has, which are signed but whose ECDSA-based key material couldn't be registered with SIDN until now. Cloudflare users divert their traffic by making their NS records point to the Cloudflare's name servers. Cloudflare has signed the domain names in question, but their customers haven't so far been able to upload the algorithm 13-based DNSKEYs generated by Cloudflare to SIDN.

"With that problem now resolved, Cloudflare users (or their registrars) simply have to register their key material to immediately enable DNSSEC. In the first days after SIDN's announcement, about two hundred .nl domains were spontaneously enabled. And the number now stands at nearly three hundred."

PowerDNS

The makers of PowerDNS are embracing ECDSA as well. From version 4 of this popular DNS server, algorithm 13 is the default. "Users don't have to stick with the default setting if they don't want to, though" explains Senior Engineer Peter van Dijk. "We're also dropping the distinction between KSKs and ZSKs; from now on we'll generate just one key pair, known as the 'Combined Signed Key'. The new key has the SEP flag set and therefore looks like a KSK, but it's the only key we'll be using.

"The two developments are linked, says Van Dijk. "A short ECDSA key is stronger than a 2048-bit RSA key based on algorithm 8, so we can make the switch without compromising on security. What's more, the shorter keys mean that the response packages are significantly smaller."

Crypto Suite B

Both DNSSEC algorithm 13 and algorithm 14 are based on ECDSA. However, algorithm 14 generates longer keys (384 bits, as opposed to 256) making it suitable for use where extreme security is required. Nevertheless, for the time being algorithm 14 is unlikely to be used much, because the longer keys and signatures underpinning the additional security require additional processing power and generate more traffic.

Finally, it is worth pointing out that ECDSA is part of the NSA-developed and NIST-standardised Suite B body of crypto-protocols. Regardless of whether that constitutes a recommendation or not, given that the two US organisations in question are regularly accused of building backdoors into their products, the protocol suite is in line to be replaced. The NSA regards the algorithms as increasingly vulnerable to quantum attacks and is currently working on the successor to Suite B.

Ongoing debate

The DNSSEC community is currently debating the merit of using ECC to further enhance the protocol. A list of meetings scheduled for the next few weeks is available here.