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é racine DNSSEC d'octobre 2018 de l'ICANN a modifié l'ancre de confiance publique utilisée par les résolveurs validant DNSSEC pour valider la racine DNS. La page de l'ICANN sur le roulement 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 a fait de la préparation un enjeu de continuité plutôt qu'une simple tâche de maintenance cryptographique.
• Le fait de responsabilité le plus marquant est le report. L'ICANN a reporté le roulement initialement prévu en octobre 2017 après que la télémétrie nouvellement disponible via le RFC 8145 ait suggéré qu'un nombre significatif de résolveurs utilisés par les FAI et les opérateurs de réseau pouvaient ne pas être prêts. Cette décision a transformé un problème caché de préparation des opérateurs en un dossier de gouvernance publique.
• 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'ont pas indiqué de défaillance systémique nécessitant un retour en arrière.
• 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 assurait 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 la mise en œuvre du RFC 5011; les agences publiques et les entreprises contrôlaient la planification de repli pour leurs propres réseaux.
• La leçon en matière de responsabilité est que les changements dans 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 le retour en arrière sûr 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 validant 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 considérer les réponses valides comme erronées et échouer la résolution de noms ordinaire pour ses utilisateurs.

La page dédiéeRoot Zone KSK Rolloverde l'ICANN est la source d'ancrage. Elle explique que l'ICANN a effectué le roulement le 11 octobre 2018, que rouler la KSK signifie générer une nouvelle paire de clés publique et privée et distribuer la composante publique aux opérateurs de résolveurs validants, et qu'il est essentiel de maintenir une KSK à jour car l'absence de la KSK de la zone racine actuelle signifie que les résolveurs validant DNSSEC seront incapables de résoudre les requêtes DNS. C'est tout le problème de responsabilité en langage clair. Un changement dans un objet de confiance central devient une panne pour les utilisateurs lorsque les opérateurs répartis n'ont pas mis à jour l'état de validation local.

La KSK n'existait pas de manière isolée. La page de l'ICANN sur le roulement 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 la fin du rôle de la NTIA le 1er octobre 2016. La pageIANA Root Zone Managementfournit le point d'entrée public actuel pour la gestion de la zone racine, tandis que la pageIANA DNSSEC Root Zone KSKfournit des informations sur l'ancre de confiance et la cérémonie KSK. Le dossier opérationnel se situe donc à l'intersection de la gouvernance de l'ICANN, des fonctions PTI/IANA, des opérations de la zone racine de Verisign et des nombreux opérateurs de résolveurs indépendants qui consomment l'ancre de confiance racine.

L'architecture technique de DNSSEC elle-même explique pourquoi l'incident était important. LeRFC 4033définit l'introduction et les exigences de DNSSEC, leRFC 4034définit les enregistrements de ressources utilisés par DNSSEC, et leRFC 4035dé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 décisive. Un résolveur validant dispose ou non d'un chemin de confiance qu'il accepte. 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 vaste. 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 la propre annonce de l'ICANN concernant le report de 2017 estimait qu'environ un quart des utilisateurs mondiaux d'Internet, soit environ 750 millions de personnes, dépendaient de résolveurs validant DNSSEC et pouvaient ê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'était pas une panne. C'était un test de responsabilité mené avant une éventuelle panne. La gouvernance des infrastructures publiques n'est souvent jugée qu'après un échec. Ici, le dossier de gouvernance est significatif parce que l'ICANN a reporté avant l'échec, a rouvert le plan, a recueilli davantage de preuves, a élargi la sensibilisation et a pris plus tard une décision d'aller de l'avant avec une acceptation explicite du risque.

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

L'événement le plus important du dossier s'est produit avant le roulement réussi. L'annonce de report du27 septembre 2017de l'ICANN 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 significatif de résolveurs utilisés par les FAI et les opérateurs de réseau n'étaient pas encore prêts. Elle a lié la nouvelle visibilité à une fonctionnalité récente du protocole DNS permettant aux résolveurs de signaler aux serveurs racine quelles clés ils avaient configurées.

Cette fonctionnalité était leRFC 8145, qui définit un moyen pour les résolveurs validants de signaler les ancres de confiance configurées. Le protocole ne donnait pas à l'ICANN une connaissance parfaite. Il créait une vue bruyante, partielle et opérationnellement sensible de l'état de 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 était néanmoins un événement de gouvernance. L'ICANN devait décider de procéder comme prévu malgré les signaux indiquant que certains résolveurs étaient obsolètes, ou de 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 à louer avec le recul car le roulement ultérieur a réussi. À l'époque, elle avait 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 uniquement 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 indiquait que l'ICANN contactait la communauté, y compris le SSAC, les registres Internet régionaux, les groupes d'opérateurs de réseau et autres. Elle citait le PDG de l'ICANN disant 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 des preuves de préparation nouvellement découvertes modifieraient la décision. Dans les opérations d'infrastructure, c'est la différence entre un changement piloté par le calendrier et un changement piloté 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 leur propre logiciel et configuration 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 du RFC 5011 était utile, pas magique

Le roulement dépendait fortement du comportement automatisé de mise à jour des ancres de confiance. LeRFC 5011définit les mises à jour automatisées des ancres de confiance DNSSEC. L'attrait du RFC 5011 est évident: un résolveur validant peut observer la nouvelle clé pendant une période d'attente d'ajout 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 variables. 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 d'attente, recevoir et valider le matériel DNSKEY pertinent, et éviter les choix de configuration locaux qui contrecarrent la mise à jour automatique. Les opérateurs doivent également savoir si leur résolveur valide réellement, s'il transmet à un autre résolveur, si la version de son paquet se comporte correctement et si les systèmes de gestion de configuration écrasent l'état de l'ancre de confiance.

La pageKSK rolloverde Verisign a saisi cette distinction du point de vue du mainteneur de la zone racine et du serveur racine. Elle disait que chaque validateur DNSSEC a besoin d'une ancre de confiance et que le RFC 5011 n'avait jamais été testé en production pour un roulement de la KSK racine. Elle indiquait également que Verisign, en tant qu'opérateur de serveur de noms racine, recevait certaines données du 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 des logiciels de résolveur, la sensibilisation auprès des opérateurs qui semblaient dépassés, les commentaires publics, les discussions sur les listes de diffusion et la surveillance post-événement. Cela incluait également la volonté de définir un seuil de retour en arrière si l'échec était suffisamment répandu.

Lerapport final de l'équipe de conception du roulement de la KSK de la zone racineest un contexte utile car il a exposé un processus de conception pour le premier roulement de la KSK racine avant le report de 2017. Il recommandait un échelonnement délibéré, une communication et des mesures précisément parce que l'Internet n'avait jamais connu auparavant un 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 échelonnée.

La leçon n'est pas que le 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 pagePlan to Restart the Root Key Signing Key Rollover Processa 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, une analyse plus poussée des données de préparation et le roulement effectif le 11 octobre 2018. LePlan for Continuing the Root KSK Rollover PDFassocié décrivait la relance proposée après le report antérieur.

Cette étape est importante parce que la légitimité technique et la légitimité institutionnelle étaient des questions différentes. L'ICANN aurait pu être techniquement capable de changer la clé tout en étant politiquement irresponsable si elle ignorait les preuves communautaires sur la préparation. Inversement, la communauté aurait pu exiger un report indéfini, mais un report indéfini créerait également une dette opérationnelle. Les commentaires publics ont forcé le désaccord à être consigné: quelles données devaient être fiables, quelle sensibilisation était suffisante, quel seuil d'échec devait être utilisé et qui prendrait la décision finale.

Lerapport du personnel sur les commentaires du plan préliminaireest une preuve de cette étape de traduction. Il n'a pas fait disparaître tous les risques. Il a montré que l'ICANN a 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 les preuves et les objections visibles avant que l'autorité n'agisse.

L'annonce de l'approbation du Conseil d'administrationde 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.

Lesrésolutions du Conseil d'administration de l'ICANN du 16 septembre 2018sous-jacentes sont l'artefact formel de gouvernance. Elles sont importantes parce que la décision d'aller de l'avant n'était pas seulement une action technique du personnel. 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 pas être roulée uniquement lorsque l'incertitude est nulle, car l'incertitude nulle n'arrive jamais.

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

Les supports de sensibilisation de l'ICANN étaient des contrôles opérationnels. La page sur le roulement renvoyait vers des ressources pourvérifier les ancres de confiance actuelles dans les résolveurs validant le DNSetmettre à jour les résolveurs validants avec la dernière ancre de confiance. Ces documents n'étaient pas du marketing. C'étaient des instructions pratiques pour les opérateurs qui contrôlaient le dernier kilomètre de la préparation.

LeGuide complet sur ce à quoi s'attendre pendant le roulement de la KSK racinea fourni une autre forme de contrôle: la gestion des attentes. Les opérateurs devaient savoir ce qui changerait, quand cela changerait, comment les symptômes pourraient se manifester et quoi faire si la validation échouait. Un changement central silencieux aurait laissé chaque enquête sur une panne repartir des premiers principes. Un guide public a donné aux services d'assistance, aux équipes réseau et au personnel de sécurité un cadre commun.

Lesmatériels de roulement de la KSK de DNS-OARCet les lieux communautaires d'opérateurs connexes comptaient pour la même raison. DNS-OARC n'est pas l'ICANN, et son rôle ne doit pas être gonflé en une autorité centrale de gouvernance. Il est utile en tant que canal public de la communauté technique où les opérateurs de résolveurs et les spécialistes du DNS pouvaient partager les tests et les observations. Les changements dans l'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 action déployable.

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 d'éducation sur DNSSEC. Il serait vécu comme une incapacité à atteindre les services.

La leçon en matière de continuité pour le secteur public est que les améliorations de la 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 en amont valide. L'équipe réseau d'un hôpital peut s'appuyer sur un appareil DNS géré. Un district scolaire peut hériter du comportement du résolveur d'un 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 pouvaient échouer sans laisser entendre que tout l'Internet s'éteindrait. 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 reprise d'urgence sans en faire l'option par défaut. Cet équilibre est opérationnellement difficile. Trop peu d'alarme entraîne l'inaction. Trop d'alarme entraîne la méfiance envers le mécanisme de sécurité lui-même.

La décision d'aller de l'avant a accepté le 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 le risque résiduel après une sensibilisation, une analyse et une consultation communautaire supplémentaires. Cette distinction est au cœur de 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 en dépendaient. 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 procéder était toujours justifié: les défaillances attendues étaient suffisamment petites, suffisamment récupérables et compensées par la nécessité d'exercer le processus de roulement de la clé.

Le dossier public comprenait également un concept de retour en arrière. L'annonce de la réussite du premier roulementde l'ICANN a indiqué par la suite 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 déclencher un retour en arrière. Cette phrase est importante car elle montre que le succès a été évalué par rapport à un seuil opérationnel explicite, et pas seulement par rapport à un optimisme a posteriori.

Le retour en arrière n'est pas anodin 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 de retour en arrière 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 dispose au moins d'un critère public pour savoir quand la stabilité l'emporte sur l'achèvement.

La décision d'aller de l'avant 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 analysaient les signaux ont créé la préparation. Les examinateurs communautaires qui contestaient les hypothèses ont créé la préparation. L'ICANN a coordonné et décidé, mais elle n'a pas, à elle seule, rendu le système distribué prêt.

C'est la carte de responsabilité fondamentale. L'ICANN avait autorité sur l'opération centrale de la KSK racine et la responsabilité de la sensibilisation et de la gouvernance des décisions. Les opérateurs de résolveurs avaient la responsabilité de leur propre configuration de validation. Les fournisseurs avaient la responsabilité de la mise en œuvre. 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é discret 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 un nombre significatif d'utilisateurs finaux d'Internet qui aient été impactés de manière persistante et négative. Elle indiquait que les quelques problèmes survenus ont été rapidement atténués et n'indiquaient pas une défaillance systémique nécessitant un retour en arrière. Elle indiquait également que l'ICANN procéderait à la révocation de l'ancienne KSK, KSK-2010, lors de la prochaine cérémonie de clé au premier trimestre 2019.

L'examen du roulement de la KSK DNSSEC 2018ultérieur est la source post-événement la plus solide. Il 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. Il 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 confondu avec la preuve que le risque avait été surestimé. De nombreux changements d'infrastructure deviennent discrets précisément parce que les opérateurs ont reporté, testé, communiqué et surveillé. Un test de charge sur un pont qui détecte une faiblesse avant l'effondrement n'est pas une fausse alerte. C'est l'objet du test. Le report de 2017 fait donc partie du succès de 2018, et non une tache distincte.

Le dossier post-événement a également limité la portée des déclarations. Il ne disait pas que personne n'avait été affecté. Il disait 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 niveau correct pour un changement d'infrastructure mondial. Certains opérateurs individuels ont peut-être eu des problèmes locaux. La question pertinente était de savoir si le changement de l'ancre de confiance racine avait provoqué une défaillance généralisée et durable 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 horodatage unique.

Le pouvoir de délégation DNS est réel même lorsqu'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, les délégations de TLD, les relations avec les bureaux d'enregistrement et la propriété des noms. Le roulement de la KSK montre une autre forme de pouvoir de délégation: le contrôle sur la chaîne de confiance de validation de la zone racine. L'ICANN n'a pas redélégué un TLD ni modifié le domaine d'un titulaire. Elle a modifié la clé cryptographique que les résolveurs validants utilisent pour décider si les données racine signées peuvent être fiables.

Ce pouvoir est limité. L'ICANN opère dans le cadre de déclarations de pratiques techniques, d'examens communautaires, de gouvernance du Conseil d'administration, d'attentes relatives aux fonctions IANA, de coordination avec les partenaires de la zone racine et d'un examen mondial. Pourtant, c'est toujours un pouvoir. Une mauvaise opération de clé centrale pourrait faire apparaître des données correctement signées comme invalides 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.

LaDéclaration de pratiques DNSSEC de l'opérateur KSK de la zone racineest pertinente car elle définit les attentes quant à la manière dont l'opérateur 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 roulé la clé, elle n'exerçait pas simplement un pouvoir discrétionnaire; elle exerçait une responsabilité opérationnelle documentée.

LeIANA Trust Anchor XMLet l'emplacement de publication des ancres racineassocié font également partie de ce pouvoir. Ils rendent le matériel d'ancre de confiance publiquement disponible sous des formes lisibles par machine et vérifiables par l'homme. 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 jusqu'à 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 préjudices, 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'avec 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 de l'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 ne blâme ou ne crédite que l'ICANN omet 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 du fournisseur et les attentes de continuité.

Le document de l'ICANN sur lavérification des ancres de confiance actuelleset celui sur lamise à jour des résolveurs validantsfournissaient des étapes pratiques, mais les opérateurs devaient les utiliser. Une organisation centrale ne peut pas compenser indéfiniment les négligences locales. Un résolveur dont la validation est activée mais sans surveillance des échecs 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 le 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 des services partagés, des fournisseurs de cloud, des fournisseurs de sécurité gérée, des intégrateurs réseau ou des contrats télécom. Ces agences ne sont peut-être pas des experts DNS, mais elles peuvent toujours exiger des preuves de la part des fournisseurs: si la validation DNSSEC est activée, quel logiciel de résolveur est utilisé, comment les ancres de confiance racine sont mises à 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 reprise. 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 le risque 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éé la responsabilité d'interpréter, pas la certitude

La signalisation des ancres de confiance du 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 pensait 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 imparfaite. C'est une bonne gouvernance, mais cela crée également la 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 une télémétrie ultérieure montre encore des signaux périmés, les dirigeants doivent décider si ces signaux représentent un impact significatif sur les utilisateurs ou un bruit résiduel gérable.

L'examen du roulement et les mises à jour techniques montrent ce fardeau analytique. Lapage de ressources sur le roulement de l'ICANNa rassemblé les mises à jour techniques, les documents d'examen et les conseils aux opérateurs en un seul endroit. Lamise à jour du 18 décembre 2017 sur le projet de roulement de la KSK racinedocumentait l'état de l'analyse après le report. L'objectif de ces documents n'est pas de produire une confiance parfaite. C'est d'empêcher que la décision ne soit motivée par des rumeurs.

La responsabilité liée à 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 une défaillance mondiale 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 distribués, d'agents, de résolveurs, de certificats, de gestionnaires de paquets ou de points de terminaison. 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 de clé, la publication, les documents de planification, la consultation communautaire, la sensibilisation, les conseils techniques, l'escalade au Conseil d'administration, la recommandation d'aller/ne pas aller, la surveillance et l'examen post-événement. L'ICANN ne contrôlait pas chaque résolveur validant, chaque progiciel, chaque fenêtre de changement des 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 de serveur racine pertinente pour l'observation et la coordination. Elle ne contrôlait pas l'état du validateur local dans chaque réseau. Les projets de logiciels de résolveur contrôlaient la qualité de la mise en œuvre du comportement du 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 repli.

Les utilisateurs finaux ne contrôlaient presque rien de cela. Un citoyen dont le résolveur du FAI échouait la validation ne saurait pas si la cause était une ancre de confiance obsolète, un échec 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é la 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 appartenait l'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 fournisseurs 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 avoir recueilli des preuves. Mais les futurs roulements ne devraient pas reposer à chaque fois sur une sensibilisation héroïque. Les opérateurs de résolveurs devraient institutionnaliser l'inventaire des ancres de confiance. Les fournisseurs 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 les plans et les 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 leroulement de l'algorithme de la KSK de la zone racinemontre 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 modifie l'algorithme cryptographique plutôt que de simplement remplacer une clé RSA par une autre clé RSA. Ces travaux futurs rendent le dossier de responsabilité de 2018 plus précieux, et non 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 à leur propre infrastructure pour les opérateurs. 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 d'une manière que les équipes réseau ordinaires peuvent surveiller. Troisièmement, l'approvisionnement du secteur public et des entreprises devrait traiter le DNS récursif comme une infrastructure de continuité. Quatrièmement, la désactivation d'urgence de la validation devrait être exercée en 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 reports ou les décisions d'aller de l'avant futurs 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 reprise: qui surveille, comment les problèmes seront détectés, quels seuils déclenchent le retour en arrière, 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, s'il existe des alarmes en cas d'échec DNSSEC et comment joindre le fournisseur lors d'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 il ne s'est rien 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 être géré.

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é autant à la préparation distribuée qu'à la coordination centrale. L'ICANN contrôlait le processus KSK racine et la décision. Verisign et d'autres opérateurs racine ont contribué à l'observation opérationnelle. Les fournisseurs et opérateurs de résolveurs ont fait fonctionner la validation sur le terrain. Les propriétaires de réseaux publics et privés ont assumé la responsabilité de leur propre continuité.

La leçon en matière 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 les étapes pratiques pour les opérateurs et examiner les résultats. 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 reprise.

Le premier roulement de la KSK racine DNSSEC n'a pas prouvé que les futurs changements cryptographiques 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 suffisamment humble pour arrêter le calendrier. C'est la norme de responsabilité que le prochain roulement devra respecter.