Résolutions 2020: l'Afnic se met à l'elliptique

10 ans... 10 ans que l'Afnic a mis en œuvre la technologie DNSSEC pour l'ensemble des TLD qu'elle opère. Il faut bien l'admettre, même si quelques ajustements sur la taille des clés, leur rôle et la génération du sel ont bien été réalisés tout au long de cette période, aucun changement radical visible pour l'utilisateur n'avait été entrepris jusqu'à ce jour. Certes, nous avons renforcé notre infrastructure et nos process pour minimiser l'impact lié au nombre toujours plus grand du nombre d'enregistrements à signer, fait en sorte qu'aucun incident ne survienne lors des phases délicates de remplacements de clés (tous les 2 ans pour la KSK, tous les 2 mois pour les ZSK) et aussi réalisé une veille active afin de suivre les évolutions en matière de cryptographie pour nous assurer que nous proposions des algorithmes de clés toujours pertinents. Mais depuis quelques temps déjà, nous pensions à passer à autre chose que RSA (algorithme actuellement choisi pour nos ZSK et KSK) afin de limiter l'impact volumétrique lié à DNSSEC sans pour autant diminuer la force cryptographique des clés et des signatures générées.

Concrètement, voici quelques chiffres pour la zone .fr (de loin notre TLD comportant le plus d'enregistrements de type DS et donc de données à signer). 

• Environ 3,5 millions de noms de domaine 
• Un peu plus de 400 000 d'entre eux sont signés 
• Le fichier de zone non signé fait environ 280 Mo, la version signée près de 800 Mo (et encore l'Afnic utilise l'option 'opt out' qui minimise le nombre de signatures). 

Actuellement les clés utilisées pour la zone .fr (et pour nos autres zones) sont de type RSA (RSA-SHA256/8 pour être précis) et de taille 2048 bits (les KSK et les ZSK). Nous souhaitions donc trouver un algorithme apportant a minima le même niveau de sécurité mais ayant un impact moindre sur la taille des fichiers de zone et des réponses aux requêtes DNS.

Quels seraient les bénéfices d'avoir un fichier de zone plus petit et des réponses de taille moindre ?

• Premièrement, lors des opérations nécessitant une génération complète d'un fichier de zone et sa distribution, les opérations de transfert seront plus rapides, le rechargement de la zone dans les serveurs sera plus rapide, de ce fait la synchronisation des différents nuages anycast qui hébergent les TLD que nous opérons sera plus rapide. 
• Avoir des réponses significativement plus petites réduiraient l'impact des attaques de type DDoS qui utiliseraient DNSSEC comme vecteur d'amplification. 
• Recours moindre à la fragmentation IP (ce qui est une manière de contribuer au DNS Flag Day 2020). De fait la diminution du temps de réponses aux requêtes améliore l'UX.
• Moins de données à faire transiter, moins de ressources à utiliser, c'est une manière, même modeste, de diminuer l'empreinte carbone de l'activité DNS. 

Quel algorithme choisir et pourquoi ?

Depuis pas mal d'années déjà, nous avions en ligne de mire les algorithmes à base de courbe elliptiques. Leur adoption (le RFC 6605 sur ECDSA date de 2012 par exemple, celui sur EdDSA, le RFC 8080 de 2017 ) puis leur mise en œuvre dans les différents maillons de la chaîne ont demandé du temps. Il y a encore peu des craintes subsistaient quant au comportement des resolvers qui ne seraient pas à jour face à ce type d'algorithme. Il existe plusieurs algorithmes à base de courbes elliptiques, mais nous avons choisi de nous intéresser à ECDSA (précisément à "ECDSA Curve P-256 with SHA-256"). Cet algorithme "moderne" promet une sécurité supérieure à ce que nous avons mis en œuvre aujourd'hui mais avec une taille de clé et de signature bien plus petite (les experts considèrent qu'une clé ECDSA a un niveau de résistance équivalent à une clé RSA de 3072 bits). En moyenne, une réponse signée à une question DNS sera 3 fois plus petite que son équivalent avec une clé RSA de 2048 bits. Le gain estimé sur la taille du fichier signé pour la zone .fr serait de -33% de celle-ci.

Si nous avons choisi de réaliser cette évolution maintenant, c'est pour plusieurs raisons :

• Le RFC 8624 qui est passé dans l'état 'standard' en juin 2019 place cet algorithme dans la courte liste (2) de ceux qui doivent être mis en œuvre au niveau des logiciels de signature (le second étant celui que nous utilisons). 
• Si dans le petit monde des TLD, c'est RSA qui prédomine largement, au niveau des registrars, c'est ECDSA qui est désormais proposé et devenu pour nombre d'entre eux l'algorithme par défaut. 
• Lors de notre veille, un message diffusé par Viktor Dukhovni en début d'année sur une liste de diffusion a suscité toute notre attention, en voici le contenu 

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 réalise un certain nombre de mesures qui sont hébergées sur le site https://stats.dnssec-tools.org, maintenu par Wes Hardaker. Ces 2 personnes sont bien connues de la communauté DNS des TLD. Voici un graphe, que l'on ne trouve pas sur le site et qui montre bien l'évolution des différents algorithmes (clé de lecture: alg-8 correspond à l'algorithme RSA que nous utilisons, alg-13 correspond à l'algorithme ECDSA. En abscisse, on retrouve des dates au format Année/Mois).

Au niveau des TLD, le constat est un peu différent puisque sur les quelques 1500 TLD annoncés par la racine, un millier utilisent RSA, 140 ne sont toujours pas signés, 8 seulement utilisent ECDSA, les autres (275) utilisent des algorithmes aujourd'hui considérés obsolètes.

Ne voyant plus de frein à cette évolution nous avons donc décidé de passer à la transition à proprement parler. Notre infrastructure aussi bien matérielle que logicielle a été progressivement mise à jour, c'est un travail de longue haleine qui a commencé il y a plus d'un an et qui va s'achever ce mois-ci. Quelques zones que nous gérons ont déjà été migrées (dnssec.fr, nic.fr, nic.re, afnic.fr, afnic.re) et nous ont permis de valider l'ensemble des éléments de notre système. Nous nous proposons de migrer 6 ccTLD que nous opérons (.fr, .re, .pm, .tf, .yt, .wf) au cours de ce premier trimestre. Une fois cette étape réalisée il sera temps de considérer cette évolution pour les gTLD opérés par l'Afnic (.paris, .ovh, ...).