Si l’on se réfère à l’article de Geoff Huston intitulé “Calling time on DNSSEC ?“, il est indéniable que l’économie s’oppose à l’adoption des extensions de sécurité des systèmes de noms de domaine (DNSSEC).
Bien que les DNSSEC aient été déployés dans la plupart des domaines de premier niveau (TLD) de l’espace de noms du système de noms de domaine (DNS) public mondial (figure 1), et malgré les incitations financières fournies par les registres et la disponibilité de bases de code et d’ensembles d’outils gratuits et à source ouverte, les avantages économiques n’ont pas été favorables. Le problème du DNSSEC n’est pas seulement d’ordre économique ; c’est peut-être sa conception même qui s’oppose à son adoption.
L’architecture de DNSSEC a été initialement définie dans les années 1990. L’internet en était encore à l’ère du “best effort” ; les hôtes et les protocoles connectés n’étaient pas sûrs et il existait peu de bonnes pratiques pour contrer les activités malveillantes et s’en remettre. Alors que l’espace de noms DNS commençait à prendre forme, il n’existait pas à l’époque d’hébergement ou de fourniture commerciale significative. Du point de vue des outils, il n’existait qu’une seule plate-forme dominante à code source ouvert.
Le DNSSEC a commencé par trois objectifs techniques visant à protéger les données au fur et à mesure qu’elles circulent dans le système DNS :
- Authentification des données – les données sont celles qui sont configurées.
- L’intégrité des données – les données sont complètes.
- Authentification des réponses négatives – sécurisation de l’absence de réponse.
Quelques principes directeurs et observations tirés de ce premier environnement ont été utilisés pour discuter de la manière dont les objectifs seraient atteints et dont les décisions prises ont influencé la conception des DNSSEC.
Nous ne pouvons pas faire confiance aux hôtes qui possèdent des clés privées”.
Les signatures numériques ont été choisies pour assurer l’authentification et l’intégrité des DNSSEC. À l’époque de cette conception, la sécurité de l’hôte était d’une médiocrité inacceptable. La (ou les) clé(s) privée(s) utilisée(s) pour générer les signatures devait (devaient) être conservée(s) dans des ordinateurs hors réseau, en s’appuyant sur des supports amovibles pour combler le fossé.
Ainsi, la conception du protocole exigeait que toutes les réponses soient précalculées, sans qu’aucune donnée de réponse ne soit générée sur la base d’une requête. Ceci est acceptable pour les résultats positifs lorsqu’il y a une correspondance directe, mais il y a trois autres types de réponses dans le DNS : les réponses négatives, les réponses synthétisées et les réponses redirigées.
Une réponse négative pré-calculée et fourre-tout semble être une approche probable, mais elle est sujette à une attaque par rejeu. DNSSEC a choisi une approche qui nécessite de trier les données dans une zone, puis de révéler les plages de données afin que le demandeur puisse déterminer que ce qu’il veut n’existe pas. Les inconvénients de cette méthode sont que les réponses sont plus nombreuses et qu’elles révèlent plus d’informations qu’il n’en faut. Ce seul fait est suffisamment significatif pour avoir suscité une nouvelle approche des réponses négatives impliquant des réponses plus larges et plus confuses.
Les réponses précalculées pour les requêtes synthétisées, communément appelées “wildcards” dans le DNS, et les réponses redirigées impliquant des enregistrements de ressources CNAME et DNAME requièrent le DNSSEC pour révéler le travail effectué par le répondeur à l’auteur de la requête. Cela s’ajoute aux problèmes liés aux réponses négatives précalculées.
Une alternative est la signature à la volée, qui consiste à confier à des serveurs en ligne des clés privées pour générer des signatures. Bien qu’il ne s’agisse pas d’une solution automatique, cela se fait dans la pratique et s’est avéré faisable, mais cela nécessite que tous les serveurs de noms soient sous le contrôle d’un seul opérateur. Dans la pratique, l’intégration d’une approche de signature à la volée dans un protocole qui suppose des réponses précalculées est compliquée. Cette complexité suggère qu’une refonte du protocole est justifiée.
Le travail d’un administrateur de zone
La RFC 1034 fait référence à un “administrateur de zone”, ce qui conduit à l’idée d’une entité unique responsable d’une zone. Avec le mantra général “mon réseau, mes règles” dans l’exploitation d’un réseau, cette orientation a créé l’idée que la zone était une entité autonome, singulièrement responsable de sa sécurité. Tout au long du protocole, il est fait mention de la “politique locale” chaque fois que des choix opérationnels doivent être faits.
Cela a entravé le rôle de la relation de délégation parent-enfant dans la conception des DNSSEC. Le DNS ayant simplifié la structure de délégation, le DNSSEC a suivi le mouvement. Il en résulte une conception qui n’a pas fonctionné dans la pratique.
Il était prévu que l’adoption de DNSSEC se ferait de bas en haut, à mesure que les administrateurs de zone reconnaîtraient ses avantages et agiraient en conséquence. Il a été supposé que les DNSSEC évolueraient vers le haut de l’espace de nommage, la racine pouvant être signée en dernier, une fois que la technologie aurait été testée de manière approfondie et aurait atteint un niveau de fiabilité élevé. Un élément important était l’utilisation d’ancres de confiance (TA), en particulier dans les cas où une zone était signée mais que sa zone mère ne l’était pas.
Aujourd’hui, DNSSEC connaît exactement le contraire. Au départ, quelques TLD pionniers existaient avant la signature de la zone racine en 2010. Aujourd’hui, certains estiment que plus de 90 % de la racine, du TLD et d’autres zones d’infrastructure sont signés, tandis que les estimations concernant la signature dans l’arborescence se situent en dessous de 10 %. Actuellement, la seule AT gérée à grande échelle concerne la zone racinaire.
Un lien plus fort entre les zones parents et enfants pourrait potentiellement résoudre de nombreux problèmes auxquels sont confrontés aujourd’hui le provisionnement ou l’enregistrement des DNS. Il s’agit notamment de faciliter le rafraîchissement dynamique des références de sécurité (clés) et le transfert en douceur du contrôle d’un administrateur de zone ou d’un opérateur de backend à un autre, surtout si l’on considère comment et pourquoi le DNSSEC s’est développé du haut vers le bas. C’est pourquoi les efforts de l’IETF (Internet Engineering Task Force) pour développer un enregistrement appelé DELEG sont importants pour les DNSSEC.
Le contact avec le parent doit être réduit au minimum
En rapport avec la section précédente, ce mantra se concentre sur l’échange d’informations sur les clés cryptographiques entre les zones enfant et parent. Cela a conduit à la création du rôle cryptographique de point d’entrée sécurisé (SEP), qui à son tour a conduit à la notion de rôle de clé de signature de clé (KSK) et de rôle de clé de signature de zone (ZSK).
La création de ces deux rôles clés s’appuie sur des observations faites lors d’ateliers : lorsque DNSSEC exige du parent qu’il modifie les enregistrements en fonction des changements de clé de l’enfant, le parent peut être lent à réagir. Pour permettre une plus grande flexibilité dans la gestion des changements de clés, un ZSK pouvant être modifié sans nécessiter de mises à jour de la part du parent a été introduit.
Cependant, le fait d’avoir deux clés double instantanément la charge de travail du gestionnaire de clés. L’introduction de ces deux rôles a également rendu l’explication de DNSSEC (via des diapositives ou des présentations) beaucoup plus difficile. Malgré l’algorithme de validation établi, il existe peu de règles strictes régissant l’utilisation de ces deux rôles, ce qui peut compliquer la mise en œuvre. Alors que la plupart des opérations adhèrent à des pratiques spécifiques avec ces rôles, la définition du protocole et le logiciel supportant DNSSEC ne peuvent pas supposer des pratiques communes universelles.
Il est possible d’utiliser DNSSEC avec une seule clé dans une zone, c’est-à-dire une clé de signature commune (CSK). Cette clé peut être modifiée aussi souvent que nécessaire, ce qui simplifie la gestion, en particulier grâce aux progrès de l’approvisionnement automatisé. Cette approche a évolué après que le système DNSSEC a été confronté à des difficultés liées à des pratiques rigides.
Toutes les zones sont égales
Lorsque le DNSSEC était en cours de développement, la zone .com était vaste et remplie presque entièrement, voire entièrement, de délégations. Il était si grand que le tout premier signataire du DNSSEC a dû jouer de quelques tours pour signer la zone. Aussi tentant que cela puisse paraître de traiter .com et potentiellement d’autres grandes zones comme “spéciales” dans la conception du DNSSEC, l’idée dominante était qu’une conception de protocole plus simple, rationalisée, toutes les zones étant les mêmes, devait être l’objectif à atteindre.
La position unique de la zone racine est un aspect critique qui a été initialement négligé dans la conception des DNSSEC. Contrairement à d’autres zones qui ont des zones mères pour établir la sécurité des clés publiques, la zone racine est autonome et ne peut pas dépendre d’une zone mère pour la validation. Pour ce faire, il est nécessaire d’utiliser des clés de confiance préconfigurées, disponibles dans tous les validateurs DNSSEC. La gestion des AT, en particulier pour la zone racinaire, reste un défi. Rétrospectivement, la distribution et la gestion à grande échelle des AT pour la zone racinaire auraient dû être une considération primordiale dès le départ.
Développeur ou opérateur
Après le développement initial, une série de petits ateliers DNSSEC a été organisée, invitant ceux qui géraient des serveurs DNS à y participer. Pendant cinq ans, ces événements ont été organisés dans de nombreuses régions du monde afin d’attirer des experts pour contribuer à la conception du DNSSEC. Les résultats de cette étude ont permis d’élaborer la définition actuelle de DNSSEC.
Le plan initial de développement des DNSSEC était solide. Toutefois, les participants impliqués n’étaient pas nécessairement représentatifs du paysage opérationnel d’aujourd’hui. S’ils avaient de l’expérience dans la gestion des services DNS, nombre d’entre eux maîtrisaient également la mise en forme de protocoles et possédaient des compétences en programmation, ce qui leur permettait de naviguer dans la complexité sans dépendre uniquement des outils disponibles. Cette dynamique a conduit à un excès de confiance dans la conception du protocole, suggérant souvent que l’amélioration de l’éducation ou de l’outillage est le premier besoin.
Il est nécessaire de reconnaître que les faibles statistiques d’adoption sont une critique du développement des DNSSEC, plutôt que de supposer qu’il s’agit d’un cas de promotion ou d’éducation plus poussée. S’il y a des opérateurs qui ne connaissent pas les DNSSEC ou qui les considèrent comme trop intimidants, il y en a beaucoup qui les connaissent bien et qui ont des raisons de ne pas les déployer. Ces raisons doivent être collectées, traitées et utilisées dans toute démarche future.
Hypothèses sur la cryptographie
Bon nombre des scénarios prévus pour l’utilisation de la cryptographie dans les DNSSEC ont été inspirés par des histoires ou des légendes sur la façon dont la cryptographie a été utilisée dans des contextes militaires ou gouvernementaux. À l’époque, les connaissances du public en matière de cryptographie étaient limitées, de sorte que ces histoires et légendes ont constitué des sources cruciales d’exigences et d’inspiration pour le développement des DNSSEC.
À en juger par les premiers scénarios d’utilisation, les opérateurs d’aujourd’hui ont tendance à adopter une approche minimaliste, en utilisant aussi peu de clés que nécessaire et en s’en tenant généralement à un seul algorithme à la fois. Cette approche permet de minimiser la complexité opérationnelle et de réduire la taille des réponses DNS, ce qui est essentiel pour optimiser les performances du réseau. Les opérateurs accordent également la priorité aux paramètres cryptographiques par défaut fournis par les progiciels, en conciliant le besoin de sécurité et les considérations pratiques de mise en œuvre. L’étude de l’utilisation de la cryptographie dans les DNSSEC devrait conduire à des approches compatibles avec l’utilisation commerciale de l’internet, en garantissant à la fois la sécurité et l’efficacité.
Pourquoi revisiter le passé ?
Ces observations ne changeront peut-être pas la voie vers un DNS sûr ; elles peuvent simplement servir de leçons historiques. Ils pourraient également guider la conception des futurs remplaçants des DNSSEC ou inspirer des approches visant à renforcer la sécurité dans les systèmes existants. Cependant, ils mettent en évidence les pièges potentiels de la conception et pourraient contribuer aux efforts visant à rendre les DNSSEC plus conviviaux pour les opérateurs.
Adapté de l’article original paru sur le blog de l’APNIC.
Edward Lewis est connu pour ses travaux sur le DNS et le DNSSEC, les domaines Internet, les registres de numéros et la recherche sur la sécurité des réseaux. Il est membre de l’équipe initiale qui a conçu et réalisé le prototype de DNSSEC. Il participe activement à des forums sectoriels et intervient fréquemment en tant qu’orateur.
Les opinions exprimées par les auteurs de ce blog sont les leurs et ne reflètent pas nécessairement celles de l’Internet Society.