Résumé

  • Depuis le 10 septembre 2026, le résolveur 1.1.1.1 de Cloudflare savait valider ML-DSA-44 pour des zones de test. À RIPE 93, Joe Abley a comparé plusieurs chemins DNSSEC dans un test exécuté par navigateur.
  • Chez les résolveurs validateurs, la double signature face au témoin classique affichait +1 ms à la médiane et +1 405 ms à p99. Les diapositives qualifient le résultat agrégé de net breakage à 6,0 % : ce test initial et bruité ne donne pas un taux de panne de population.

La médiane rassure, la queue appelle l’astreinte

Un milliseconde de plus à la médiane : voilà le chiffre qu’une annonce de mise à niveau mettrait en gros caractères. Joe Abley a montré la ligne que l’annonce préférerait laisser en petits caractères : à p99, le chemin à double signature accusait 1 405 ms de plus que le témoin classique. Ce centile décrit la frange lente, celle que la moyenne bien coiffée laisse hors champ.

Le graphique des diapositives originales de RIPE 93 compare le temps écoulé pour la double signature moins celui du témoin en algorithme 13, chez les résolveurs validateurs. Les écarts sont de +1 ms à la médiane, +147 ms à p90, +618 ms à p95 et +1 405 ms à p99. C’est le temps du défi dans le navigateur, pas un chronomètre isolé sur la vérification cryptographique. Abley présente aussi un témoin de référence — signature classique volontairement cassée face au contrôle — avec 0, +73, +215 et +1 132 ms aux mêmes centiles.

L’expérience rassemble environ 140 000 points de données, après affichage du défi à un utilisateur sur 1 000. Quatre requêtes HTTPS parallèles partaient de noms DNS servis par Cloudflare : contrôle en algorithme 13, signature 13 volontairement invalide, chemin ML-DSA-44 en algorithme 18, puis nom signé avec les deux algorithmes. La diapositive 19 appelle le résultat agrégé des résolveurs validateurs un « net breakage » de 6,0 %. Abley relève une hausse significative des échecs dans une vingtaine d’AS ; la majorité des AS observés ne montre pas de différence. La présentation n’attribue pas chaque échec à une cause précise.

La nouvelle signature peut fermer l’issue de secours

Le test est devenu possible parce que 1.1.1.1 savait valider ML-DSA-44 pour tous ses clients depuis le 10 septembre, au moyen de zones de test. Il s’agissait de validation, pas du lancement d’une signature post-quantique proposée aux clients. Dans le registre IANA, l’algorithme 18 désigne ML-DSA-44 et l’usage en signature comme en validation est marqué MAY. L’algorithme 13 — ECDSA P-256 avec SHA-256 — est RECOMMENDED.

En DNSSEC ordinaire, un résolveur peut accepter un RRset dès qu’une RRSIG qui le couvre est valide. La RFC 6840 indique qu’il devrait accepter toute signature valide et ne marquer le RRset bogus que si toutes échouent. La RFC 4035 laisse la gestion des conflits à la politique de sécurité locale. La règle post-quantique plus stricte de Cloudflare referme cette sortie : si une signature en algorithme 18 est présente, elle doit valider. Une signature 13 valide ne rattrape pas une ML-DSA-44 cassée. Le but est d’empêcher qu’une mise à niveau post-quantique se transforme en retour discret à l’ancienne signature.

La protection fait aussi de la nouvelle signature une condition de disponibilité. Si elle est mal formée, une réponse que la signature classique aurait authentifiée peut tout de même disparaître. Cette règle relève de la politique locale du résolveur, pas d’une modification du protocole DNSSEC de base.

Le navigateur n’était pas une salle blanche

Abley qualifie les résultats de très précoces et bruités. Les mêmes noms DNS étaient réutilisés, donc le cache pouvait peser sur la comparaison ; le défi ne le purgeait pas. Les redirections HTTPS ajoutaient du temps. Les participants qui terminaient vite pouvaient quitter la mesure, tandis qu’un délai d’attente de deux secondes coupait les requêtes lentes. Le navigateur et le réseau domestique ajoutaient leur propre bruit. Les diapositives signalent donc une piste à examiner, pas une attribution nette de chaque panne à la validation ML-DSA.

La décision de déploiement restait ouverte. Cloudflare expérimentait encore la signature en ligne ML-DSA-44 et n’avait annoncé aucune date de disponibilité client. Des exigences de conformité pourraient créer une demande d’option ; activer la double signature par défaut exigerait une forte confiance dans l’absence de casse. Le projet individuel de Joe Abley propose un signal Extended DNS Error pour distinguer la politique locale stricte du résolveur d’une réponse négative inexpliquée.

Une répétition randomisée avec noms sans cache et traces côté résolveur changerait le jugement de déploiement : elle séparerait les échecs DNS des redirections, des sorties du navigateur et des délais dépassés. Pour l’instant, la forme du résultat suffit à poser le problème : le milieu reste calme, la queue s’allonge, et la politique rend la nouvelle signature obligatoire.

Sources