DNSSEC : Changement d’algorithme pour la zone .fr

Il y a déjà 18 mois de cela nous présentions à travers un article (lire ici) une évolution concernant l’algorithme des clés utilisées pour signer les zones des domaines de premier niveau (TLD) que l’Afnic opère. Dans les mois qui ont suivi, l’ensemble de ceux-ci ont vu les clés RSA-SHA256 (algorithme numéro 8, appelé simplement RSA dans la suite de ce billet) remplacées par des clés de type ECDSAP256SHA256 (algorithme numéro 13, simplement noté ECDSA par la suite).

Tous à l’exception du .fr.

Pourtant toutes ces migrations se sont passées sans incidents, les évolutions logicielles et matérielles pour assurer ces opérations ont permis de montrer que les solutions adoptées étaient sûres et répondaient bien aux attentes. Mais si fonctionnellement tout se passait correctement, il restait malgré tout un point noir : les performances dégradées de la chaîne assurant la signature par rapport à celle que nous utilisions pour les clés de type RSA.

Ces mauvaises performances sont toutes relatives puisque lors des mises à jour des fichiers de zones qui ont lieux toutes les 10 minutes, seules les données modifiées font l’objet d’un traitement et nécessitent des opérations de signatures. Dans ce contexte, ce type de mise à jour ne prend qu’une poignée de secondes et il eut été acceptable que celui-ci prenne 10 fois plus de temps, cela n’aurait pas été perceptible. Par contre nous avons aussi une procédure, que nous utilisons peu certes, qui est nécessaire en cas de problème lors de la publication des fichiers de zone et qui va permettre une génération à partir de zéro avec éventuellement re-création de l’ensemble des signatures. Pour le .fr, compte tenu de sa volumétrie et des tests de validation qui sont réalisés, il faut compter une trentaine de minutes avec des clés de type RSA mais près de 6 heures avec des clés de type ECDSA, ce qui n’est pas acceptable. C’est la raison pour laquelle nous avions pris la décision de repousser la migration du .fr, le temps de trouver une solution raisonnable.

Aujourd’hui, nous sommes en mesure de dire que cette solution a été trouvée et c’est pour cela que nous pouvons assurer le changement d’algorithme des clés de 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.

TLD	# de DS dans la zone	Algorithme, taille des clés KSK/ZSK
nl	3478676	RSA-SHA256 2048/1024
se	770352	RSA-SHA256 2048/2048
br	751947	ECDSA 512/512
cz	739537	ECDSA 512/512
fr	539786	RSA-SHA256 2048/2048 → ECDSA 512/512

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.

#	Type d’enregistrement
9640636	NS
1115961	RRSIG
594369	DS
557986	NSEC3
13974	A
746	AAAA
[…]

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)