1. Introduction
Les «extensions de sécurité DNS (DNSSEC)» [RFC9364] sont utilisées pour fournir l'authentification des données DNS. Les algorithmes de signature DNSSEC sont définis par divers RFC, notamment [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605] et [RFC8080].
Pour garantir l'interopérabilité, un ensemble d'algorithmes de clé publique DNS (DNSKEY) «obligatoires à implémenter» est défini dans [RFC8624]. Pour rendre le statut actuel des algorithmes plus facilement accessible et compréhensible, et pour faciliter la publication des modifications futures de ces recommandations, ce document déplace le statut canonique des algorithmes de [RFC8624] vers les registres d'algorithmes DNSSEC IANA. Ce document intègre également les considérations DNSSEC IANA révisées de [RFC9157]. De plus, en tant que conseil aux opérateurs, il ajoute des recommandations pour déployer et utiliser ces algorithmes.
Ceci est similaire au processus utilisé pour le registre «TLS Cipher Suites» [TLS-ciphersuites], où la liste canonique des suites de chiffrement se trouve dans le registre IANA et les RFC référencent le registre IANA.
1.1. Public du document (Document Audience)
Les colonnes ajoutées aux registres IANA «DNS Security Algorithm Numbers» [DNSKEY-IANA] et «Digest Algorithms» [DS-IANA] ciblent les opérateurs et implémenteurs DNSSEC.
Les implémentations doivent répondre à des attentes de sécurité élevées ainsi que fournir une interopérabilité entre diverses implémentations et avec différentes versions.
Le domaine de la cryptographie évolue continuellement. De nouveaux algorithmes plus robustes apparaissent, et les algorithmes existants peuvent s'avérer moins sûrs que prévu initialement. Par conséquent, les exigences d'implémentation d'algorithmes et les conseils d'utilisation doivent être mis à jour de temps en temps afin de refléter la nouvelle réalité et de permettre une transition en douceur vers des algorithmes plus sécurisés ainsi que la dépréciation des algorithmes jugés ne plus être sécurisés.
Les implémentations doivent être conservatrices dans la sélection des algorithmes qu'elles implémentent afin de minimiser à la fois la complexité du code et la surface d'attaque.
La perspective des implémenteurs peut différer de celle d'un opérateur qui souhaite déployer et configurer DNSSEC avec uniquement l'algorithme le plus sûr. En tant que tel, ce document ajoute également de nouvelles recommandations sur les algorithmes qui devraient être déployés indépendamment du statut d'implémentation. En général, on s'attend à ce que le déploiement d'algorithmes vieillissants soit généralement réduit avant que les implémentations cessent de les prendre en charge.
1.2. Mise à jour des niveaux d'exigence d'algorithme (Updating Algorithm Requirement Levels)
Au moment où un algorithme cryptographique DNSSEC est rendu obligatoire à implémenter, il devrait déjà être disponible dans la plupart des implémentations. Ce document définit une modification d'enregistrement IANA pour permettre aux documents futurs de spécifier les recommandations d'implémentation pour chaque algorithme, car le statut de recommandation de chaque algorithme cryptographique DNSSEC devrait changer au fil du temps. Par exemple, il n'y a aucune garantie que les algorithmes nouvellement introduits deviendront obligatoires à implémenter à l'avenir. De même, les algorithmes publiés sont continuellement soumis à des attaques cryptographiques et peuvent devenir trop faibles, voire complètement cassés, et nécessiteront une dépréciation à l'avenir.
On s'attend à ce que la dépréciation d'un algorithme soit effectuée progressivement. Cela donne le temps aux implémentations de mettre à jour leurs algorithmes implémentés tout en restant interopérables. Sauf s'il existe de fortes raisons de sécurité, on s'attend à ce qu'un algorithme soit rétrogradé de MUST à NOT RECOMMENDED ou MAY, au lieu de directement de MUST à MUST NOT. De même, un algorithme qui n'a pas été mentionné comme obligatoire à implémenter devrait d'abord être introduit comme RECOMMENDED au lieu d'un MUST.
Étant donné que l'effet de l'utilisation d'un algorithme DNSKEY inconnu est que la zone est traitée comme non sécurisée, il est recommandé que les algorithmes rétrogradés à NOT RECOMMENDED ou inférieur ne soient pas utilisés par les serveurs de noms autoritaires et les signataires DNSSEC pour créer de nouveaux DNSKEY. Cela garantit que l'utilisation des algorithmes dépréciés diminue au fil du temps. Une fois qu'un algorithme a atteint un niveau de déploiement suffisamment bas, il peut être marqué comme MUST NOT, afin que les résolveurs récursifs puissent supprimer la prise en charge de sa validation.
Les résolveurs récursifs de validation sont encouragés à conserver la prise en charge de tous les algorithmes non marqués comme MUST NOT.
1.3. Notation des exigences (Requirements Notation)
Les mots-clés «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY» et «OPTIONAL» dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
[RFC2119] considère le terme SHOULD comme équivalent à RECOMMENDED, et SHOULD NOT équivalent à NOT RECOMMENDED. Ce document a choisi d'utiliser les termes RECOMMENDED et NOT RECOMMENDED, car cela exprime plus clairement les recommandations aux implémenteurs.