Cloudflare valide des signatures DNS postquantiques

A stronger seal arrives before the internet can carry its weight.
Composition d image · tobriefDepuis le 10 septembre, le résolveur public 1.1.1.1 de Cloudflare sait vérifier les signatures ML-DSA-44, conçues pour résister aux futurs ordinateurs quantiques. Le test fonctionne, mais la taille des données et une chaîne de confiance encore classique empêchent toute protection de bout en bout.
Lorsque votre navigateur cherche l’adresse d’un site, une série de requêtes traduit son nom en une adresse numérique exploitable par les réseaux. Ces réponses peuvent être signées afin que votre appareil vérifie qu’elles n’ont pas été modifiées pendant leur acheminement. Le 10 septembre, Cloudflare a appris à son résolveur public 1.1.1.1 à contrôler un nouveau type de signature, conçu pour résister aux futurs ordinateurs quantiques. Un domaine de test franchit déjà cette vérification. Mais entre cette requête validée et un Internet à l’épreuve du quantique, il reste un chantier qu’aucune entreprise ne peut mener seule.
Le sceau de cire prend du poids
Lorsqu’un domaine utilise DNSSEC, les enregistrements DNS concernés sont accompagnés de signatures cryptographiques. Le résolveur peut remonter de chacune d’elles jusqu’à une chaîne de clés de confiance et vérifier que l’enregistrement provient bien de l’autorité DNS attendue, sans avoir été altéré. Le mécanisme ressemble au sceau de cire apposé sur une carte postale : il en authentifie l’expéditeur, mais n’empêche personne d’en lire le contenu. DNSSEC ne chiffre donc ni la requête ni la session de navigation.
Ces sceaux reposent aujourd’hui sur la cryptographie classique, qu’un ordinateur quantique suffisamment puissant pourrait en théorie contourner. ML-DSA-44, normalisé par le NIST en août 2024 sous la référence FIPS 204, utilise des structures mathématiques auxquelles les machines quantiques ne devraient pas savoir s’attaquer. IANA lui a attribué le numéro d’algorithme 18 dans le registre DNSSEC. Cloudflare a simplement donné à 1.1.1.1 la capacité de reconnaître et de vérifier cet algorithme lorsqu’un domaine publie les enregistrements requis (Cloudflare).
Les utilisateurs de 1.1.1.1 n’ont rien eu à modifier. Les domaines qui recourent aux algorithmes habituels sont validés comme auparavant : le résolveur comprend désormais un langage cryptographique supplémentaire.
Trop volumineux pour un seul paquet
La difficulté technique tient surtout à la taille. Une signature ML-DSA-44 occupe 2 420 octets, auxquels s’ajoute une clé publique de 1 312 octets (NIST FIPS 204, projet de texte IETF). Or le DNS classique a été conçu pour de petites réponses tenant dans un seul paquet réseau. Une seule signature résistante au quantique dépasse déjà ce format confortable.
Une réponse trop volumineuse doit être renvoyée au moyen de TCP, le protocole également utilisé par le navigateur pour charger les pages web. Il transporte de gros volumes de manière fiable, au prix d’un aller-retour supplémentaire. Lors du test publié par Cloudflare, la requête vers valid.mldsa44.dnstest.dev a suivi ce parcours en 20,7 millisecondes (Cloudflare). Le mécanisme fonctionne donc, mais ce résultat unique, obtenu depuis un seul emplacement, ne mesure pas les performances du réseau mondial de Cloudflare. L’entreprise n’a publié ni distribution des temps de réponse, ni taux d’échec, ni données sur la bande passante consommée.
Une chaîne supérieure encore classique
La chaîne de confiance de DNSSEC part d’une clé racine, traverse les domaines de premier niveau (.com, .de, .fr), puis atteint chaque site. La racine du DNS et les niveaux situés au-dessus des domaines individuels utilisent encore des algorithmes classiques. Cloudflare présente d’ailleurs la signature de ses propres zones DNS faisant autorité et la possibilité, pour son service d’enregistrement, de soumettre des enregistrements ML-DSA comme des étapes futures, et non comme des fonctions déjà disponibles (Cloudflare).
La solidité de DNSSEC reste celle de son maillon le plus faible. Un attaquant quantique capable de falsifier une signature classique située plus haut dans la chaîne pourrait détourner le trafic avant même que la vérification post-quantique n’entre en jeu.
Cloudflare a ajouté une règle contre le retour forcé à un algorithme plus ancien. Si une zone parente exige ML-DSA, 1.1.1.1 rejettera toute réponse validée uniquement avec la cryptographie classique. Cette mesure empêche un attaquant de supprimer silencieusement la nouvelle protection en aval (Cloudflare). Elle ne vaut toutefois qu’à partir du niveau où commence effectivement la signature post-quantique.
La spécification qui adapte ML-DSA aux formats d’enregistrement de DNSSEC demeure un projet de texte en cours d’élaboration au sein d’un groupe de travail de l’IETF. Les modalités pratiques ne sont donc pas encore arrêtées.
Contrairement aux communications chiffrées, les enregistrements DNS signés sont publics. Il n’existe ici aucune urgence liée au scénario consistant à « collecter maintenant pour déchiffrer plus tard » : conserver les réponses DNS actuelles ne permettra pas de les falsifier demain à l’aide d’une machine quantique. Le risque apparaîtra au moment où une telle falsification deviendra possible. La migration du DNS exige néanmoins de coordonner les opérateurs de la racine, les registres, les bureaux d’enregistrement, les serveurs faisant autorité, les logiciels de résolution et des équipements réseau susceptibles de rejeter les gros paquets ou les connexions TCP. Commencer tôt permet de repérer ces défaillances avant qu’elles ne deviennent critiques.
Ce déploiement peut servir de banc d’essai grandeur nature, en révélant les réseaux sur lesquels le repli vers TCP échoue ou les équipements qui éliminent les réponses trop volumineuses. Cloudflare a démontré qu’un résolveur public exploité en production pouvait valider une réponse DNS signée avec ML-DSA après être passé à TCP. L’entreprise n’a pas encore établi la rapidité ni la fiabilité de ce parcours sous une charge représentative.
Cloudflare valide des signatures DNS post-quantiques hors normes
Depuis le 10 septembre, le résolveur public 1.1.1.1 de Cloudflare sait vérifier les signatures ML-DSA-44, conçues pour résister aux futurs ordinateurs quantiques. Le test fonctionne, mais la taille des données et une chaîne de confiance encore classique empêchent toute protection de bout en bout.
Lorsque votre navigateur cherche l’adresse d’un site, une série de requêtes traduit son nom en une adresse numérique exploitable par les réseaux. Ces réponses peuvent être signées afin que votre appareil vérifie qu’elles n’ont pas été modifiées pendant leur acheminement. Le 10 septembre, Cloudflare a appris à son résolveur public 1.1.1.1 à contrôler un nouveau type de signature, conçu pour résister aux futurs ordinateurs quantiques. Un domaine de test franchit déjà cette vérification. Mais entre cette requête validée et un Internet à l’épreuve du quantique, il reste un chantier qu’aucune entreprise ne peut mener seule.
Le sceau de cire prend du poids
Lorsqu’un domaine utilise DNSSEC, les enregistrements DNS concernés sont accompagnés de signatures cryptographiques. Le résolveur peut remonter de chacune d’elles jusqu’à une chaîne de clés de confiance et vérifier que l’enregistrement provient bien de l’autorité DNS attendue, sans avoir été altéré. Le mécanisme ressemble au sceau de cire apposé sur une carte postale : il en authentifie l’expéditeur, mais n’empêche personne d’en lire le contenu. DNSSEC ne chiffre donc ni la requête ni la session de navigation.
Ces sceaux reposent aujourd’hui sur la cryptographie classique, qu’un ordinateur quantique suffisamment puissant pourrait en théorie contourner. ML-DSA-44, normalisé par le NIST en août 2024 sous la référence FIPS 204, utilise des structures mathématiques auxquelles les machines quantiques ne devraient pas savoir s’attaquer. IANA lui a attribué le numéro d’algorithme 18 dans le registre DNSSEC. Cloudflare a simplement donné à 1.1.1.1 la capacité de reconnaître et de vérifier cet algorithme lorsqu’un domaine publie les enregistrements requis (Cloudflare).
Les utilisateurs de 1.1.1.1 n’ont rien eu à modifier. Les domaines qui recourent aux algorithmes habituels sont validés comme auparavant : le résolveur comprend désormais un langage cryptographique supplémentaire.
Trop volumineux pour un seul paquet
La difficulté technique tient surtout à la taille. Une signature ML-DSA-44 occupe 2 420 octets, auxquels s’ajoute une clé publique de 1 312 octets (NIST FIPS 204, projet de texte IETF). Or le DNS classique a été conçu pour de petites réponses tenant dans un seul paquet réseau. Une seule signature résistante au quantique dépasse déjà ce format confortable.
Une réponse trop volumineuse doit être renvoyée au moyen de TCP, le protocole également utilisé par le navigateur pour charger les pages web. Il transporte de gros volumes de manière fiable, au prix d’un aller-retour supplémentaire. Lors du test publié par Cloudflare, la requête vers valid.mldsa44.dnstest.dev a suivi ce parcours en 20,7 millisecondes (Cloudflare). Le mécanisme fonctionne donc, mais ce résultat unique, obtenu depuis un seul emplacement, ne mesure pas les performances du réseau mondial de Cloudflare. L’entreprise n’a publié ni distribution des temps de réponse, ni taux d’échec, ni données sur la bande passante consommée.
Une chaîne supérieure encore classique
La chaîne de confiance de DNSSEC part d’une clé racine, traverse les domaines de premier niveau (.com, .de, .fr), puis atteint chaque site. La racine du DNS et les niveaux situés au-dessus des domaines individuels utilisent encore des algorithmes classiques. Cloudflare présente d’ailleurs la signature de ses propres zones DNS faisant autorité et la possibilité, pour son service d’enregistrement, de soumettre des enregistrements ML-DSA comme des étapes futures, et non comme des fonctions déjà disponibles (Cloudflare).
La solidité de DNSSEC reste celle de son maillon le plus faible. Un attaquant quantique capable de falsifier une signature classique située plus haut dans la chaîne pourrait détourner le trafic avant même que la vérification post-quantique n’entre en jeu.
Cloudflare a ajouté une règle contre le retour forcé à un algorithme plus ancien. Si une zone parente exige ML-DSA, 1.1.1.1 rejettera toute réponse validée uniquement avec la cryptographie classique. Cette mesure empêche un attaquant de supprimer silencieusement la nouvelle protection en aval (Cloudflare). Elle ne vaut toutefois qu’à partir du niveau où commence effectivement la signature post-quantique.
La spécification qui adapte ML-DSA aux formats d’enregistrement de DNSSEC demeure un projet de texte en cours d’élaboration au sein d’un groupe de travail de l’IETF. Les modalités pratiques ne sont donc pas encore arrêtées.
Contrairement aux communications chiffrées, les enregistrements DNS signés sont publics. Il n’existe ici aucune urgence liée au scénario consistant à « collecter maintenant pour déchiffrer plus tard » : conserver les réponses DNS actuelles ne permettra pas de les falsifier demain à l’aide d’une machine quantique. Le risque apparaîtra au moment où une telle falsification deviendra possible. La migration du DNS exige néanmoins de coordonner les opérateurs de la racine, les registres, les bureaux d’enregistrement, les serveurs faisant autorité, les logiciels de résolution et des équipements réseau susceptibles de rejeter les gros paquets ou les connexions TCP. Commencer tôt permet de repérer ces défaillances avant qu’elles ne deviennent critiques.
Ce déploiement peut servir de banc d’essai grandeur nature, en révélant les réseaux sur lesquels le repli vers TCP échoue ou les équipements qui éliminent les réponses trop volumineuses. Cloudflare a démontré qu’un résolveur public exploité en production pouvait valider une réponse DNS signée avec ML-DSA après être passé à TCP. L’entreprise n’a pas encore établi la rapidité ni la fiabilité de ce parcours sous une charge représentative.
Details about this article
- Model:
- claude-opus-4-6
- Generated:
- 9/11/2026, 1:46:37 AM
- Pipeline run:
- eu_pipeline_20260911_005007
- Watermark:
- SynthID (Google's invisible watermark)
- Human review:
- None before publication