Résumé

  • La RFC 9906 est une norme IETF Standards Track de novembre 2025 qui met à jour la RFC 5933 et retire GOST R 34.10-2001 (ECC-GOST) et GOST R 34.11-94 de DNSSEC.
  • GOST R 34.11-94 MUST NOT créer de DS. Une délégation qui ne repose que sur ce DS historique doit être traitée comme insecure, sauf présence d’un autre DS accepté.
  • ECC-GOST MUST NOT créer de DNSKEY ni de RRSIG. Les signatures historiques seules sont considérées comme non prises en charge ; sans autre RRSIG accepté, les enregistrements concernés sont considérés comme insecure.
  • Les algorithmes GOST 2012 distincts, documentés par la RFC 9558, ne sont pas visés. La RFC 9906 ne modifie pas leurs niveaux d’exigence.

Le mécanisme de la fermeture

La nouveauté opérationnelle est l’état complet de la matrice. Les cases concernées par la signature, la validation, l’implémentation et l’usage portent toutes MUST NOT. Il n’existe donc plus une voie de production tolérée à côté d’une voie de validation résiduelle. La RFC 9906 ajoute aussi un point de contrôle concret : les registres devraient interdire l’envoi et la publication de DS ECC-GOST.

Cette logique ne doit pas être confondue avec la transition asymétrique de la SHA-1 dans la RFC 9905. Pour ECC-GOST, la réponse prescrite aux seuls éléments historiques est insecure. Il ne faut pas la reformuler comme une autre classification cryptographique. Avant de retirer un DS ou un RRSIG historique, l’exploitant doit avoir établi une chaîne fondée sur un algorithme pris en charge.

Deux contrôles, deux objets

Pour GOST R 34.11-94, le contrôle porte sur le DS au niveau de la délégation parente : ce digest ne doit pas en créer. S’il n’existe aucun autre DS accepté, les données sous le point de délégation doivent être traitées comme insecure. Pour ECC-GOST, le contrôle porte sur la zone enfant : elle ne doit produire ni DNSKEY ni RRSIG avec l’algorithme retiré. Si aucune autre RRSIG acceptée n’est disponible, les enregistrements associés doivent être considérés comme insecure.

La décision pratique consiste à migrer la signature vers des algorithmes pris en charge, à publier la nouvelle chaîne et à vérifier sa validation. Les opérateurs doivent conserver les preuves du retrait aux points de signature, de registre, de parent et de résolution. GOST 2012 reste une famille distincte. La RFC 9558 en fournit le contexte ; la RFC 9906 n’en change pas les niveaux d’exigence.

Sources