DENIC Supports Additional Cryptographic Algorithms for DNSSEC Domains under .de
With GOST (algorithm 12) and ECDSA (algorithms 13 and 14), DENIC now supports three additional algorithms to be used for the keys of DNSSEC domains. For the first time, the currently supported public key algorithms – DSA/SHA1 (3), RSA/SHA-1 (5), DSA-NSEC3-SHA1 (6), RSASHA1-NSEC3-SHA1 (7), RSA/SHA-256 (8), RSA/SHA-512 (10) – now are supplemented by cryptographic algorithms that are based on elliptic curves (ECC). Thus, DENIC once again supports the complete range of signing procedures specified and not flagged as obsolete by the IETF (Internet Engineering Task Force).
A great advantage of elliptic curves is their much higher cryptographic strength with identical key length compared to RSA. In practice, this results in considerably shorter keys and signatures. While RSA uses keys and signatures 1024 or 2048 bits long, ECDSA only needs 256 and 384 bits. This results in the following byte values for the DNSKEY and RRSIG records:
1024 RSA 2048 RSA ECDSA256 ECDSA384
DNSKEY 148 276 80 112
RRSIG 172 300 95 125
But it is not the savings in bandwidth that make shorter DNS (response) packets so interesting. What is more important is the reduced potential forf DNS amplification attacks and last but not least the prevented packed fragmentation. This in turn, helps to avoid that answers get lost due to (excessive) filtering.
When key material is received, DENIC implements the so-called Predelegation Checks. Next to the answers by the name servers, this check verifies a successful DNSSEC validation. On the one hand, this approach is in line with the good practice applied by certificate authorities ("Proof of Possession"), on the other hand it prevents errors that will make the domain inaccessible. For the purpose of this validation, DENIC has extended its software by the new algorithms and added the corresponding functions to the open source libraries that are used. They have been published as NAST version 220.127.116.11.
Security technologies like DNSSEC, which are developed in and specified by the IETF, offer a feature referred to as "algorithm agility". Due to this agility, it is possible to respond to technical and cryptographic evolutions without touching the actual protocol – here DNSSEC – and to implement new security requirements with this very protocol.
RSA has become the public key algorithm of choice for DNSSEC and other technologies because it is widespread, has appropriate characteristics and because there are hardly any more promising alternatives.
However, for some time, a new public key technology, which is based on elliptic curves (ECC), has been gaining ground. Next to a number of RSA variants (more precisely, RSA with different hash algorithms), the IETF has specified three solutions based on elliptic curves:
GOST R 34.10-2001 with GOST R 34.11-94 (12) (RFC 5933)
ECDSA on curve P-256 with SHA-256 (13) (RFC 6605)
ECDSA on curve P-384 with SHA-384 (14) (RFC 6605)
With immediate effect, key material for DNSSEC-secured .de domains can be registered for these three algorithms, too. Thus, DENIC once again supports the complete range of signing algorithms specified by the IETF and not flagged as obsolete.
However, validating signatures with ECC requires considerably more resources than a validation with RSA. Consequently, the load of the validating resolver is higher. Also, research shows that ECC is not yet supported by all validating resolvers. Such systems would treat a domain signed (exclusively) by ECC as an unsigned domain. But the number of ECC-enabled validating resolvers is increasing.
One can also expect a development with regard to the technical details of the available curves. At present, the IETF and its academic kin, the Internet Research Task Force (IRTF), are investigating, among other things, the "curve 25519" or rather the "Ed25519" signing system based on it. Moreover, a standardization proposal for using "brainpool" curves has been submitted.
Given these reasons, DENIC will continue to use the well-established RSA algorithm for its own zones, in particular for the .de zone.