Résumé

  • RFC 9558 réserve l’algorithme DNSSEC 23 à GOST R 34.10-2012 et le type de condensat DS 5 à GOST R 34.11-2012, avec un profil binaire strict.
  • Ce texte informatif relève de l’Independent Submission : il ne porte ni consensus de l’IETF, ni jugement indépendant sur la robustesse cryptographique, ni garantie d’adoption.
  • L’exploitation doit conserver une chaîne de reçus séparés, depuis l’enregistrement IANA jusqu’au statut rendu à l’application, en passant par le signataire, le parent et le validateur.

Le parent publiait bien le DS, mais le résolveur ne savait pas quoi en faire

La panne la plus instructive n’est pas toujours une signature fausse. Supposons un domaine dont la zone enfant publie une DNSKEY d’algorithme 23, des RRSIG correctement formées et un DS de type 5 dans la zone parente. L’équipe qui signe la zone peut reproduire les vecteurs de RFC 9558. Sur son banc d’essai, la chaîne est valide.

Chez un utilisateur, le résolveur ne prend en charge ni l’algorithme de clé ni le condensat. Selon les règles DNSSEC précisées par RFC 6840, il écarte ce chemin non pris en charge. S’il n’en reste aucun autre, il traite la zone comme non signée. Les trois enregistrements sont présents ; l’authentification, elle, n’a jamais traversé le dernier maillon.

Ce scénario sépare deux choses que les tableaux de bord confondent volontiers : l’existence d’un format interopérable et l’existence d’un chemin de confiance utilisable. IANA peut nommer un algorithme. Seul le code déployé peut l’exécuter.

Un RFC n’emporte pas toujours le même mandat

RFC 9558 a été publié en avril 2024 comme document informatif de l’Independent Submission stream. Ce n’est pas une spécification Standards Track. Le Datatracker précise qu’il n’est pas approuvé par l’IETF et n’a pas de statut formel dans son processus de normalisation. Le RFC Editor, de son côté, ne se prononce ni sur sa valeur d’implémentation ni sur son déploiement.

Le texte ajoute une réserve substantielle : les propriétés cryptographiques des standards nationaux russes GOST R 34.10-2012 et GOST R 34.11-2012 n’ont pas été vérifiées indépendamment dans ce cadre. Ni l’IETF ni l’IRTF n’en ont analysé l’aptitude pour une application donnée. Il serait donc inexact de transformer la publication en recommandation.

La portée véritable est plus modeste et plus utile. Des acteurs qui choisissent déjà cette suite disposent d’un langage commun pour DNSKEY, RRSIG et DS. La coordination porte sur les octets, non sur la politique de confiance.

La précision du codage protège l’interopérabilité

Le profil retient la variante de signature sur 256 bits, le condensat sur 256 bits et le jeu de paramètres A. Le point de courbe Q=(x,y) occupe exactement 64 octets dans DNSKEY : 32 octets little-endian pour x, puis 32 pour y. La clé publique et la signature font chacune 512 bits ; le condensat, 256 bits.

Une inversion d’ordre d’octets suffit à créer une clé qui paraît transportable et ne vérifie jamais. Pour raccorder les bibliothèques GOST qui attendent une structure X.509, RFC 9558 fournit même un préfixe ASN.1 fixe de 30 octets. Cette enveloppe est une adaptation d’API. Elle ne transforme pas la clé en certificat et ne lui ajoute aucune autorité.

Le calcul RRSIG hache l’entrée canonique définie par RFC 4034 avec GOST R 34.11-2012, puis signe avec GOST R 34.10-2012. La valeur pseudo-aléatoire k publiée dans l’exemple ne sert qu’à rendre le résultat reproductible ; le texte interdit sa réutilisation réelle. Un vecteur de test prouve une conformité ponctuelle, pas la sûreté de la génération en production.

L’algorithme 23 et le type 5 répondent à deux questions

Le registre IANA des algorithmes DNSSEC donne à GOST R 34.10-2012 le numéro 23 et le mnémotechnique ECC-GOST12. Le registre DS attribue le type 5 à GOST R 34.11-2012 avec le statut OPTIONAL. Le premier identifiant explique comment lire DNSKEY et RRSIG. Le second explique comment le DS du parent condense la DNSKEY de l’enfant.

La présence de l’un ne prouve pas l’autre. Une RRSIG valide sans DS utilisable ne relie pas l’enfant au parent. Un DS correct sans prise en charge du validateur ne crée aucun chemin. Un validateur compatible, placé derrière une ancre différente ou observant un cache ancien, peut rendre un autre résultat.

Le reçu d’audit doit donc nommer les RRsets exacts, les points d’observation parent et enfant, les dates de validité, les TTL, l’ancre de confiance, la version du validateur et son inventaire d’algorithmes. « DNSSEC activé » n’est pas un diagnostic.

Le double KSK organise une transition, pas une certitude

RFC 9558 recommande une zone signée avec deux algorithmes de KSK tant que les logiciels compatibles GOST ne sont pas largement répandus, sauf choix explicite d’une cryptographie exclusivement GOST. Le second chemin permet à un validateur non compatible avec l’algorithme 23 de conserver une route d’authentification.

Ce dispositif multiplie aussi les états à coordonner : deux clés, plusieurs DS, plusieurs signatures, leurs périodes, la publication du parent, les caches et le retrait. Une politique locale trop stricte peut contredire le principe de RFC 6840 selon lequel une RRSIG valide doit suffire et le statut Bogus ne doit être conclu que lorsque toutes échouent.

La sortie doit être conçue avant l’entrée. Ajouter la nouvelle clé, mesurer les populations de validateurs, constater les DS depuis plusieurs réseaux, attendre les horizons de cache, puis retirer l’ancien chemin : chacune de ces étapes exige son propre reçu. Voir simultanément deux clés ne prouve pas que l’une peut disparaître.

La preuve DNSSEC ne commande pas l’application

Même une chaîne parfaitement validée n’établit qu’une propriété bornée : un RRset est authentifié, selon DNSSEC, par rapport à une ancre configurée et pour une période donnée. Elle ne prouve ni l’identité juridique de l’opérateur, ni la disponibilité du service, ni la conformité d’une action ultérieure.

Les bits DO, CD et AD ne sont pas interchangeables. Le premier demande des données DNSSEC, le deuxième influe sur la vérification, le troisième communique un état d’authentification sous conditions. Une application qui reçoit AD par un canal non fiable ou qui ignore complètement cet état ne peut revendiquer une preuve de bout en bout.

Le dernier reçu appartient donc à l’application : résolveur identifié, canal de confiance, statut reçu, politique appliquée, action décidée et effet observé. RFC 9558 ajoute une coordonnée à DNSSEC. Il ne raccourcit pas cette chaîne.

Sources

Sources