Résumé

  • draft-kaizer-dnsop-ml-dsa-mtl-dnssec-02 remplace la répétition d’une grande signature ML-DSA par des chemins d’authentification rattachés à une même échelle Merkle signée.
  • Le validateur peut vérifier une réponse complète, mais cette preuve ne dit pas si les signataires autoritaires ont transporté l’état nécessaire pour continuer la série après transfert, mise à jour ou sinistre.

La révision 02 date du 28 septembre 2026. Son en-tête vise désormais le Standards Track et son texte propose un registre IANA des types MTL. Ce statut ne doit pas être gonflé : il s’agit d’un Internet-Draft individuel, pas d’un document adopté par DNSOP, pas d’un consensus IETF et pas d’un RFC. Le numéro d’algorithme demandé reste TBD. Les implémentations LDNS, NSD, Unbound et la bibliothèque C citées servent aux essais ; le draft précise lui-même que cette liste, fournie par des contributeurs et non vérifiée, ne vaut pas approbation.

Le gain recherché part d’une contrainte tangible. ML-DSA est une norme post-quantique du NIST, mais ses signatures sont volumineuses. Dans DNSSEC, signer chaque RRset séparément augmente la zone, le cache et les réponses. MTL partage le coût : les messages deviennent des feuilles, les feuilles appartiennent à un ensemble de nœuds, et une signature ML-DSA couvre l’échelle qui en authentifie plusieurs.

Le DNSKEY contient la clé publique ML-DSA. Pour chaque message, le signataire choisit un randomizer, calcule une feuille et lui donne l’index suivant, à partir de zéro. L’ensemble évolutif porte un identifiant de série de 32 octets, le SID. Les rungs changent au fur et à mesure des ajouts. Une réponse complète transporte le chemin de la feuille et l’échelle signée.

Le résolveur vérifie d’abord la signature de l’échelle avec le DNSKEY. Il recalcule ensuite la feuille à partir du RRset, remonte le chemin de hashes jusqu’à un rung compatible et poursuit la validation DNSSEC ordinaire. La construction permet donc à une seule signature lourde d’authentifier les RRsets inclus dans l’ensemble de nœuds. C’est un résultat cryptographique précis, pas une promesse vague de compression.

Mais la mutualisation crée une dépendance précise. L’index n’est pas un détail de présentation : il situe la feuille dans la série. Le SID distingue l’instance MTL. Le randomizer participe au hash. Les rungs reflètent l’historique d’ajout. Lorsqu’une nouvelle feuille arrive, un ancien message peut nécessiter un nouveau chemin vers l’échelle courante.

Une zone DNS traditionnelle se transfère comme un ensemble de données signées. Ici, l’opérateur doit aussi décider ce que signifie transférer le travail du signataire. Suffit-il de copier les RRSIG existants ? Faut-il répliquer le compteur, les feuilles, les randomizers, les nœuds internes et la dernière échelle promue ? Peut-on reconstruire ces éléments de façon déterministe ? À quel moment un secondaire a-t-il le droit d’allonger la série ? La révision 02 ne tranche pas.

Le texte en convient honnêtement. Il se concentre sur les code points, DNSKEY, RRSIG et opérations cryptographiques. Les règles de composition de zone, mise à jour, transfert, traitement par serveur, traitement par résolveur et cache sont renvoyées à des versions ou documents ultérieurs. Cette réserve empêche de traiter le format de preuve comme un manuel de continuité.

La clé privée ne résout pas seule le problème. Le draft interdit la réutilisation du même SID entre instanciations MTL et cite explicitement les ensembles KSK et ZSK. Une reprise qui restaure la bonne clé mais le mauvais SID ou un compteur ancien peut produire une autre histoire. Elle peut peut-être démarrer proprement une nouvelle série ; elle ne peut pas prétendre avoir continué l’ancienne sans preuve.

La signature par lots transforme cette histoire en levier de performance. Plusieurs RRsets sont ajoutés avant la création d’une nouvelle échelle, ce qui amortit ML-DSA et soulage éventuellement le HSM. Pourtant, attendre le lot retarde la disponibilité des nouvelles signatures. Le bon lot dépend de la zone ; il doit donc être relié à un objectif explicite de fraîcheur, et non choisi seulement dans un benchmark.

La signature en ligne ouvre un autre régime. Le draft donne comme exemple un nouvel ensemble de nœuds pour chaque réponse dynamique. Le modèle réduit alors la durée de vie de l’état partagé, mais son économie peut se limiter aux données de cette réponse. Une phrase disant « online signing supporté » ne permet pas de déduire le coût, la latence ou le comportement de reprise.

La révision 01 a supprimé l’option EDNS(0) de la version initiale. Dans la révision actuelle, chaque RRset reçoit une réponse MTL complète. Le document affirme qu’elle dépasse toujours la capacité du DNS sur UDP. Il prévoit davantage de TCP et recommande aux clients soucieux d’éviter la séquence troncature puis nouvel essai de passer directement par TCP lorsqu’ils rencontrent cet algorithme.

Ce choix rend le transport observable, mais il ne répare pas l’état. Une connexion TCP réussie ne prouve pas que les nœuds autoritaires possèdent la même génération d’échelle. Une échelle valide ne prouve pas la chaîne DS/DNSKEY jusqu’à l’ancre de confiance locale. Une chaîne valide ne prouve ni l’adoption par le parc de résolveurs ni la disponibilité de l’application.

Le draft SigTag, déjà traité par BTW, intervient plus tard. Il permettrait au client d’annoncer les échelles qu’il pense détenir afin que le serveur envoie parfois une preuve condensée. Cette analyse antérieure conserve la question du cache déclaré, du choix complet/condensé, de la confidentialité et du repli. Le sujet ici est antérieur : produire et préserver l’échelle que l’on voudrait réutiliser.

La doctrine du running code impose cette retenue. Une structure peut être déterministe et vérifiable localement sans que l’exploitation soit déjà sûre. La publication décrit une compatibilité possible. Les essais donnent un premier contact avec le réel. L’adoption ne devient crédible qu’après bascule, restauration, transfert, séparation KSK/ZSK, charge TCP et validation indépendante.

Un reçu de continuité devrait accompagner chaque échelle : rôle de clé, SID, plage d’index, rungs, série SOA, identité du signataire, version logicielle, horodatage et prédécesseur. Le test utile consiste à arrêter le primaire, restaurer un secondaire volontairement en retard et démontrer soit une continuation identique, soit une transition explicite vers une nouvelle série. « La signature est valide » n’est qu’une étape de ce test.

Sources