Résumé

  • Les présidents de DNSOP ont constaté un soutien clair à l’adoption de draft-huque-dnsop-multi-alg-rules-08, sans valider pour autant son mécanisme actuel.
  • Le projet permettrait, dans certaines configurations, de ne servir qu’une signature relevant d’un algorithme qualifié de UNIVERSAL.
  • La même qualification modifierait le comportement d’un validateur ayant désactivé localement un algorithme : ce n’est donc pas une simple étiquette documentaire.
  • Daniel Kade propose qu’une future modification de classification possède son propre reçu de déploiement, distinct du reçu d’adoption du document.

Une adoption avec réserve explicite

Le message de clôture tient en peu de mots. Il y a, selon les présidents, un soutien clair à l’adoption. Il existe aussi des préoccupations sur la complexité du mécanisme, à traiter pendant la suite des travaux. Lire uniquement la première phrase fabriquerait un résultat plus large que celui que les responsables du groupe ont réellement consigné.

L’appel avait commencé le 13 août et s’était achevé le 31. La fiche Datatracker actuelle classe désormais le texte comme Internet-Draft actif « Adopted by a WG ». Côté IESG, l’état reste « I-D Exists » ; aucun shepherd, Area Director responsable ou téléconférence d’approbation n’est indiqué. L’adoption transfère la garde du travail à DNSOP. Elle ne transforme pas la révision 08 en RFC.

Ce point de procédure rejoint ici un point technique. Le groupe n’a pas seulement accepté un thème général. Il a accepté de travailler un mécanisme dont certaines conséquences normatives ont précisément motivé les réserves.

Pourquoi la règle actuelle exige toutes les signatures

RFC 4035 demande qu’un RRset soit signé avec au moins une clé de chaque algorithme présent dans le DNSKEY à l’apex, et que ce DNSKEY soit signé selon chaque algorithme annoncé par le DS du parent. RFC 6840 reformule l’exigence du côté signataire, tout en demandant aux validateurs d’accepter n’importe quel chemin valide.

Le signataire assume ainsi la charge du jeu complet, car il ne connaît pas nécessairement les algorithmes compris par chaque validateur. La règle évite qu’une signature prise en charge mais manquante soit confondue avec une tentative de rabaissement de sécurité. En contrepartie, elle lie les prestataires. RFC 8901 explique que plusieurs signataires d’une même zone doivent partager un algorithme commun. Deux fournisseurs aux ensembles disjoints ne peuvent pas simplement juxtaposer leurs clés.

La révision 08 veut desserrer cette contrainte. Elle vise le service multi-signataire permanent, le changement de fournisseur, la rotation distincte des KSK et ZSK, la prépublication d’une ancre de confiance et l’essai d’un algorithme nouveau par un seul fournisseur. Ces besoins peuvent être admis sans que la solution soumise soit déjà jugée définitive.

Une colonne IANA qui commanderait des comportements

Le projet ajouterait au registre IANA une colonne Validation support status. Trois états sont prévus : UNIVERSAL, FORMERLY-UNIVERSAL et vide. Les algorithmes 8 et 13 seraient initialement placés dans la première catégorie. Le registre IANA aujourd’hui publié ne contient pas cette colonne ; il indique en revanche que 8 et 13 sont MUST à implémenter pour la validation DNSSEC.

La différence est substantielle. En présence d’au moins un algorithme UNIVERSAL et en l’absence de tout FORMERLY-UNIVERSAL, le signataire pourrait ne servir qu’une signature issue d’un algorithme universel. Les autres signatures annoncées seraient facultatives. Dans les autres combinaisons, le jeu complet resterait obligatoire.

Un validateur dépourvu d’un algorithme annoncé comme UNIVERSAL ou FORMERLY-UNIVERSAL devrait, selon le projet, considérer la zone comme non signée, même s’il prend en charge un autre algorithme annoncé. Il devrait aussi garder la mémoire des algorithmes qui ont autrefois porté l’étiquette. Le mot inscrit dans le registre déciderait donc de ce qui peut être omis sur le fil et de la manière dont un défaut local est classé.

RFC 9904 a déjà installé dans les registres IANA les recommandations canoniques d’usage et d’implémentation. Il sépare le choix de déploiement de l’obligation d’interopérabilité et prévoit une évolution graduelle. La nouvelle colonne créerait une autre fonction. Sa proximité graphique avec les colonnes existantes ne lui confère pas automatiquement la même preuve ni la même maturité.

Le désaccord fait partie du dossier adopté

Les réponses montrent pourquoi les présidents ont gardé leur réserve. Mark Andrews rejette le projet et conteste son hypothèse sur la prise en charge par les validateurs du monde entier. Paul Hoffman approuve l’objectif de relâcher l’ancienne exigence, mais pas la taxonomie proposée. Paul Wouters soutient l’adoption tout en demandant une simplification importante.

Ces messages sont des positions individuelles. Ils ne permettent ni de recompter le consensus, ni d’attribuer une conclusion à DNSOP. Ils permettent seulement d’identifier les questions que la clôture n’a pas effacées : généralisation, cycle de vie, anciennes implémentations, préférences locales et arrivée de la cryptographie post-quantique.

Le projet reconnaît lui-même sa dépendance la plus délicate. Un protocole ne peut pas mesurer à lui seul la prise en charge universelle. Le texte confie à la communauté le soin de ne promouvoir un algorithme que lorsque la population des validateurs incapables de le traiter est jugée négligeable. Il faut donc relier un qualificatif global à une observation datée et limitée.

Un reçu distinct pour la classification

Chaque future Standards Action changeant un état devrait publier un reçu court. Il nommerait l’algorithme, la version du registre, la date des mesures, la cohorte de validateurs observée, les exclusions connues, les générations anciennes et la règle ayant rendu le non-support « négligeable ».

Le même document devrait montrer les résultats attendus — Secure, Insecure ou Bogus — pour des transitions représentatives, l’effet des préférences locales, les dépendances entre signataires, la fenêtre d’entrée en vigueur et le responsable d’un retour d’urgence. Les identités de résolveurs et les données commerciales peuvent rester protégées. La base de la conclusion d’interopérabilité ne peut pas rester implicite.

La discipline de couche commune minimale défendue par Heng Lu donne ici un test utile. Seul le fait d’interopérabilité indispensable à tous mérite une qualification commune. Le choix entre plusieurs algorithmes autrement acceptables doit rester local, sauf décision de normalisation ultérieure qui en expose clairement le motif et l’effet.

DNSOP a choisi le problème dont il accepte désormais la garde. Il n’a pas choisi une fois pour toutes le vocabulaire qui commandera les signataires et les validateurs. La prochaine étape de légitimité consiste à préserver cette différence jusqu’au registre et au code.

Sources