Cloudflare a activé la validation des signatures DNSSEC utilisant l’algorithme ML-DSA-44 sur le résolveur DNS public 1.1.1.1, dans le but de tester la préparation du système des noms de domaine à une période où les algorithmes de signature actuels pourraient devenir cassables par des ordinateurs quantiques puissants. L’entreprise affirme que cette étape marque le début d’une transition plus longue, et non une mise en œuvre complète de la sécurité DNSSEC post-quantique.
L’Institut national des normes et de la technologie des États-Unis (NIST) a publié l’algorithme ML-DSA-44 parmi les algorithmes standardisés, et l’algorithme a reçu le numéro 18 pour les algorithmes DNSSEC auprès de l’IANA. Cloudflare prévoit d’atteindre une sécurité entièrement post-quantique d’ici 2029, après avoir consacré une grande partie de ses travaux précédents aux accords de clés dans TLS.
Une seule signature plus grande qu’un paquet DNS habituel
Le principal obstacle pratique réside dans la taille de la signature. La signature ML-DSA-44 fait 2 420 octets, contre 64 octets pour une signature ECDSA P-256, tandis que sa clé publique fait 1 312 octets. La signature seule dépasse ainsi les limites courantes des réponses DNS transmises par UDP, avant même l’ajout des enregistrements, des noms de domaine, des en-têtes de protocole et du reste des enregistrements DNSSEC.
Les implémentations DNS utilisent souvent une limite prudente de 1 232 octets pour les paquets UDP, limite liée à l’unité de transmission minimale d’IPv6. Lorsque le paquet est trop volumineux, le serveur faisant autorité doit renvoyer une réponse tronquée, qui incite le résolveur à réessayer via un autre protocole, généralement TCP, plutôt que de compter sur une fragmentation UDP peu fiable. Le problème apparaît clairement dans les réponses DNSKEY qui transportent les clés nécessaires à la validation de la zone, et pourrait s’aggraver lors de la publication simultanée de clés classiques et post-quantiques, ou pendant la rotation des clés.
Empêcher le repli vers la signature classique
Les algorithmes classiques ne peuvent pas être désactivés immédiatement, car les résolveurs anciens ne pourront pas valider une zone qui ne publie que ML-DSA-44. Toutefois, le maintien des deux voies peut ouvrir la voie à une dégradation de la sécurité : une fois qu’un algorithme classique comme ECDSA sera devenu non sûr face aux ordinateurs quantiques, un attaquant pourra forger une réponse qui en dépend, même si le résolveur est capable d’utiliser ML-DSA-44.
Pour y remédier, 1.1.1.1 s’appuie sur les enregistrements DS publiés dans la zone parente. Si l’ensemble DS validé contient un enregistrement pour un algorithme post-quantique pris en charge, Cloudflare applique une politique de validation locale plus stricte, exigeant l’existence d’un chemin de validation valide utilisant ML-DSA-44 ; le seul chemin classique ne suffit pas. L’entreprise précise qu’il ne s’agit pas encore du mécanisme de validation habituel de DNSSEC, mais qu’il repose sur les pouvoirs de politique locale prévus par le RFC 4035.
Qu’est-ce qui change concrètement ?
Pour les utilisateurs de 1.1.1.1, aucune modification n’est nécessaire ; la validation s’effectue automatiquement lorsque la zone publie les enregistrements DNSSEC requis, tandis que les zones actuelles continuent de fonctionner normalement. Cloudflare indique qu’environ 85 % des requêtes adressées à 1.1.1.1 arrivent via UDP, ce qui fait de la mesure des réponses plus volumineuses et des nouvelles tentatives via TCP une partie importante du test opérationnel.
Toutefois, l’activation de la validation sur le résolveur ne crée pas une chaîne de confiance post-quantique complète. Les serveurs faisant autorité doivent prendre en charge la signature des zones, les bureaux d’enregistrement doivent accepter les enregistrements DS appropriés, et ceux-ci doivent être publiés dans les zones parentes, jusqu’à la racine du DNS. Tout niveau dépourvu de protection post-quantique demeure un point potentiel de dégradation.
Analyse de certi.news
La valeur fondamentale de cette annonce ne réside pas dans l’ajout d’une option pour l’utilisateur final, mais dans le passage de ML-DSA-44 d’un standard cryptographique à un test opérationnel à grande échelle. Le problème mis en évidence par Cloudflare est double : transporter des messages bien plus volumineux que d’habitude et maintenir une validation stricte pendant que les anciens algorithmes resteront en place pendant des années. Les questions ouvertes concernent toujours la vitesse d’adoption de l’algorithme dans l’ensemble de la chaîne DNS, ainsi que la mesure du coût en bande passante et de l’augmentation du recours à TCP. Cloudflare prévoit par la suite d’ajouter la prise en charge de la signature ML-DSA-44 à Cloudflare Authoritative DNS et la prise en charge des enregistrements DS dans Cloudflare Registrar gratuitement pour ses clients, ce qui permettra de tester l’ensemble du parcours.