Résumé

  • Une zone malveillante pouvait multiplier les clés au même key tag et les signatures candidates afin d’imposer au résolveur un effort cryptographique disproportionné.
  • Les correctifs ont rétabli une frontière locale : interrompre la validation pathologique, continuer à servir les autres requêtes et mesurer le déclenchement des limites.

La bonne foi algorithmique comme vecteur

DNSSEC permet à un résolveur de vérifier une chaîne d’authenticité. Plusieurs DNSKEY et RRSIG sont normales pendant une rotation de clés, un changement d’algorithme ou une exploitation multi-signataire. Le key tag de seize bits aide à rapprocher signature et clé, mais ne constitue pas un identifiant unique.

KeyTrap a exploité cette ambiguïté sans casser la cryptographie. La zone de l’attaquant pouvait construire de nombreuses clés portant le même tag et plusieurs signatures invalides. Le validateur essayait alors les combinaisons plausibles avant de déclarer l’échec. Quelques données réseau déclenchaient une longue série d’opérations à clé publique sur la machine d’autrui.

La conséquence était une indisponibilité, non une fausse réponse déclarée sûre. L’attaquant ne signait pas le domaine d’un tiers et ne rompait pas la racine. Désactiver DNSSEC supprimait le calcul, mais aussi la protection. C’est pourquoi les éditeurs ont recommandé une mise à jour plutôt qu’un abandon général de la validation.

L’équipe ATHENE a coordonné la divulgation avec les principaux développeurs et opérateurs à partir de novembre 2023. La publication commune date du 13 février 2024. Les durées extrêmes observées en laboratoire — d’environ une minute à plusieurs heures selon le logiciel — définissent une possibilité expérimentale, pas la durée certaine d’une panne chez tout opérateur.

Trois réponses, une même frontière

ISC a classé CVE-2023-50387 High et exploitable à distance pour les branches BIND évaluées. Son avis associe les réponses spécialement construites à l’épuisement CPU et précise qu’aucune exploitation active n’était connue lors de la publication.

Unbound 1.19.1 adopta une logique de suspension. Après un nombre borné d’essais, la tâche de validation cède le processeur ; d’autres requêtes avancent ; après plusieurs reprises, la requête hostile échoue. Le contrôle essentiel ne porte donc pas seulement sur la cryptographie, mais sur l’ordonnancement et l’isolation du service.

Cloudflare fixa des plafonds par RRset et par tâche complète de résolution, ajouta une erreur explicite et des métriques. L’entreprise indique que 1.1.1.1 était corrigé contre KeyTrap le 8 décembre 2023 et son résolveur CDN interne le 13 février 2024 pour KeyTrap et la vulnérabilité NSEC3 associée.

Ces choix n’emploient pas nécessairement le même chiffre. Ils reconnaissent toutefois la même règle : publier une donnée signée donne le droit d’être évalué, pas celui de réserver sans limite le processeur du tiers.

Quand la spécification oublie le coût

Les RFC 4034 et 4035 décrivent les objets DNSSEC et leur validation. Cette discipline commune est indispensable. Mais une procédure correcte sur entrée normale peut devenir dangereuse si l’émetteur choisit la taille de la recherche et si aucun plafond ne fait partie du modèle.

Un Internet-Draft de 2026 sur les limites supérieures du DNS cite l’absence de bornes explicites pour les DNSKEY, DS et RRSIG. Ce texte montre que le travail de normalisation continue ; il ne représente pas encore une décision finale de l’IETF.

Le processus de normalisation de l’IETF devient ainsi le foyer institutionnel durable de cette affaire. La question n’est plus seulement de savoir quel fournisseur a corrigé le premier, mais quelles limites doivent entrer dans le contrat commun du protocole et lesquelles doivent rester locales à l’implémentation. Un projet individuel n’établit pas un consensus de l’IETF ; les opérateurs ne peuvent donc pas remplacer des limites déployées par un travail encore en cours.

La doctrine de Heng Lu éclaire la séquence. La spécification initiale doit rester minimale et interopérable. La décision future — ici, la quantité de calcul accordée à une validation — doit pouvoir rester locale. L’adoption volontaire permet aux implémentations de prouver les limites en production avant qu’une institution ne fige prématurément un ordonnanceur universel.

Une preuve d’exploitation, pas une case cochée

L’inventaire utile mentionne le logiciel, la version exacte, le paquet de distribution, la provenance du correctif et la date de déploiement. « DNSSEC actif » ne prouve pas que le chemin coûteux a disparu.

Il faut observer le nombre d’essais de signature, le temps de validation, la saturation des workers, le service du cache et les erreurs produites par les plafonds. Les tests de zone hostile doivent rester confinés, tout en démontrant que les requêtes ordinaires continuent.

Une désactivation d’urgence de DNSSEC exige un responsable, un périmètre, une échéance et une preuve de retour. Faute de quoi, une décision temporaire de disponibilité devient une dégradation permanente de l’authenticité.

Limites des faits

Les sources ne prouvent ni exploitation mondiale, ni panne globale, ni taux complet de résolveurs vulnérables. Une date de publication éditeur ne prouve pas la mise à jour de chaque distribution. Les mesures ATHENE ne doivent pas être étendues à toutes les configurations, et les superlatifs promotionnels ne remplacent pas une comparaison.

KeyTrap démontre plus précisément qu’une affirmation signée peut imposer un coût asymétrique. Le validateur doit donc gouverner non seulement sa conclusion, mais aussi les ressources qu’il accepte de dépenser pour l’atteindre.

Sources