L’ICANN a fait du roulement de la clé racine DNSSEC un test public de responsabilité opérationnelle

Résumé

• Le roulement de la clé de signature de clé (KSK) racine DNSSEC effectué par l’ICANN en octobre 2018 a modifié l’ancre de confiance publique utilisée par les résolveurs validant DNSSEC pour valider la racine DNS. La page de roulement de l’ICANN indique qu’un résolveur ne disposant pas de l’ancre de confiance racine actuelle serait incapable de résoudre les requêtes DNS après le changement, ce qui fait de la préparation un enjeu de continuité plutôt qu’une simple tâche de maintenance cryptographique.
• Le fait le plus marquant en matière de responsabilité est le report. L’ICANN a repoussé le roulement initialement prévu en octobre 2017 après que de nouvelles données de télémétrie de la RFC 8145 aient suggéré qu’un nombre important de résolveurs utilisés par des FAI et des opérateurs réseau pourraient ne pas être prêts. Cette décision a transformé un problème caché de préparation des opérateurs en un dossier public de gouvernance.
• L’ICANN a ensuite procédé le 11 octobre 2018 après approbation du Conseil d’administration, commentaires publics, poursuite de la sensibilisation, analyse technique et un plan révisé. L’ICANN a annoncé après l’événement que les quelques problèmes observés ont été rapidement atténués et n’indiquaient pas une défaillance systémique nécessitant une annulation.
• Le contrôle pratique était réparti. L’ICANN et Public Technical Identifiers contrôlaient le processus de cérémonie de la KSK racine, la publication, la documentation, la sensibilisation et la décision finale de roulement; Verisign occupait le rôle de mainteneur de la zone racine; les opérateurs de résolveurs contrôlaient la configuration de l’ancre de confiance et le comportement logiciel; les éditeurs contrôlaient la qualité de l’implémentation de la RFC 5011; les agences publiques et les entreprises contrôlaient la planification de secours pour leurs propres réseaux.
• La leçon en matière de responsabilité est que les modifications de l’infrastructure Internet mondiale nécessitent une préparation observable, des critères de décision publiés, un examen par la communauté, une réflexion sur une annulation sûre, et suffisamment d’humilité pour reporter lorsque la télémétrie ébranle la confiance. Le roulement a réussi parce qu’il a été traité comme un risque opérationnel public, et non parce que le risque était imaginaire.

La clé racine était petite, mais la dépendance était mondiale

Le roulement de la clé de signature de clé racine DNSSEC semble être un événement microscopique si on le réduit au remplacement d’une clé cryptographique. Sur le plan opérationnel, il s’agissait d’un test de dépendance mondiale. La racine DNS est le sommet de la hiérarchie de délégation du système de noms de domaine public. Les résolveurs effectuant la validation DNSSEC utilisent des ancres de confiance pour vérifier les données DNS signées.

Si l’ancre de confiance racine d’un résolveur validant est obsolète après le changement de la KSK racine, le résolveur peut traiter des réponses valides comme étant fausses et échouer à la résolution de noms ordinaire pour ses utilisateurs.

La page dédiée Root Zone KSK Rollover de l’ICANN est la source principale. Elle explique que l’ICANN a effectué le roulement le 11 octobre 2018, que le roulement de la KSK signifie générer une nouvelle paire de clés publique et privée et distribuer le composant public aux opérateurs de résolveurs validants, et que maintenir une KSK à jour est essentiel car ne pas disposer de la KSK actuelle de la zone racine signifie que les résolveurs validants DNSSEC seront incapables de résoudre les requêtes DNS. C’est là tout le problème de responsabilité en langage simple.

Un changement dans un objet de confiance central devient une panne utilisateur lorsque les opérateurs distribués n’ont pas mis à jour l’état de validation local.

La KSK n’existait pas de manière isolée. La page de roulement de l’ICANN décrit la planification initiale comme le travail des partenaires de gestion de la zone racine: l’ICANN en tant qu’opérateur des fonctions IANA, Verisign en tant que mainteneur de la zone racine, et la NTIA du département du Commerce des États-Unis en tant qu’administrateur de la zone racine avant que le rôle de la NTIA ne prenne fin le 1er octobre 2016.

La page de gestion de la zone racine de l’IANA fournit le point d’entrée public actuel pour la gestion de la zone racine, tandis que la page KSK de la zone racine DNSSEC de l’IANA fournit des informations sur l’ancre de confiance et les cérémonies KSK. Le dossier opérationnel se situe donc à l’intersection de la gouvernance de l’ICANN, des fonctions PTI/IANA, des opérations de zone racine de Verisign et des nombreux opérateurs de résolveurs indépendants qui consomment l’ancre de confiance racine.

L’architecture technique propre à DNSSEC explique pourquoi l’incident a eu de l’importance. La RFC 4033 définit l’introduction et les exigences de DNSSEC, la RFC 4034 définit les enregistrements de ressources utilisés par DNSSEC, et la RFC 4035 définit les modifications du protocole. Ces normes ne sont pas des preuves d’incident spécifiques à l’ICANN. Elles expliquent la chaîne de validation qui a rendu la clé racine conséquente. Un résolveur validant dispose soit d’un chemin de confiance qu’il accepte, soit pas.

Contrairement à un certificat de site Web qui peut être remplacé par un seul opérateur pour un seul service, l’ancre de confiance racine est une infrastructure partagée.

L’enjeu de continuité publique était donc large. Les FAI, les entreprises, les universités, les agences publiques, les fournisseurs de DNS récursif, les registres, les bureaux d’enregistrement, les réseaux cloud, les distributions logicielles, les fabricants d’appareils et les utilisateurs ordinaires n’étaient pas tous des clients directs de l’ICANN. Pourtant, leur résolution DNS pouvait dépendre de la préparation de leur résolveur récursif.

C’est pourquoi l’annonce par l’ICANN du report de 2017 estimait qu’environ un quart des utilisateurs mondiaux d’Internet, soit environ 750 millions de personnes, s’appuyaient sur des résolveurs validant DNSSEC et pourraient être affectés par un roulement mal exécuté. Ce chiffre n’était pas une prédiction que tous ces utilisateurs échoueraient. C’était une mesure de la population dépendante.

Cette distinction est importante. Le roulement n’a pas été une panne. C’était un test de responsabilité mené avant une éventuelle panne. La gouvernance des infrastructures publiques est souvent jugée seulement après une défaillance. Ici, le dossier de gouvernance est significatif parce que l’ICANN a reporté avant une défaillance, a rouvert le plan, a recueilli davantage de preuves, a élargi la sensibilisation, et a pris plus tard une décision d’exécution avec une acceptation explicite du risque.

Le report a été le pivot de la responsabilité

L’événement le plus important dans le dossier s’est produit avant le roulement réussi. L’annonce du report par l’ICANN le 27 septembre 2017 indiquait que le plan visant à changer la clé cryptographique qui aide à protéger le DNS était reporté. L’ICANN a expliqué que des données récemment obtenues montraient qu’un nombre important de résolveurs utilisés par des FAI et des opérateurs réseau n’étaient pas encore prêts. Elle a lié cette nouvelle visibilité à une fonctionnalité récente du protocole DNS qui permettait aux résolveurs de signaler aux serveurs racine quelles clés ils avaient configurées.

Cette fonctionnalité était la RFC 8145, qui définit une manière pour les résolveurs validants de signaler les ancres de confiance configurées. Le protocole n’a pas donné à l’ICANN une connaissance parfaite. Il a créé une vue bruyante, partielle et opérationnellement sensible de la préparation. Certains signaux pouvaient provenir de systèmes mal configurés, d’environnements de test, de redirecteurs, de logiciels obsolètes, de configurations périmées ou de résolveurs qui ne desservaient pas de grandes populations d’utilisateurs. Mais l’existence d’une télémétrie imparfaite restait un événement de gouvernance.

L’ICANN devait décider s’il fallait procéder comme prévu malgré les signaux indiquant que certains résolveurs étaient obsolètes, ou reporter pendant que la communauté interprétait les données et intensifiait la sensibilisation.

L’ICANN a choisi le report. Cette décision est facile à saluer avec le recul parce que le roulement ultérieur a réussi. Sur le moment, elle comportait son propre coût. Le report pouvait saper la confiance dans le plan, prolonger la période avec deux clés publiées, retarder l’exercice opérationnel requis par la déclaration de pratiques DNSSEC de l’ICANN, et signaler une incertitude aux opérateurs qui s’étaient déjà préparés pour la date de 2017. Pourtant, procéder aurait risqué de faire découvrir aux opérateurs de résolveurs et à leurs utilisateurs des problèmes de préparation seulement lorsque les noms cesseraient de se résoudre.

L’annonce du report est inhabituellement franche pour la gouvernance des infrastructures. Elle indiquait qu’il pouvait y avoir de multiples raisons pour lesquelles les opérateurs n’avaient pas installé la nouvelle clé, notamment des logiciels de résolveur mal configurés et un problème récemment découvert dans un programme de résolveur largement utilisé qui semblait ne pas mettre à jour automatiquement la clé comme prévu. Elle disait que l’ICANN contactait la communauté, y compris le SSAC, les registres Internet régionaux, les groupes d’opérateurs réseau et d’autres.

Elle citait le PDG de l’ICANN déclarant qu’il serait irresponsable de procéder après avoir identifié de nouveaux problèmes qui pourraient nuire au succès et à la connectivité des utilisateurs finaux.

Ce langage a créé une norme publique. L’ICANN ne promettait pas que chaque résolveur validant fonctionnerait. Elle promettait que les nouvelles preuves de préparation modifieraient la décision. Dans les opérations d’infrastructure, c’est la différence entre un changement dicté par le calendrier et un changement dicté par les preuves.

Le report a également préservé la responsabilité des opérateurs de résolveurs. L’ICANN ne pouvait pas se connecter à chaque résolveur récursif et installer l’ancre de confiance. Les opérateurs de FAI, d’entreprises, de réseaux gouvernementaux et de services DNS contrôlaient leurs propres logiciels et configurations de résolveur. En reportant, l’ICANN a rendu public le problème de préparation et a donné à ces opérateurs du temps supplémentaire. Cela n’a pas transféré toute la responsabilité sur eux, mais a rendu visible le modèle de contrôle partagé.

L’automatisation RFC 5011 était utile, pas magique

Le roulement dépendait fortement du comportement de mise à jour automatique des ancres de confiance. La RFC 5011 définit les mises à jour automatisées des ancres de confiance DNSSEC. L’attrait de la RFC 5011 est évident: un résolveur validant peut observer la nouvelle clé pendant une période de maintien supplémentaire et l’accepter automatiquement comme ancre de confiance. Sans un tel mécanisme, chaque opérateur de résolveur validant aurait besoin d’une installation manuelle de clé à l’échelle d’Internet.

L’automatisation, cependant, n’est jamais une responsabilité en soi. C’est une promesse faite par le code et la configuration dans des conditions réelles variées. Un résolveur doit implémenter l’algorithme correctement, persister l’état, avoir une horloge et un modèle de disponibilité compatibles avec le processus de maintien, recevoir et valider le matériel DNSKEY pertinent, et éviter les choix de configuration locaux qui empêchent la mise à jour automatique.

Les opérateurs doivent également savoir si leur résolveur valide effectivement, s’il transfère les requêtes à un autre résolveur, si la version de leur paquet se comporte correctement, et si les systèmes de gestion de configuration écrasent l’état de l’ancre de confiance.

La page de Verisign sur le roulement de la KSK a saisi cette distinction du point de vue du mainteneur de la zone racine et des serveurs racine. Elle indiquait que chaque validateur DNSSEC a besoin d’une ancre de confiance et que la RFC 5011 n’avait jamais été testée en production pour un roulement de KSK racine. Elle disait également que Verisign, en tant qu’opérateur de serveur de noms racine, recevait certaines données RFC 8145 et les analysait pour identifier les sources qui semblaient avoir une configuration d’ancre de confiance obsolète.

C’est important car cela montre que la télémétrie n’était pas seulement un tableau de bord central de l’ICANN. Les opérateurs de serveurs racine pouvaient également voir et agir sur les signaux de préparation.

L’automatisation a rendu le roulement possible, mais la responsabilité publique exigeait des preuves indépendantes que l’automatisation avait fonctionné. Ces preuves comprenaient la signalisation des ancres de confiance, les tests de logiciels de résolveur, la sensibilisation auprès des opérateurs qui semblaient obsolètes, les commentaires publics, les discussions sur les listes de diffusion et la surveillance post-événement. Elles comprenaient également la volonté de définir un seuil d’annulation si l’échec était suffisamment généralisé.

Le rapport final de l’équipe de conception du roulement de la KSK racine est un contexte utile car il a posé les bases d’un processus de conception pour le premier roulement de KSK racine avant le report de 2017. Il recommandait une mise en scène délibérée, une communication et des mesures précisément parce qu’Internet n’avait jamais connu de roulement opérationnel d’une ancre de confiance racine. Le report ultérieur n’a pas prouvé que l’équipe de conception avait échoué. Il a prouvé que l’hypothèse de conception était juste: le premier roulement nécessitait une observation et une prise de décision par étapes.

La leçon n’est pas que la RFC 5011 n’est pas fiable. La leçon est que les mécanismes de mise à jour automatique distribués ont besoin de télémétrie et de coordination sociale lorsqu’ils protègent une infrastructure partagée. Une norme peut définir une machine à états. Elle ne peut pas faire en sorte que chaque opérateur comprenne si cette machine à états fonctionne correctement dans son réseau.

Les commentaires publics ont transformé un changement technique en dossier de gouvernance

Après le report, l’ICANN n’a pas simplement choisi une nouvelle date en privé. Sa page de commentaires publics sur le plan de redémarrage du processus de roulement de la clé de signature de clé racine a ouvert le plan révisé à l’examen de la communauté. La page de commentaires publics indiquait que le plan comprenait davantage de publicité sur la préparation, plus d’analyse des données de préparation, et le roulement effectif le 11 octobre 2018. Le plan pour la poursuite du roulement de la KSK racine (PDF) décrivait le redémarrage proposé après le report antérieur.

Cette étape est importante parce que la légitimité technique et la légitimité institutionnelle étaient deux problèmes différents. L’ICANN aurait pu être techniquement capable de changer la clé et néanmoins politiquement irresponsable si elle avait ignoré les preuves de préparation de la communauté. Inversement, la communauté aurait pu exiger un report indéfini, mais un report indéfini aurait également créé une dette opérationnelle.

Les commentaires publics ont forcé le désaccord à entrer dans le dossier: quelles données devaient être fiables, quelle sensibilisation était suffisante, quel seuil d’échec devait être utilisé, et qui prendrait la décision finale.

Le rapport du personnel sur les commentaires du projet de plan est une preuve de cette étape de traduction. Il n’a pas fait disparaître tous les risques. Il a montré que l’ICANN avait recueilli et répondu aux commentaires avant de présenter un plan au Conseil d’administration. La responsabilité en matière d’infrastructure consiste souvent moins à obtenir un accord universel qu’à rendre visibles les preuves et les objections avant que l’autorité n’agisse.

L’ annonce d’approbation du Conseil d’administration de l’ICANN indiquait que le Conseil avait approuvé les plans pour le tout premier changement de la clé cryptographique protégeant la racine DNS, ordonnant à l’organisation de procéder le 11 octobre 2018. L’annonce reconnaissait qu’il n’y avait aucun moyen de garantir complètement que chaque opérateur de réseau aurait des résolveurs correctement configurés, mais indiquait que l’ICANN s’attendait à ce que la grande majorité ait accès à la zone racine.

Elle indiquait également qu’une solution de dernier recours pour un opérateur serait de désactiver la validation DNSSEC, d’installer la nouvelle clé et de réactiver la validation.

Les résolutions du Conseil d’administration de l’ICANN du 16 septembre 2018 sous-jacentes sont l’artefact formel de gouvernance. Elles importent parce que la décision d’exécution n’était pas seulement une action du personnel technique. C’était une décision institutionnelle d’une société d’utilité publique dont la mission inclut la sécurité, la stabilité et la résilience du DNS. Le Conseil d’administration n’exploitait pas chaque résolveur, mais il a approuvé le changement central après le plan révisé et la consultation.

Un compte rendu honnête ne doit pas prétendre que les commentaires publics ont éliminé le risque. Ils ont modifié la charge de la preuve. L’ICANN devait expliquer pourquoi procéder en octobre 2018 était préférable à un nouveau report. Les opérateurs devaient utiliser l’année supplémentaire pour valider leur propre préparation. La communauté devait accepter qu’une ancre de confiance partagée ne peut être renouvelée seulement lorsque l’incertitude est nulle, car l’incertitude nulle n’arrive jamais.

La communication faisait partie du contrôle, pas des relations publiques

Les documents de sensibilisation de l’ICANN étaient des contrôles opérationnels. La page de roulement renvoyait vers des ressources pour vérifier les ancres de confiance actuelles dans les résolveurs DNS validants et mettre à jour les résolveurs validants avec la dernière ancre de confiance. Ces documents n’étaient pas du marketing. C’étaient des instructions pratiques destinées aux opérateurs qui contrôlaient le dernier kilomètre de la préparation.

Le Guide complet sur ce à quoi s’attendre pendant le roulement de la KSK racine fournissait une autre forme de contrôle: la gestion des attentes. Les opérateurs avaient besoin de savoir ce qui allait changer, quand cela changerait, comment les symptômes pourraient se présenter, et que faire si la validation échouait. Un changement central silencieux aurait laissé chaque enquête sur une panne commencer à partir de zéro. Un guide public a donné aux services d’assistance, aux équipes réseau et au personnel de sécurité un cadre commun.

Les documents sur le roulement KSK de DNS-OARC et les autres lieux de la communauté des opérateurs ont compté pour la même raison. DNS-OARC n’est pas l’ICANN, et son rôle ne doit pas être gonflé en une autorité de gouvernance centrale. Il est utile en tant que canal public de la communauté technique où les opérateurs de résolveurs et les spécialistes DNS pouvaient partager les tests et les observations.

Les changements d’infrastructure Internet réussissent souvent grâce à ce maillage de coordination semi-formelle: les organismes de normalisation définissent les mécanismes, l’ICANN gère la fonction racine, les opérateurs racine observent le trafic, et les communautés d’opérateurs traduisent le risque en actions déployables.

La communication devait également atteindre les réseaux du secteur public. L’étiquette manifeste « Continuité du secteur public » convient parce que les services gouvernementaux, les écoles, les hôpitaux, les bureaux de gestion des urgences et les agences publiques dépendent souvent d’un DNS récursif configuré par une organisation informatique centrale ou un fournisseur. Un résolveur validant obsolète dans un tel environnement ne serait pas vécu comme un exercice de formation à DNSSEC. Il serait vécu comme une incapacité à atteindre les services.

La leçon de continuité pour le secteur public est que les améliorations de sécurité peuvent créer un risque de disponibilité lorsque les mises à jour des ancres de confiance sont cachées aux propriétaires de services. Une agence municipale peut ne pas savoir si son résolveur amont valide. Une équipe réseau d’hôpital peut s’appuyer sur un appareil DNS géré. Un district scolaire peut hériter du comportement du résolveur du FAI. Les documents publics de l’ICANN ne pouvaient pas forcer ces organisations à tester, mais ils leur donnaient un moyen de poser les bonnes questions.

La communication devait également éviter la panique. L’ICANN devait avertir que les résolveurs validants non préparés pourraient échouer sans laisser entendre que tout Internet serait paralysé. Elle devait expliquer que la plupart des résolveurs non validants ne seraient pas directement affectés sans décourager l’adoption de DNSSEC. Elle devait décrire la désactivation de la validation comme une option de récupération d’urgence sans en faire l’option par défaut. Cet équilibre est opérationnellement difficile. Trop peu d’alarme provoque l’inaction. Trop d’alarme provoque la méfiance envers le mécanisme de sécurité lui-même.

La décision d’exécution a accepté un risque résiduel

L’approbation de septembre 2018 ne signifiait pas que l’ICANN avait prouvé que chaque résolveur était sûr. Cela signifiait que l’ICANN acceptait un risque résiduel après une sensibilisation, une analyse et une consultation communautaire supplémentaires. Cette distinction est centrale pour la responsabilité.

L’annonce d’approbation de l’ICANN indiquait que les recherches montraient que plusieurs milliers d’opérateurs de réseau avaient activé la validation DNSSEC et qu’environ un quart des utilisateurs d’Internet s’appuyaient sur eux. Elle indiquait également qu’au moins quelques opérateurs quelque part n’étaient presque certainement pas préparés. C’est un langage de risque inhabituellement honnête. Elle ne promettait pas un roulement sans faille.

Elle expliquait pourquoi il était tout de même justifié de procéder: les échecs attendus étaient suffisamment petits, récupérables et compensés par la nécessité d’exercer le processus de roulement de clé.

Le dossier public comprenait également un concept d’annulation. L’ annonce de la réussite du premier roulement de l’ICANN a indiqué plus tard que les quelques problèmes survenus ont été rapidement atténués et qu’aucun ne suggérait une défaillance systémique approchant le seuil défini par la communauté pour initier une annulation. Cette phrase importe car elle montre que le succès a été évalué par rapport à un seuil opérationnel explicite, et pas seulement par rapport à l’optimisme après coup.

L’annulation n’est pas triviale dans DNSSEC. Revenir sur une KSK racine après que les validateurs ont changé d’état peut créer sa propre complexité. Pourtant, avoir un seuil d’annulation oblige les dirigeants à définir quel niveau de dommage modifie la décision. Sans un tel seuil, les équipes peuvent être piégées par l’élan du changement. Avec un seuil, l’organisation a au moins un critère public pour savoir quand la stabilité l’emporte sur l’achèvement.

La décision d’exécution appartenait donc à la direction de l’ICANN et à la gouvernance du Conseil d’administration, mais elle reposait sur des preuves distribuées. Les opérateurs de résolveurs qui avaient mis à jour leurs ancres de confiance ont créé la préparation. Les éditeurs de logiciels dont les implémentations se comportaient correctement ont créé la préparation. Les opérateurs racine qui ont analysé les signaux ont créé la préparation. Les examinateurs de la communauté qui ont contesté les hypothèses ont créé la préparation. L’ICANN a coordonné et décidé, mais elle n’a pas rendu le système distribué prêt à elle seule.

C’est la carte de responsabilité centrale. L’ICANN avait autorité sur l’opération centrale de la KSK racine et la responsabilité de la sensibilisation et de la gouvernance de la décision. Les opérateurs de résolveurs avaient la responsabilité de leur propre configuration de validation. Les éditeurs avaient la responsabilité de l’implémentation. Les propriétaires de réseaux du secteur public et des entreprises avaient la responsabilité de la planification de la continuité. Aucune partie ne détenait l’ensemble du système, la responsabilité devait donc être explicite plutôt que présumée.

L’événement lui-même a été calme parce que la préparation ne l’était pas

Le 11 octobre 2018, l’ICANN a effectué le roulement. L’annonce post-événement de l’ICANN le 15 octobre indiquait qu’après évaluation des données disponibles, il ne semblait pas y avoir de nombre significatif d’utilisateurs finaux d’Internet qui aient été affectés de manière persistante et négative. Elle indiquait que les quelques problèmes survenus avaient été rapidement atténués et n’indiquaient pas de défaillance systémique nécessitant une annulation. Elle indiquait également que l’ICANN procéderait à la révocation de l’ancienne KSK, KSK-2010, lors de la prochaine cérémonie des clés au premier trimestre 2019.

L’ examen du roulement de la KSK DNSSEC de 2018 ultérieur est la source d’après-action la plus solide. Elle définit KSK-2010 comme l’ancre de confiance utilisée jusqu’au roulement de 2018 et KSK-2017 comme la clé utilisée pour la première fois pour signer la zone racine le 11 octobre 2018. Elle documente également les leçons du premier roulement en production. Un rapport d’examen ne fait pas de l’ICANN un observateur neutre de son propre travail, mais il est plus précieux qu’une annonce de victoire car il crée un dossier durable pour le prochain roulement.

Le calme de l’événement ne doit pas être pris pour la preuve que le risque avait été surestimé. De nombreux changements d’infrastructure deviennent calmes précisément parce que les opérateurs ont reporté, testé, communiqué et surveillé. Un test de charge d’un pont qui trouve une faiblesse avant l’effondrement n’est pas une fausse alerte. C’est le but du test. Le report de 2017 fait donc partie du succès de 2018, et non une tache distincte.

Le bilan post-événement a également limité la portée des affirmations. Il n’a pas dit que personne n’avait été affecté. Il a dit qu’il n’y avait pas de nombre significatif d’impacts négatifs persistants sur les utilisateurs finaux et pas de défaillance systémique. C’est le bon niveau pour un changement d’infrastructure mondial. Certains opérateurs individuels ont pu avoir des problèmes locaux. La question pertinente était de savoir si le changement de l’ancre de confiance racine avait causé une défaillance généralisée et persistante de la résolution DNS.

L’étape de révocation de l’ancienne clé compte également. Un roulement n’est pas terminé simplement parce que la nouvelle clé est utilisée. L’ancienne ancre de confiance doit être retirée d’une manière qui confirme que les validateurs ont accepté le nouvel état. L’examen de l’ICANN et les documents de cérémonie ultérieurs montrent que le roulement était une séquence, pas un seul horodatage.

Le pouvoir de délégation DNS est réel même si aucun domaine n’est redélégué

L’étiquette manifeste « Pouvoir de délégation DNS » évoque généralement le contrôle des entrées de la zone racine, des délégations de TLD, des relations avec les bureaux d’enregistrement et de la propriété des noms. Le roulement de la KSK montre une autre forme de pouvoir de délégation: le contrôle de la chaîne de confiance de validation de la zone racine. L’ICANN n’a pas redélégué un TLD ni changé le domaine d’un titulaire. Elle a changé la clé cryptographique que les résolveurs validants utilisent pour décider si les données signées de la racine peuvent être fiables.

Ce pouvoir est limité. L’ICANN fonctionne selon des déclarations de pratiques techniques, un examen communautaire, une gouvernance du Conseil d’administration, des attentes en matière de fonctions IANA, une coordination avec les partenaires de la zone racine et une surveillance mondiale. Pourtant, c’est tout de même un pouvoir. Une mauvaise opération de clé centrale pourrait faire apparaître des données correctement signées comme non valides pour les validateurs, ou forcer les opérateurs à désactiver la validation en urgence. Le fait que la clé soit cryptographique ne rend pas la décision purement technique.

La Déclaration de pratiques DNSSEC de l’opérateur de la KSK racine est pertinente car elle définit les attentes sur la manière dont l’opérateur de la KSK racine effectue la gestion des clés. Les déclarations de pratiques sont des documents arides, mais ce sont des instruments de responsabilité. Elles définissent les cérémonies, les rôles, les contrôles et les attentes qui permettent à la communauté d’évaluer si l’opérateur agit conformément aux procédures publiées. Lorsque l’ICANN a renouvelé la clé, elle n’exerçait pas simplement un pouvoir discrétionnaire; elle exerçait une responsabilité opérationnelle documentée.

L’ ancre de confiance IANA en XML et l’ emplacement de publication des ancres racine associé font également partie de ce pouvoir. Ils rendent le matériel d’ancre de confiance accessible publiquement sous des formes lisibles par machine et vérifiables par l’humain. La publication ne suffit pas à garantir l’adoption, mais sans publication et distribution stable, les opérateurs de résolveurs ne peuvent pas se préparer de manière fiable.

Le pouvoir de délégation DNS devient responsable lorsqu’il existe une chaîne publique allant de la décision à l’artefact, puis à l’action de l’opérateur. La décision de rouler est documentée. La clé publique est publiée. Le comportement attendu de l’opérateur est décrit. La télémétrie est discutée. L’approbation du Conseil d’administration est enregistrée. L’examen post-événement est publié. Cette chaîne n’élimine pas les dommages, mais elle rend l’exercice de l’autorité inspectable.

Le contraste avec une panne de plateforme privée est utile. Un fournisseur SaaS privé peut parfois ne communiquer qu’à ses clients et publier peu. L’ICANN n’avait pas cette option de la même manière. La KSK racine est une dépendance publique d’Internet. Le canal de responsabilité devait être public parce que la population dépendante était publique.

Les opérateurs de résolveurs étaient également responsables

Une analyse centrale qui blâme ou crédite uniquement l’ICANN passe à côté de la moitié du système. Les opérateurs de résolveurs ont rendu le roulement sûr ou risqué dans leurs propres réseaux. Si un FAI activait la validation DNSSEC pour des millions d’utilisateurs, il contrôlait si ses résolveurs étaient mis à jour, surveillés et testés. Si une entreprise utilisait des résolveurs validants pour la résolution interne et externe, elle contrôlait si la gestion des changements incluait la préparation de l’ancre de confiance racine.

Si une agence publique externalisait le DNS à un fournisseur, elle contrôlait les questions posées au fournisseur et les attentes de continuité.

Le document de l’ICANN sur la vérification des ancres de confiance actuelles et celui sur la mise à jour des résolveurs validants fournissaient des étapes pratiques, mais les opérateurs devaient les utiliser. Une organisation centrale ne peut pas compenser indéfiniment la négligence locale. Un résolveur dont la validation est activée mais qui n’a pas de surveillance des défaillances DNSSEC est un risque de continuité latent. Un résolveur dont le fichier d’ancre de confiance est écrasé par la gestion de configuration est un risque de continuité latent.

Un appareil de fournisseur qui implémente incorrectement la RFC 5011 est un risque de continuité latent.

La dimension du secteur public rend cela concret. Les agences gouvernementales et les services publics critiques héritent souvent des choix DNS de services partagés, de fournisseurs cloud, de fournisseurs de sécurité gérée, d’intégrateurs réseau ou de contrats télécom. Ces agences peuvent ne pas être des experts DNS, mais elles peuvent toujours exiger des preuves des fournisseurs: si la validation DNSSEC est activée, quel logiciel de résolveur est utilisé, comment les ancres de confiance racine se mettent à jour, comment les échecs de validation sont surveillés et comment les changements d’urgence sont approuvés.

Les opérateurs contrôlaient également le chemin de récupération. L’annonce d’approbation du Conseil d’administration de l’ICANN décrivait la désactivation de la validation DNSSEC, l’installation de la nouvelle clé et la réactivation de la validation comme une solution de dernier recours pour un opérateur non préparé. Ce chemin d’urgence n’est pas idéal car la désactivation de la validation supprime un contrôle de sécurité, même temporairement. Mais c’est mieux que de laisser les utilisateurs incapables de résoudre les noms.

La question de responsabilité est de savoir si les opérateurs avaient ce chemin documenté avant le changement, et non s’ils l’ont découvert pendant une crise.

C’est pourquoi le roulement appartient à une série sur les risques et la responsabilité plutôt qu’à une simple histoire de DNSSEC. L’événement a testé si les opérateurs distribués pouvaient aligner leurs pratiques locales sur un changement de sécurité central. Un contrôle de sécurité mondial n’est aussi résilient que les organisations les moins préparées qui en dépendent pour leur continuité.

La télémétrie a créé une responsabilité d’interprétation, pas de certitude

La signalisation des ancres de confiance de la RFC 8145 est l’un des éléments les plus intéressants de l’histoire car elle a créé de la visibilité et de l’incertitude en même temps. Le signal pouvait indiquer quelles ancres de confiance un résolveur croyait avoir configurées. Mais les serveurs racine voient le trafic DNS, pas l’intention organisationnelle. Une adresse source visible peut représenter de nombreux utilisateurs ou un laboratoire. Certains signaux peuvent être périmés. Certains résolveurs peuvent ne pas signaler. Certains réseaux peuvent transférer à travers des couches qui obscurcissent le résolveur validant réel.

Le report de 2017 montre que l’ICANN a traité la télémétrie comme pertinente pour la décision même lorsqu’elle était imparfaite. C’est une bonne gouvernance, mais cela crée aussi une responsabilité d’expliquer l’interprétation. Si la télémétrie suggère un risque, les dirigeants doivent décider si le risque est suffisamment réel pour reporter. Si plus tard la télémétrie montre encore quelques signaux périmés, les dirigeants doivent décider si ces signaux représentent un impact utilisateur significatif ou un bruit résiduel gérable.

L’examen du roulement et les mises à jour techniques montrent cette charge analytique. La page de ressources sur le roulement de l’ICANN a rassemblé des mises à jour techniques, du matériel d’examen et des conseils aux opérateurs en un seul endroit. La mise à jour du 18 décembre 2017 sur le projet de roulement de la KSK racine a documenté l’état de l’analyse après le report. Le but de ces documents n’est pas de produire une confiance parfaite. C’est d’empêcher que la décision ne soit dictée par la rumeur.

La responsabilité de la télémétrie a deux faces. L’ICANN et les opérateurs racine devaient éviter de surestimer le signal. Les opérateurs de résolveurs devaient éviter de l’ignorer. Si le résolveur d’un réseau signalait une ancienne ancre de confiance, l’opérateur ne pouvait pas raisonnablement s’attendre à ce que la communauté centrale identifie et corrige la configuration locale sans coopération. Inversement, l’ICANN ne pouvait pas raisonnablement procéder sans montrer pourquoi les signaux périmés observés n’impliquaient pas un échec mondial inacceptable.

Cet équilibre est de plus en plus pertinent au-delà du DNS. Les changements d’infrastructure modernes impliquent souvent une télémétrie bruyante provenant de clients, d’agents, de résolveurs, de certificats, de gestionnaires de paquets ou de terminaux distribués. La leçon du roulement de la KSK est que des preuves imparfaites ne doivent ni paralyser ni être rejetées. Elles doivent déclencher une interprétation transparente et des critères de décision responsables.

Ce que l’ICANN contrôlait et ce qu’elle ne contrôlait pas

L’ICANN contrôlait le processus central de la KSK par le biais de ses fonctions IANA et de son rôle de Public Technical Identifiers, y compris les cérémonies des clés, la publication, les documents de planification, la consultation communautaire, la sensibilisation, les conseils techniques, l’escalade au Conseil d’administration, la recommandation d’exécution/arrêt, la surveillance et l’examen post-événement. L’ICANN ne contrôlait pas chaque résolveur validant, chaque paquet logiciel, chaque fenêtre de changement de FAI, chaque configuration d’entreprise ou chaque contrat DNS du secteur public.

Verisign contrôlait la fonction de mainteneur de la zone racine et exploitait l’infrastructure des serveurs racine pertinente pour l’observation et la coordination. Elle ne contrôlait pas l’état des validateurs locaux à l’intérieur de chaque réseau. Les projets de logiciels de résolveur contrôlaient la qualité de l’implémentation du comportement de la RFC 5011 et de la validation DNSSEC. Les fabricants d’appareils et les distributions de systèmes d’exploitation contrôlaient l’empaquetage et les comportements par défaut. Les opérateurs de réseau contrôlaient le déploiement.

Les agences publiques et les entreprises contrôlaient l’approvisionnement, la surveillance et la planification de secours.

Les utilisateurs finaux ne contrôlaient presque rien de tout cela. Un citoyen dont le résolveur FAI échouait à la validation ne saurait pas si la cause était une ancre de confiance périmée, une défaillance DNSSEC, un problème de routage, un problème d’application ou une panne de site Web. Une petite entreprise utilisant un routeur géré ne saurait pas si son appareil DNS avait accepté KSK-2017. Cette asymétrie est la raison pour laquelle la responsabilité doit incomber aux opérateurs d’infrastructure plutôt qu’aux utilisateurs.

La question de responsabilité n’est donc pas « Qui possédait Internet? » Personne. La question est de savoir qui contrôlait chaque partie conséquente du roulement. L’ICANN contrôlait l’autorité centrale et la coordination publique. Les opérateurs contrôlaient la préparation. Les éditeurs contrôlaient le code. Les institutions publiques contrôlaient les attentes de continuité. Chacun avait un devoir différent.

Cette carte en couches empêche également un récit de succès superficiel. L’ICANN a bien fait de reporter et de procéder après preuves. Mais les futurs roulements ne devraient pas dépendre d’une sensibilisation héroïque à chaque fois. Les opérateurs de résolveurs devraient institutionnaliser l’inventaire des ancres de confiance. Les éditeurs devraient rendre l’état de validation visible. Les agences publiques devraient exiger des preuves de continuité DNSSEC de la part des fournisseurs. La gouvernance de la zone racine devrait continuer à publier des plans et des examens.

Le succès devrait devenir une pratique reproductible, pas un souvenir ponctuel.

Le prochain roulement devrait hériter des preuves, pas de la chance

La page actuelle de l’ICANN sur le roulement de l’algorithme de la KSK racine montre que la maintenance cryptographique de la zone racine se poursuit. Un futur roulement d’algorithme diffère du roulement de clé de 2018 car il change l’algorithme cryptographique plutôt que de simplement remplacer une clé RSA par une autre clé RSA. Ce travail futur rend le dossier de responsabilité de 2018 plus précieux, pas moins. Le premier roulement a créé un modèle pour la planification publique, la sensibilisation, la télémétrie, l’approbation du Conseil d’administration, les conseils aux opérateurs et l’examen après action.

Le modèle devrait être amélioré. Premièrement, la télémétrie devrait être plus facile à relier pour les opérateurs à leur propre infrastructure. Un signal central est moins utile si un opérateur ne peut pas dire quel appareil l’a produit. Deuxièmement, les logiciels de résolveur devraient exposer l’état de l’ancre de confiance de manière à ce que les équipes réseau ordinaires puissent le surveiller. Troisièmement, les achats du secteur public et des entreprises devraient traiter le DNS récursif comme une infrastructure de continuité.

Quatrièmement, la désactivation d’urgence de la validation devrait être exercée comme un dernier recours et suivie d’une restauration, et non normalisée comme une solution de contournement à long terme. Cinquièmement, l’ICANN devrait continuer à publier les critères de décision à l’avance afin que les futurs reports ou décisions d’exécution puissent être évalués par rapport à une norme connue.

Le roulement de 2018 montre également la valeur d’une confiance limitée. L’ICANN a procédé après avoir reconnu que certains opérateurs ne seraient pas préparés. C’est honnête. Les infrastructures critiques ne peuvent pas attendre une conformité parfaite de chaque entité. Mais un risque résiduel honnête devrait être accompagné de preuves de récupération: qui surveille, comment les problèmes seront détectés, quels seuils déclenchent l’annulation, comment les opérateurs obtiennent de l’aide, et comment les leçons après action sont publiées.

La même norme devrait s’appliquer aux réseaux du secteur public. Les agences devraient savoir qui fournit le DNS récursif, si la validation est activée, si les ancres de confiance racine se mettent à jour automatiquement, si des alarmes de défaillance DNSSEC existent, et comment joindre le fournisseur pendant un changement cryptographique de la zone racine. Si une agence publique ne peut pas répondre à ces questions, elle a délégué la continuité sans conserver la responsabilité.

La leçon durable

Le dossier du roulement de la KSK racine 2016-2018 de l’ICANN est un exemple solide de responsabilité opérationnelle car il contient le milieu inconfortable: le plan, le signal d’alarme, le report, les commentaires publics, le plan révisé, l’approbation du Conseil d’administration, l’exécution, la surveillance et l’examen. L’histoire n’est pas « L’ICANN a changé une clé et rien ne s’est passé. » L’histoire est que l’ICANN et la communauté DNS ont traité un changement de clé comme un risque opérationnel mondial et ont rendu le risque suffisamment visible pour le gérer.

Le roulement a réussi sans impact persistant significatif sur les utilisateurs finaux, selon la déclaration publique post-événement de l’ICANN. Ce succès doit être attribué à la préparation distribuée autant qu’à la coordination centrale. L’ICANN contrôlait le processus de la KSK racine et la décision. Verisign et d’autres opérateurs racine ont contribué à l’observation opérationnelle. Les éditeurs et les opérateurs de résolveurs ont fait fonctionner la validation sur le terrain. Les propriétaires de réseaux publics et privés ont porté la responsabilité de leur propre continuité.

La leçon de responsabilité est durable. Une ancre de confiance centrale est une promesse publique, pas un élément de configuration privé. Lorsqu’elle change, l’organisation dotée de l’autorité centrale doit publier le plan, écouter la télémétrie, reporter lorsque les preuves le justifient, définir des seuils d’échec, communiquer des étapes pratiques aux opérateurs et examiner le résultat. Les opérateurs qui s’appuient sur l’ancre de confiance doivent connaître leurs propres systèmes, tester la préparation, surveiller les défaillances et préparer la récupération.

Le premier roulement de la KSK racine DNSSEC n’a pas prouvé que les futurs changements cryptographiques de la racine sont sans risque. Il a prouvé que les changements d’infrastructure partagée peuvent être effectués de manière responsable lorsque l’autorité est associée à des preuves et lorsque la confiance technique est maintenue suffisamment humble pour arrêter le calendrier. C’est la norme de responsabilité que le prochain roulement devra respecter.