Résumé

  • L’IANA classe ML-DSA-44 comme algorithme DNSSEC 18 et marque MAY pour son usage en signature et validation. La soumission d’une DS dépend aussi de la règle EPP du registre parent.
  • À RIPE 93, Joe Abley a décrit les essais menés sur les registres qu’il avait vérifiés et une exception ouverte après un changement de code. Son projet individuel d’octobre propose d’aligner ces règles sur les registres de l’IANA.

Le numéro 18 figurait déjà dans la table de l’IANA. Pour faire entrer une nouvelle DS dans la zone parente, le bureau d’enregistrement doit encore la transmettre par EPP et le registre parent doit l’accepter. Un algorithme peut avoir son numéro officiel; la transaction peut s’arrêter au guichet suivant.

Le 29 octobre, à RIPE 93, Joe Abley a raconté ses essais. Dans les systèmes qu’il disait avoir vérifiés, il n’avait trouvé aucun registre acceptant l’algorithme 18, avant de citer une exception : un mainteneur a fusionné une modification de code après une conversation avec Garth Miller. Un échange et un merge ont ouvert un chemin. Ils n’ont pas donné aux autres registres une règle prévisible.

Le registre DNSSEC de l’IANA répertorie le numéro 18 comme ML-DSA-44. Il autorise l’algorithme pour la signature de zone et indique MAY pour son usage et son implémentation en signature comme en validation. Ces champs fixent un niveau d’exigence permis; ils ne décrivent pas le déploiement des registres, des signataires ni des résolveurs.

RFC 5910 définit le transport des données DS par EPP. Le champ alg indique l’algorithme de la DNSKEY visée; digestType indique le condensat utilisé pour construire la DS. Le projet individuel de Joe Abley, daté du 14 octobre, porte sur ces deux champs. Il propose de prendre les registres IANA des algorithmes et condensats DNSSEC comme règle commune, avec des exclusions pour les valeurs incapables d’assurer la sécurité DNSSEC. Datatracker ne recense que la version 00, à l’état I-D Exists; le texte n’a pas le statut d’une norme IETF.

La conséquence tient à l’endroit où le changement peut s’arrêter. Le signataire prépare la nouvelle DS; le bureau d’enregistrement la transmet; le registre parent décide si elle entre dans la zone. Un refus bloque l’étape parentale du changement d’algorithme. Une liste locale non publiée oblige chaque opérateur à découvrir la règle au moment de la transaction.

L’acceptation par le registre et la validation par les résolveurs sont deux décisions distinctes. Un résolveur qui ne prend pas en charge un algorithme ignore les données DS correspondantes. S’il ne reste aucune DS qu’il sait traiter, il considère la zone enfant comme non sécurisée. EPP ouvre la voie de soumission; le soutien des résolveurs relève d’une autre étape.

Le projet ne fournit pas de tableau daté nommant les registres et leurs valeurs EPP testées; sa publication permettrait de mesurer l’ampleur de la variation.

Sources primaires : exposé RIPE 93 · transcription de la session · registre IANA des algorithmes DNSSEC · RFC 5910 · RFC 4035 · projet individuel de Joe Abley, version 00.