Bonnes pratiques : Maintenir à niveau son infrastructure DNSSEC

La sécurité d’Internet est aujourd’hui une préoccupation majeure pour tous les acteurs de l’Internet. L’évolution des technologies exige désormais une approche plus stratégique en matière de sécurité. Dans ce sens, DNSSEC (Domain Name System Security Extensions) est l’un des protocoles clés pour garantir l’intégrité et l’authenticité des données.

DNSSEC va prochainement fêter ses 20 ans (RFC 4033/4034/4035 publiées en mars 2005) mais ce n’est véritablement qu’au moment de la signature de la racine en juillet 2010 que le déploiement de la technologie a pu être lancé. Les opérateurs de noms de domaine (dont l’Afnic) réalisaient déjà des expérimentations bien avant cette date, ils étaient donc prêts. Cela a permis d’accélérer la signature les domaines de premier niveau, d’établir les chaînes de confiance depuis la racine et d’offrir à nos communautés respectives, la possibilité de signer à leur tour leurs propres zones.

Nous ne reviendrons pas ici en détails sur la technologie DNSSEC elle-même, l’Afnic a déjà écrit plusieurs billets sur le sujet, un dossier thématique, une documentation de déploiement complète et propose aussi une formation dédiée. Ce billet s’adresse en priorité à ceux qui ont déjà sauté le pas, à ceux qui se posent des questions sur la suite, … « Oui, j’ai signé ma zone, mais ensuite ? »

Signer sa zone n’est pas une fin en soi, mais c’est bien souvent le point de départ d’un long parcours. Si, il y a 15 ans, cette opération pouvait représenter un challenge, force est de constater qu’aujourd’hui les choses sont beaucoup plus simples. L’évolution des outils qui proposent des fonctionnalités plus faciles d’usage et éprouvées d’une part, les partages d’expérience et la diffusion de la connaissance à un public de plus en plus large d’autre part, ont simplifié l’adoption de cette technologie.

Certes, mais une fois signée, quels sont les aspects de DNSSEC à surveiller, à faire évoluer, quelles sont les questions à se poser ?

• Est-ce que les algorithmes des clés utilisés il y a 15 ans sont toujours aussi pertinents ?
• Est-ce que les paramétrages recommandés au lancement de DNSSEC n’ont pas évolués ?
• Est-ce que cela sert vraiment de changer de clés régulièrement ?
• Faut-il s’inquiéter de l’impact des travaux sur les ordinateurs quantiques sur les méthodes de chiffrement actuelles ? Peut-on s’y préparer ?

C’est ce genre de considérations que nous allons aborder ici en tentant d’y apporter des réponses et en proposant des actions à réaliser pour que les zones signées restent à la pointe des dernières recommandations en la matière. Pour cela nous allons nous appuyer sur différents documents de référence, en particulier la RFC 8624 (Algorithm Implementation Requirements and Usage Guidance for DNSSEC), publiée en 2019 et qui spécifie quels algorithmes existants ne devraient plus être utilisés et ceux qu’il faudrait privilégier. La cryptographie étant une science en perpétuelle évolution, une nouvelle version de cette RFC est déjà en cours d’adoption au sein de l’IETF (draft-ietf-dnsop-rfc8624-bis).

Les algorithmes de signature à choisir en 2024

Voici l’état de l’art en termes d’algorithmes recommandés (paragraphe 3.1 de la RFC 8624)

Si les algorithmes de cryptographie tels que RSA-MD5, DSA et SHA-1 ont longtemps été utilisés dans le domaine de la sécurité informatique, leur utilisation n’est plus considérée comme fiable et efficace en raison de leur vulnérabilité. De la même manière, l’algorithme GOST R 34.10-2001 (mnémonique ECC-GOST) qui a été rendu obsolète en 2012 n’est pas non plus conseillé. Le cas de RSASHA512 est un peu différent, puisqu’il est considéré tout aussi efficace que RSASHA256, mais dans les faits, il est très peu utilisé et le gain de sécurité vis à à vis de RSASHA256 ne justifie pas la présence de 2 algorithmes aux propriétés similaires.

À l’Afnic, nous considérons que seuls les algorithmes dont le status est « MUST », « RECOMMENDED » et « MAY » devraient être utilisés pour signer. Ce qui laisse malgré tout la possibilité de choisir parmi 5 algorithmes, à savoir : RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), ED25519 (15), ED448 (16).

Dans les faits, c’est déjà le cas pour 99% des zones signées dans les TLDs que nous opérons. C’est une très bonne chose, mais que risquent les utilisateurs qui opèrent le 1% restant ?

Au-delà de l’aspect fiabilité et efficacité évoqué un peu plus haut, utiliser des algorithmes désignés comme étant obsolètes vous expose au fait qu’ils ne seront plus utilisables dans tout ou partie du système dans un futur proche. Par exemple, si vous utilisez l’outil Bind de l’ISC sur un OS récent tel que RHEL9 et ses dérivés, vous pourriez être surpris par le résultat de certaines commandes.

Essayons par exemple de créer une clé pour la zone fr en choisissant l’algorithme RSASHA1-NSEC3-SHA1 (7) :

> dnssec-keygen -a NSEC3RSASHA1 -b 1024 fr
dnssec-keygen: fatal: unsupported algorithm: NSEC3RSASHA1

Cela signifie que si un administrateur utilise cet algorithme sur un OS RHEL8 et qu’il souhaite réaliser une montée en version de son système vers RHEL9, il faudra au préalable qu’il réalise un changement d’algorithme de ses clés afin de pouvoir continuer à appliquer ses procédures de gestion de clés/signatures sur le système mis à jour.

Pour le moment, nous n’interdisons (pas encore) formellement les algorithmes déconseillés par la RFC 8624, mais ce que nous appliquons depuis quelques mois c’est que si un de ces algorithmes n’est plus du tout utilisé dans une zone opérée, nous le supprimons de la liste des algorithmes sélectionnables lors de l’ajout d’en enregistrement de type DS pour cette zone. Par exemple, si pour un domaine dans la zone fr, il est encore possible d’utiliser la quasi-totalité des algorithmes listés plus haut, pour les domaines de la zone museum, seuls les 5 algorithmes acceptables sont sélectionnables.

Conseils de l'Afnic :

• Si votre zone est signée avec un algorithme autre que RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), ED25519 (15) ou ED448 (16), opérez prochainement un changement de clés en choisissant un algorithme dans la liste proposée.
• Les algorithmes à base de courbes elliptiques présentent un certain nombre d’avantages par rapport aux algorithmes de type RSA. Le choix vers un nouvel algorithme devrait se porter vers ECDSAP256SHA256 (13), c’est celui utilisé par l’Afnic et par de nombreux opérateurs de TLD, ou bien ED25519 (15) qui est pressenti pour devenir le prochain algorithme privilégié.

Paramétrages pour la preuve de non existence

Ce sujet a déjà fait l’objet d’un billet (RFC 9276, l’Afnic adopte le régime sans sel) et si vous n’êtes pas familier avec ce concept et les enregistrements de type NSEC/NSEC3, nous vous encourageons à le relire.

En résumé, NSEC3 propose une technique de preuve de non existence (RFC5155) qui, contrairement à NSEC, ne s’appuie pas sur des noms de domaine existants, mais utilise un résumé cryptographique dont le calcul peut être contrôlé à l’aide de plusieurs paramètres. L’un va permettre de définir le nombre de fois que ce calcul de résumé sera appliqué (en plus de l’itération initiale), l’autre permet d’ajouter un aléas (sel) dans le calcul de ce résumé cryptographique. Plusieurs études ont par la suite démontrées que le gain de sécurité apporté par ces variations n’étaient pas significatif eu égard au coût qu’entrainent ces calculs supplémentaires au niveau des systèmes de résolution DNS.

De plus, des travaux récents, ont permis de constater que ces traitements supplémentaires peuvent être utilisées à des fin d’attaque contre les résolveurs DNS en provoquant l’épuisement des ressources de celui-ci (CPU, mémoire). Un utilisateur malveillant pourrait configurer à dessein une zone (ou en repérer une existante) avec un paramétrage NSEC3 excessif (des milliers d’itérations, un sel de longueur maximale de 255). Ensuite un volume important de requêtes sur des noms de domaines non existants de cette zone, demanderait au résolveur de réaliser un nombre disproportionné de calculs pour répondre à celles-ci. Ce type d’attaque a fait l’objet d’une CVE (CVE-2023-50868).

La bonne nouvelle, c’est que l’on peut observer que les recommandations sur le paramétrage permettant le calcul du résumé cryptographique utilisé dans l’enregistrement de type NSEC3 ont été largement suivies. En effet si en 2022, moins de 2% des zones signées dans la zone .fr et ayant choisi NSEC3 se conformaient à ces règles, aujourd’hui, on atteint presque les 90%. Reste un peu plus de 10% de zones qui utilisent des valeurs parfois extravagantes pour le nombre d’itérations

Conseil de l'Afnic :

• En cas d’utilisation de NSEC3, se conformer aux recommandations de la RFC 9276.

Choix d'un bon algorithme pour la DS publiée dans la zone parente

En plus des algorithmes de clés DNSSEC, la RFC 8624 fournit aussi des recommandations sur le choix de l’algorithme pour l’enregistrement de type DS publié par la zone parente (les zones opérées par l’Afnic dans ce cas précis). Sachant qu’il y avait, déjà, à l’origine, beaucoup moins de choix que pour les clés, le tableau proposé laisse assez peu d’alternatives.

Dans les faits, seul le choix SHA-256 (2) semble raisonnable. La logique voudrait que les enregistrements DS de type SHA-1 (1) soient très minoritaires dans la mesure où dès 2006, date de publication introduisant un nouveau type d’algorithme (SHA-256), on pouvait lire dans la RFC 4509 :

Implementations MUST support the use of the SHA-256 algorithm in DSRRs. Validator implementations SHOULD ignore DS RRs containing SHA-1 digests if DS RRs with SHA-256 digests are present in the DS RRset.

S’il est vrai, que, pendant plusieurs années, l’habitude était d’avoir systématiquement 2 DS par KSK, en l’occurrence une de type SHA-1 et une de type SHA-256, aujourd’hui les choses ont bien changé puisque dans de très nombreux cas, seuls les DS de type SHA-256 sont présentes. Par exemple, au niveau du fichier de zone de la racine, on peut constater que 98% des TLD ne publient que des DS de type SHA-256.

Au niveau de l’Afnic et en particulier de la zone fr, 99,5% des domaines qui ont un enregistrement de type DS en ont au moins un de type SHA-256. Par contre, quelques dizaines de milliers de ces domaines ont aussi une DS de type SHA-1.

Contrairement aux clés utilisées pour signer les zones, il serait toutefois possible pour l’Afnic de réaliser une opération de nettoyage pour faire disparaître les DS de type SHA-1. Cela pourrait se dérouler selon plusieurs étapes :

• Pour les domaines ayant une DS de type SHA-256 et une de type SHA-1, après vérification que les 2 références la même clé, suppression dans les fichiers de zone de l’Afnic des DS de type SHA-1 de ces domaines.
• Pour les domaines n’ayant qu’une DS de type SHA-1, création de d’une nouvelle DS de type SHA-256 dans un premier temps puis quelques temps plus tard, suppression de la DS de type SHA-1.

Une analyse des données actuelle montre qu’à part de très rares exceptions (zones incorrectement signées), l’ensemble des domaines pourraient se voir appliquer cet algorithme de nettoyage des DS de type SHA-1.

Ceci étant, ce type d’opération n’est pas encore planifiée. Mais d’autres registres ont eu des approches similaires avec succès.

Puisque l’on évoque les DS, il convient d’ajouter que lors des analyses des données, nous avons observé quelques rares cas où des domaines étaient associés à 5 ou 6 DS. Si aujourd’hui, rien n’interdit ce type de pratique il est important de savoir que des travaux sont en cours pour définir une limite claire (il n’y en a pas dans les RFC actuelles) et que le nombre de 3 DS a été plusieurs fois évoqué. Rien n’indique que ce sera cette valeur qui sera choisie, mais, si jamais un jour ce type de zone devait se comporter de manière inhabituelle lors de la validation DNSSEC, vérifiez bien qu’une nouvelle règle en la matière n’a pas été mise en œuvre.

Conseils de l'Afnic :

• Supprimez/remplacez les enregistrement DS de type SHA-1/GOST. Privilégiez le type SHA-256.
• Limitez le nombre d’enregistrements de type DS à 3 (En dehors des changements de KSK, un est en général suffisant pour la grande majorité des zones qui n’utilisent pas de KSK en standby).

Le cas de la racine

La racine a été signée en 2010, ce qui a permis de réellement activer la validation au niveau des résolveurs. La clé générée à l’époque (référencée sous le nom de KSK-2010 et ayant pour keytag 19036) a été utilisée jusqu’en octobre 2018. Il a donc fallu attendre 8 ans pour que le premier remplacement de KSK soit finalisé. En 2016, la clé KSK-2017 (keytag 20326) qui devait remplacer KSK-2010 a été générée et a donc été activée en 2018. L’algorithme utilisé pour la clé (RSASHA256) a été conservé car il ne faisait pas l’objet de remises en causes particulières et les algorithmes à base de courbe elliptiques étaient encore trop récents et leur prise en charge dans les serveurs DNS n’était pas généralisée. En tout cas c’était un point d’interrogation à l’époque et personne ne s’est offusqué de ce choix, d’autant que ce changement de clés était une première pour la racine et s’est déroulé sans perturber Internet.

C’est cette crainte, de perturber l’Internet, qui fait que le délai a été aussi long. Par la suite, il y a eu de nombreuses discussions pour essayer de convaincre l’IANA de réaliser ce type d’opération à un rythme plus régulier, partant du principe que « l’on ne fait bien que ce que l’on fait souvent ». Certains ont émis l’idée qu’il n’était pas nécessaire de changer cette clé. C’est un point de vue qui a ses partisans dans la mesure où ce changement impacte tous les résolveurs de la planète. Soit, mais que se passerait-il si demain, suite à une faille de sécurité, cette clé devait malgré tout être changée et que personne ne soit capable de le faire ni même d’en mesurer les conséquences ?

Sensible à ce type d’argument, l’IANA a finalement pris la décision de partir sur des cycles de 3 ans pour changer les KSK. La clé KSK-2017 a plus de 3 ans mais plusieurs évènements ont retardé le lancement du prochain changement de clé (confinements Covid, remplacement du type de HSM utilisé, …), donc c’est finalement en 2024 que la prochaine KSK a été crée. Elle n’est pas encore publiée dans le DNS mais est déjà publiée sur le site de l’IANA ( https://data.iana.org/root-anchors/root-anchors.xml). On notera que l’on conserve toujours le même algorithme. Elle sera activée en octobre 2026.

La clé suivante doit être générée mi 2027 (KSK-2027) et activée en octobre 2029. À ce stade l’IANA n’a pas encore confirmé le fait que cette dernière pourrait être d’un algorithme différent (peut-être pour KSK-2030 du coup ?). À ce rythme, on peut se demander si les algorithmes à base de courbes elliptiques seront encore la panacée ou si nous aurons à notre disposition ces nouveaux algorithmes récemment développés et standardisés qui ont pour objectif de résister aux ordinateurs quantiques.

Conseil de l'Afnic :

• Un changement de KSK qui ne se passe pas comme prévu peut avoir des conséquences ; réalisez de manière « régulière » des changements de KSK, éventuellement d’algorithme afin d’éprouver vos procédures et vous assurer que celles-ci seront fonctionnelles si ce type d’opération devait être réalisée dans l’urgence.

Cryptographie post-quantique (PQC) et DNSSEC

Bien qu’aujourd’hui, l’usage des algorithmes RSA et à base de courbes elliptiques est recommandé, il y a malgré tout une ombre au tableau. En effet, à la fin des années 90, un mathématicien américain, Peter Shor, a décrit un algorithme éponyme qui permettrait la décomposition en produit de facteurs premiers avec une rapidité sans commune mesure comparé aux algorithmes actuels. L’algorithme de Shor pourrait être exploité pour craquer aussi bien les clés basées sur RSA que sur les courbes elliptiques. Si nous employons le conditionnel, c’est que pour pouvoir exécuter cet algorithme, il faudrait avoir accès à un ordinateur quantique disposant de suffisamment de puissance.

Si ces ordinateurs sont bien une réalité, leur montée en puissance doit s’affranchir de problèmes physiques complexes. Ce qui fait que personne n’est en mesure de se prononcer sur une date à partir de laquelle les algorithmes utilisés pour DNSSEC seront devenus vulnérables. Mais quand bien même faudrait-il 30 ans pour atteindre cette échéance, on a vu avec les changements prudents de clés et d’algorithmes à la racine qu’appliquer des modifications majeures à DNSSEC sans mettre en danger la stabilité de l’infrastructure DNS va demander de nombreuses années. C’est pour cela que depuis déjà quelques temps, des travaux ont commencé pour trouver des remplaçants aux algorithmes cryptographiques actuels. Et en 2022, le NIST a fourni une liste de nouveaux algorithmes qui résisteront à l’algorithme de Shor (retrouvez ICI notre billet sur le sujet). C’est à partir de cette date que les ingénieurs de l’IETF ont commencé à travailler pour anticiper et proposer des adaptations aux protocoles que nous utilisons. Les travaux actuellement menés consistent à analyser l’impact de l’utilisation des algorithmes proposés pour évaluer les changements à prévoir sur l’infrastructure actuelle. Par exemple, une conséquence de ces nouveaux algorithmes va être l’augmentation des tailles de clés et de signatures. Sur ce dernier point particulier c’est l’algorithme Falcon-512 qui tire le mieux son épingle du jeu de par la compacité des signatures qu’il produit. Par contre pour la taille des clés, les approches étudiées peuvent être assez disruptives, comme par exemple la mise en œuvre des arbres de Merkel qui permet de traiter des condensats plutôt que des clés très volumineuses (Stateless Hash-Based Signatures in Merkle Tree Ladder Mode (SLH-DSA-MTL) for DNSSEC) mais qui en revanche nécessite des changements de ZSK permanents.

Le 27 novembre dernier, un collectif regroupant les agences nationales engagées dans la cyber sécurité de 18 pays membres de l’Union Européenne (L’ANSSI pour la France) a publié une déclaration commune sur la transition vers de la cryptographie post-quantique. Bien entendu, le champ d’application est plus vaste que le sujet qui nous intéresse ici, mais les recommandations sont du même ordre, à savoir, s’en préoccuper aujourd’hui pour préparer les longues, et parfois difficiles, transitions que cela va impliquer.

Les prochaines années s’annoncent donc passionnantes dans notre écosystème au vu des évolutions à venir et l’Afnic s’engage à continuer à publier des billets sur ces sujets pour vous tenir informé de celles-ci.

Conseils de l'Afnic :

• Même si c’est de loin, surveillez les avancées dans le domaine de la cryptographie post-quantique, afin d’anticiper et de ne pas devoir réaliser des aménagements de vos systèmes dans la précipitation.
• Un conseil qui vaut pour l’ensemble des points abordés dans ce billet, utilisez les outils Zonemaster et DNSViz pour analyser vos zones signées. Ceux-ci sont régulièrement mis à jour et mettent en œuvre les dernières recommandations en matière de DNS/DNSSEC.