DNSSEC : Changement d’algorithme pour la zone .fr

Quelques éléments techniques

Jusqu’à encore récemment l’Afnic utilisait la branche 9.11 de Bind pour les opérations de chiffrement sur les fichiers de zone. Cette branche offrait 2 techniques pour interagir avec les HSM (des boitiers sécurisés à l’intérieur desquels se trouvent les parties privées des clés et qui réalisent toutes les opérations de chiffrement).

La première, historique, utilisait une version modifiée d’OpenSSL et affichait de très bonnes performances. Malheureusement, le support n’était plus assuré et des algorithmes récents n’étaient pas pris en compte (c’est le cas d’ECDSA par exemple). C’est cette méthode que nous avons continué à utiliser pour la zone .fr. Elle a été abandonnée dans les versions plus récentes de Bind.

La seconde méthode, dite native, permet à Bind d’interagir directement avec les drivers PKCS#11 des HSM, sans passer par un intermédiaire (comme OpenSSL). Si celle-ci propose d’utiliser les derniers algorithmes, elle ne gère malheureusement pas correctement le multi-threading avec le type de HSM que nous employons (des modèles AEP KeyperPlus). Il en résulte des performances qui sont particulièrement dégradées. C’est cette méthode que nous utilisions, il y a encore quelques mois pour les zones signées avec des clés de type ECDSA. Du fait de la taille de ces zones et du peu de données à signer, ces mauvaises performances n’étaient pas un frein à la mise en œuvre de cette technologie.

Plus récemment l’ISC a introduit une nouvelle méthode pour assurer l’interaction entre HSM et Bind 9 (les détails, pour ceux qui souhaiteraient l’utiliser se trouvent sur ce blog BIND 9 PKCS11 · Wiki · ISC Open Source Projects / BIND · GitLab). L’idée est de proposer une méthode plug & play qui ne nécessite pas, contrairement aux 2 méthodes précédemment décrites, de re-compiler Bind pour dialoguer avec les HSM. Cette méthode utilise à nouveau OpenSSL mais ce dernier s’interface avec les HSM en utilisant un moteur PKCS#11 développé dans le cadre du projet OpenSC. Celle-ci pourrait être la seule méthode proposée pour les futures versions de Bind. Si elle se veut plus universelle, elle souffre du même problème de performances que la méthode dite native.

Nous avons alors porté ce problème à la connaissance de l’ISC (qui produit Bind) et de notre fournisseur de HSM afin qu’ils investiguent ce cas et nous indiquent s’il existe une possibilité de retrouver des performances à la hauteur de nos attentes. Après de nombreux échanges qui nous ont permis de mieux qualifier celui-ci et d’identifier les points à améliorer, l’ISC a pu engager des ressources pour travailler sur cette partie de code et proposer au projet OpenSC/libp11 plusieurs évolutions à leur produit pour assurer une meilleure gestion du multi-threading et optimiser les interactions avec les HSM. Les traitements étaient incroyablement plus rapides avec un facteur de 3 à 5 par rapport à la version avant modification. Dans le même temps, de nouveaux drivers étaient disponibles pour nos HSM. De notre côté, nous avons aussi amélioré nos process en travaillant sur des mécanismes de pré-traitement, en optimisant la parallélisation de certaines étapes… Résultat, en travaillant sur ces différents axes, les performances sont à nouveau au niveau auquel nous étions en droit de nous attendre.

Au cours des derniers mois, nous avons donc fait évoluer tous nos bancs (celui du .fr y compris). Un des objectifs était d’utiliser une version bien plus récente de Bind (dans la branche 9.16 qui est devenue en juillet le nouvelle version ESV) et cette méthode via OpenSC/libp11 pour signer nos zones.

Pendant ce temps là...

Pendant plusieurs années nous avons pu constater une stagnation du nombre de domaines signés dans la zone .fr. Or, depuis le début de l’année, comme on peut le constater sur le graphique ci-après, l’évolution est repartie nettement à la hausse.

Depuis début 2021, ce sont donc 135 000 domaines supplémentaires qui sont signés portant à près de 15 % du nombre total de .fr (environ 560 000) ceux qui intègrent des enregistrements de type DS.

Cette hausse n’est pas sans conséquences sur notre classement parmi les TLD pour des codes pays (ccTLD) qui mettent en œuvre DNSSEC. Le .fr passe à la 5ème place en termes de nombre d’enregistrements de type DS. On notera que parmi ces 5 TLD, 2 utilisent déjà des clés de type ECDSA.

Concrètement, en simplifiant, pour chaque enregistrement de type DS dans le fichier de zone, 1 enregistrement de type NSEC3 et 2 enregistrements de type RRSIG sont créés. Sur les 12 millions d’enregistrements que contient le fichier de zone .fr (Cf tableau ci-après), plus de 2 millions concernent DNSSEC dont plus d’1 million uniquement pour les signatures.

Cette soudaine recrudescence de données à signer et l’impact sur la taille du fichier de zone sont aussi des éléments qui nous ont confortés dans l’idée de migrer vers ECDSA sans trop tarder maintenant que les performances sont à nouveau au rendez-vous. En effet, lors de la phase de bascule, la zone doit être doublement signée, par une clé RSA et par une clé ECDSA, doublant ainsi le nombre de signatures.

Au niveau des TLD présents dans la racine, la situation a aussi un peu évolué depuis notre annonce de 2020 puisque 41 domaines sont signés avec l’algorithme ECDSA et 2 sont en cours de remplacement (près de 50 % de ces domaines sont opérés par l’Afnic).

La bascule

À l’Afnic, dans le cadre de DNSSEC, nous utilisons OpenDNSSEC pour gérer les cycles de vie des clés. S’il existe aujourd’hui des alternatives pour assurer ce travail, OpenDNSSEC a longtemps été la seule solution « user-friendly » pour assurer ce type de traitement. L’expérience acquise au fil du temps sur cette solution logicielle nous permet d’être sereins quant au bon déroulé des opérations. Le changement d’algorithme n’est pas l’opération la plus simple et même les documents officiels (le RFC 6781 par exemple) laissent une part d’interprétation pour ce genre de process. Dans le cas qui nous intéresse, 2 méthodes sont proposées, l’une dite « libérale », l’autre « conservatrice ».

La différence entre les 2 approches se situe au début et à la fin du process. L’approche « conservatrice » impose que les nouvelles signatures soient publiées avant les nouvelles clés et que les anciennes signatures soient supprimées après avoir supprimé les anciennes clés. C’est cette seule approche qui fut un temps supportée par quelques vieilles mises en œuvre de resolvers validants. Toutefois, les clarifications apportées par le RFC 6840 indiquent que ces resolvers devraient ignorer les signatures produites par des clés qui ne seraient pas présentes dans la zone.

OpenDNSSEC utilise l’approche « libérale » (à ma connaissance, seul l’excellent outil Knot-DNS propose la méthode « conservatrice »). En voici les détails, étape par étape, illustrés grâce à l’outil DNSViz.

Avant l'introduction des nouvelles clés

• Date : 13/07/2021
• Numéro de série de la zone : 2227585342
• La KSK dont le tag est 35095 est utilisée pour signer les clés utilisées dans la zone
• La ZSK dont le tag est 23721 est utilisée pour signer la zone
• Les 2 clés sont de type RSA et de taille 2048 bits
• Taille du fichier de zone : 1,1 Go
• Nombre de signatures : 1116938
• Taille d’une réponse DNS signée pour récupérer l’ensemble des clés : 901 octets
• Taille d’une réponse DNS signée de type NXDOMAIN : 1561 octets

Introduction de 2 nouvelles clés de type ECDSA et des signatures associées

• Date 14/07/2021
• Introduction de la KSK dont le tag est 51508 qui va signer les clés utilisées dans la zone au même titre que la clé 35095
• Introduction de la ZSK dont le tag est 30633 qui va signer la zone au même titre que la clé 23721
• Les 2 nouvelles clés sont de type ECDSA et de taille 512 bits
• Taille du fichier de zone : 1,3 Go
• Nombre de signatures : 2233810
• Taille d’une réponse DNS signée pour récupérer l’ensemble des clés : 1159 octets
• Taille d’une réponse DNS signée de type NXDOMAIN : 1949 octets
• Pour lancer l’étape suivante il faut attendre que ces nouvelles clés et signatures soient récupérées par les resolvers validants qui en auraient besoin

Modifications au niveau de la racine

• Date : 19/07/2021
• Suppression de la DS correspondant à la KSK dont le tag est 35095 (RSA)
• Apparition de la DS correspondant à la KSK dont le tag est 51508 (ECDSA)
• Le numéro de série de la zone de la racine correspondant à ce changement est le 2021071901

Pendant la transition

(certains serveurs ne sont pas encore à jour)

Une fois la transition achevée au niveau des serveurs de la racine

Suppression des 2 anciennes clés RSA et des signatures associées

• Date : 22/07/2021
• Numéro de série de la zone : 2227666100
• Taille du fichier de zone : < 800 Mo (-25 % par rapport aux données du 13/07/2021)
• Nombre de signatures : 1124675
• Taille d’une réponse DNS signée pour récupérer l’ensemble des clés : 317 octets (-65 % par rapport aux données du 13/07/2021)
• Taille d’une réponse DNS signée de type NXDOMAIN : 789 octets (-50 % par rapport aux données du 13/07/2021)