Resolutions for 2020: Afnic goes elliptic

10 years... 10 years that Afnic has been using DNSSEC technology for all the TLDs it operates. It must be admitted, although some adjustments have been made to the size of the keys, their role and the generation of salts throughout this period, no visible radical change for the user had been undertaken until now. We have of course strengthened our infrastructure and our processes in order to minimise the impact of the ever greater number of registrations to be signed, made sure that no incidents occur during the delicate key replacement phases (every two years for KSKs, every two months for ZSKs) and kept an active watch on developments in the field of cryptography in order to make sure we always offered pertinent key algorithms. But for some time now we had been thinking of moving away from RSA (the algorithm currently used for our ZSKs and KSKs) in order to limit the volume impact of DNSSEC without diminishing the cryptographic strength of the keys and signatures generated.

Specifically, here are some figures for the .fr zone (by far our TLD with the most DS resource records and therefore data to sign).

• Approximately 3.5 million domain names 
• Just over 400,000 of them are signed 
• The unsigned zone file is about 280 Mo, the signed version nearly 800 Mo (even though Afnic uses the 'opt out' option which minimises the number of signatures). 

At present the keys used for the .fr zone (and for our other zones) are of the RSA type (RSA-SHA256/8 to be exact) and their size is 2,048 bits (both KSKs and ZSKs). We therefore wish to find an algorithm that will provide at least the same level of security but with less impact on the size of the files for the zone and for responses to DNS requests.

What would be the advantages of having a smaller zone file and smaller responses?

• Firstly, with operations requiring the complete generation of a zone file and its distribution, transfer operations would be faster, and so would reloading the zone in the servers, and as a result the synchronisation of the various anycast clouds that host the TLDs we manage would also be faster. 
• Having significantly smaller responses would reduce the impact of DDoS type attacks using DNSSEC as their amplification vector. • Less recourse to IP fragmentation (which is a way of contributing to DNS Flag Day 2020). In fact the reduction in response times to requests improves the UX.
• Having fewer data to transmit and using fewer resources is a way, albeit modest, of reducing the carbon footprint of the DNS activity. 

Which algorithm to choose, and why?

For some years we have had our eye on elliptic curve-based algorithms. Their adoption (RFC 6605 on ECDSA dates from 2012 for example, that on EdDSA, RFC 8080 from 2017) and their implementation in the various links of the chain have taken time. Until recently there were concerns about the behaviour of resolvers which it was feared might not be up to date in the face of this type of algorithm. There are several elliptic curve based algorithms, but we have decided to go for ECDSA (more specifically “ECDSA Curve P-256 with SHA-256”). This “modern” algorithm promises superior security to that which we currently have in place but with far smaller key and signature size (the experts consider that an ECDSA key has a level of resistance equivalent to an RSA key of 3,072 bits). On average, a signed response to a DNS question will be just one third the size of its equivalent with a 2,048 bit RSA key. The estimated gain in the size of the signed file for the .fr zone would be 33%.

There are several reasons for our having decided to make this change now:

• RFC 8624, which acquired ‘standard’ status in June 2019, places this algorithm on the shortlist (2) of those that must be implemented at the level of signature software applications (the other one being the one we use). 
• While RSA is predominant in the small world of TLDs, at the level of the registrars, it is ECDSA that is now offered and that has become the default algorithm for many of them. 
• While we were conducting our surveillance, a message broadcast by Viktor Dukhovni at the beginning of the year on an electronic mailing list caught our attention. Here is the content: 

With daily updates at https://stats.dnssec-tools.org I decided some time back that it no longer made sense to post monthly updates to this list, but perhaps a short annual note is not out of place. Some highlights for this year are:

- 10.70 million signed delegations, up from ~8.77 million a year ago. + 1.50 million signed .COM delegations, up from ~973 thousand. + 97 TLDs with 1000+ signed delegations, up from 76.

- 1.73 million DANE SMTP domains, up from ~775 thousand a year ago. + DANE MX hosts in 5.0 thousand zones, up from ~3.8 thousand.

- ECDSA P256 (13) now most common KSK algorithm, ahead of RSASHA256 (8). + Last year: 4,005,976 alg 8; 1,908,218 alg 13. + This year: 3,798,256 alg 8; 3,937,115 alg 13.

Viktor Dukhovni makes a number of measurements which are hosted on https://stats.dnssec-tools.org, a website maintained by Wes Hardaker. These two people are well known in the DNS community of TLDs. Here is a graph, which is not on the website, showing how the various algorithms have evolved (legend: alg-8 is the RSA algorithm that we use, alg-13 is the ECDSA algorithm. The horizontal axis shows dates in year/month format).

At the level of TLDs, the findings are somewhat different, since of the approximately 1,500 TLDs announced by their root, 1,000 use RSA, 140 are not yet signed and only eight use ECDSA, the remainder (275) using algorithms now considered obsolete.

We no longer see any impediment to this evolution and have therefore decided on effective transition. Our infrastructure, both hardware and software, has been progressively updated. This is a long-haul project which started more than a year ago and which will be completed this month. Some zones that we manage have already been migrated (dnssec.fr, nic.fr, nic.re, afnic.fr and afnic.re) enabling us to validate all the elements of our system. We propose to migrate six ccTLDs that we manage (.fr, .re, .pm, .tf, .yt and .wf) during this first quarter. Once this stage has been completed it will be time to consider this evolution for the gTLDs managed by Afnic (.paris, .ovh, etc.)