EdDSA-based algorithms for DNSSEC under development

Digital signatures in the DNSSEC protocol

The DNSSEC protocol is based entirely on digital signatures. Digital signatures (RRSIG records) attached to DNS responses (RRsets) confirm the authenticity of those responses. A digital signature (DS record) attached to the signer's public key (#1) (DNSKEY record) confirms the authenticity of the signer's signatures. And a digital signature attached to the public key (#2) of the signer of that public key (#1) confirms the authenticity of that public key (#2). Hence, a 'chain of trust' is created within the existing DNS infrastructure, anchored in the root zone. In the root, the final signature in the chain is attached using a key pair that is by definition trustworthy. That pair's public key is built into all resolver software in the form of a trust anchor.

The diagram below shows how the chain of trust leading to the root zone is built up for the domain name example.nl.

Public and private keys

Digital signatures are in turn based on public-key cryptography and hash functions. First, a hash (a digital extract) of an electronic document (in this case an RRset) is created. The hash is then encrypted using a private key. The result is a digital signature specific to that document.

Each private (i.e. secret) key is paired with a public key (i.e. a key that is available to anyone; in this case a DNSKEY record). Anyone can use the public key to verify that the relevant signature does indeed belong to the particular document and therefore must have been attached by the owner of the public key (as the only party who knows the associated private key).

Pubkey algorithms and hash functions

Various algorithms are available both for creating hashes and for public-key cryptography. DNSSEC supports various combinations of hashing algorithm and cryptography algorithm. So, before signing your zones, you have to choose what combination of pubkey algorithm and hash function to use.

Separately, you have to choose which hash function to use for the DS/CDS records.

About 15 cryptographic hash/pubkey combinations are defined for use in DNSSEC. A comprehensive list is available on IANA's website:

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

Over time, some established algorithms become 'deprecated' (i.e. regarded as obsolete, on account of being outdated or insecure) and new algorithms are added. Where DNSSEC is concerned, the latest developments in (applied) cryptography are reflected in RFC 8624, the successor to RFC 6944.

RFC 8624 recommendations

RFC 8624 makes a number of recommendations regarding the selection and use of the various DNSSEC algorithms:

• Algorithm number 13 (ECDSA Curve P-256 with SHA-256) is recommended.

• Alongside number 8 (RSA/SHA-256), which was the standard for a long time but is now slowly being phased out in favour of the ECDSA-based algorithms.

• Number 10 (RSA/SHA-512), a variant of number 8, has never gained popularity, and its use is now discouraged.

• Number 14 (ECDSA Curve P-384 with SHA-384) is a stronger version of number 13, but isn't needed yet.

• However, it is likely that, in due course, number 13 will be succeeded not by number 14 but by an EdDSA-based algorithm (number 15, Ed25519).

To sum up, if you are implementing DNSSEC now, use algorithm 13. However, if you're already using DNSSEC on the basis of algorithm number 8 (or an older algorithm), you are advised to switch to number 13 before too long.

The various algorithms are considered more closely below.

Unsuitable for continued use

Algorithm number 1 (RSA/MD5) should definitely not be used any longer, because the MD5 hash function is known to be insecure.

The SHA-1 hash function has not been approved by NIST for use in digital signatures since 2011. "SHA-1 is too weak," says Marc Stevens, cryptographer at CWI and famous for cracking MD5 and SHA-1.

Use of that hash function for DNSSEC is now formally discouraged (in RFC 8624). The algorithms to be avoided are therefore numbers 3 (DSA/SHA1), 5 (RSA/SHA-1), 6 (DSA-NSEC3-SHA1) and 7 (RSASHA1-NSEC3-SHA1).

Algorithms 8 and 10 are both based on the SHA-2 hash function, which is definitely secure at the present time. For a long time, number 8 (RSA/SHA-256) was the standard, but it is now slowly being phased out in favour of the ECDSA-based algorithms. Number 10 (RSA/SHA-512), a variant of number 8, has never gained popularity, and its use is now discouraged (in RFC 8624).

The various public-key algorithms

The security of the various public-key algorithms – DSA, RSA and ECDSA – 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 2 large prime numbers back into its factors (prime factorisation). Consequently, RSA is secure to use only if quite long keys are generated, which makes this algorithm less suitable for use 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.

Advantages of ECDSA

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.

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 2¹²⁸ 'brute 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 2,048 bits are required. With both ECDSA and DSA, the signature length is roughly 4 times the desired security level (i.e. 512 bits in this example), whereas with RSA the signature length is more than 2,048 bits.

For 128-bits security:

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

Best choice

The differences in algorithmic properties considered above mean that ECDSA is currently the best choice for DNSSEC. First, the length of both the digital signatures (RRSIG records) and the public keys (DNSKEY records) can be kept to less than 512 bytes. Consequently, the records can be transported without switching from traditional DNS packets to (longer) EDNS packets.

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/amplification 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.

ECDSA-based algorithms in the .nl zone

Since March 2016, registrars have been able to provide SIDN with DNSKEY records based on algorithms 13 and 14 for publication in the .nl zone (in the form of hash values in DS records). Consequently, registrars are able to sign their clients' domains using ECDSA.

Since support for those algorithms was added, it's been possible to enable DNSSEC protection for .nl domain names hosted by Cloudflare, of which there are about 20,000. Cloudflare is a CDN provider that from the start used algorithm 13 by default to sign its clients' domain names.

Algorithms 13 and 14 are now also widely supported both on the client (resolver) side and on the server side. As the following graph shows, algorithm 7 has now largely disappeared from the .nl zone, while algorithm 8 is gradually being displaced by algorithm 13. By February 2023, 57 per cent of DNSSEC-enabled .nl domain names were using algorithm 13, and 43 per cent were using algorithm 8.

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/fb08db89265df917e7bca30c2ecdb36b/stats.sidnlabs.nl-DNSSECalgorithms-20240826.png

At the time of writing, February 2023, we are still using algorithm 8 for the .nl top-level domain. However, we intend to migrate to algorithm 13 later this year.

ECDSA algorithm 14

Both DNSSEC algorithm number 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, algorithm 14 isn't used much, because the longer keys and signatures underpinning the additional security require additional processing power and generate more traffic. In February 2023, a mere 0.05 per cent of DNSSEC-enabled .nl domain names were using algorithm 14. Furthermore, we expect that in due course, algorithm 13 will be succeeded not by algorithm 14, but by an EdDSA-based algorithm (number 15, Ed25519; see above).

ECDSA and the future of DNSSEC

The big difference in signing speed between ECDSA and RSA means that in the future it will probably be possible to generate a digital signature for a denial-of-existence on-the-fly – in other words, as part of the DNS response composition process. That will provide a dynamic alternative to NSEC(3), definitively resolving the security problem of 'zone walking'.

This 'DNSSEC white lies' technology (see RFCs 4470 and 4471) is propagated mainly by CDN provider Cloudflare.

EdDSA-based algorithms

The EdDSA algorithm (Edwards-curve Digital Signature Algorithm) is a relative newcomer to the world of DNSSEC. Technically speaking, EdDSA is very similar to ECDSA. However, as the name suggests, EdDSA uses 'twisted Edwards curves', a particular variant of the mathematics underpinning Elliptic-Curve Cryptography (ECC).

DNSSEC algorithms 15 and 16 (defined in RFC 8080) use the Ed25519 and Ed448 cryptographic constructions (defined in RFCs 8032 and 7748). The first of those constructions combines elliptic curve Curve 25519 with the SHA-512 hash function, resulting in a very fast public-key algorithm. Ed448 does the same using Curve 448 and SHA-3 (in this case, the SHAKE256 variant).

Like algorithm 13 (ECDSA Curve P-256 with SHA-256), Ed25519 (algorithm 15) provides 128-bit security (the current norm) on the basis of a 256-bit private key, plus a 512-bit public key and 512-bit signatures. With a key length of 448 bits and 224-bit security, Ed448 (algorithm 16) is the EdDSA-based equivalent of algorithm 14 (ECDSA Curve P-384 with SHA-384).

For DNSSEC, EdDSA-based cryptography has the same benefits over DSA and RSA that ECDSA has, while also being simpler, slightly faster and less vulnerable to (side-channel) attacks than ECDSA.

EdDSA-based algorithms in the .nl zone

Although the large-scale operational use of algorithms 15 (Ed25519) and 16 (Ed448) is regarded as premature at the present time (February 2023), it is possible to deploy them in the .nl zone.

Registrars can definitely provide SIDN with DNSKEY records based on algorithms 15 and 16 for publication in the .nl zone (in the form of hash values in DS records). In principle, therefore, registrars can also sign their clients' domains using EdDSA.

RFC 8624 (published in June 2019) describes the implementation of algorithms 15 and 16 in resolvers, and the implementation of algorithm 15 in name servers, as 'recommended'. As a result, support for EdDSA-based algorithms will be incorporated into DNS software in the years ahead. However, until that support is realised, it would be premature to make large-scale operational use of the algorithms. According to DNSThought statistics, 85 per cent of validating resolvers currently support algorithm 15. However, where the .nl zone is concerned, a negligible 0.01 per cent of domain names are using algorithm 15.

Hash functions for DS/CDS records

Finally, RFC 8524 also makes recommendations regarding the hash function to be used in DS/CDS record generation:

• Only a handful of algorithms are currently defined. A comprehensive list is available on IANA's website: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

• Hash algorithm 2 (SHA-256) is recommended.

• Hash algorithm 1 (SHA-1) is still in widespread use, but should now be replaced by number 2.

• Hash algorithm 4 (SHA-384) is a stronger version of number 2, but isn't needed yet.

To sum up, if you are implementing DNSSEC now, use hash algorithm 2. If, on the other hand, you're already using DNSSEC on the basis of hash algorithm 1, you are advised to switch to number 2.