Où le DNSSEC s'est-il trompé ?

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 nommage public mondial du système de noms de domaine (DNS) (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 des DNSSEC n'est pas seulement d'ordre économique ; c'est peut-être leur conception qui s'oppose à leur adoption.

L'architecture de DNSSEC a été initialement établie dans les années 1990. L'internet en était encore à l'époque du "best effort" ; les hôtes et les protocoles connectés n'étaient pas sécurisés, 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'y avait pas d'hébergement commercial significatif ou de provisionnement à l'époque. Du point de vue des outils, il n'existait qu'une seule plateforme open-source dominante.

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 :

1. Authentification des données - les données sont celles qui sont configurées.
2. L'intégrité des données - les données sont complètes.
3. Authentification des réponses négatives - sécurisation des "non réponses".

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 de la façon dont les décisions prises ont influencé la conception des DNSSEC.

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é des hôtes é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. Cela est acceptable pour les résultats positifs lorsqu'il y a une correspondance directe, mais il existe 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 voulait n'existe pas. Les inconvénients de cette approche sont des réponses plus volumineuses et la révélation de plus d'informations que nécessaire. Ce seul fait est suffisamment important pour justifier 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 exigent que le DNSSEC révèle au demandeur le travail effectué par le répondeur. Cela s'ajoute aux problèmes liés aux réponses négatives précalculées.

Une autre solution 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, cette méthode est appliquée dans la pratique et s'est avérée réalisable, mais elle exige que tous les serveurs de noms soient sous le contrôle d'un seul opérateur. En 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.

La RFC 1034 fait référence à un "administrateur de zone", ce qui a 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" lorsque 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 des DNSSEC se ferait de bas en haut, au fur et à mesure que les administrateurs de zone en reconnaîtraient les avantages et agiraient en conséquence. Il a été supposé que les DNSSEC se développeraient 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 pas sa zone mère.

Aujourd'hui, DNSSEC connaît exactement le contraire. Au départ, quelques TLD pionniers existaient avant que la zone racine ne soit signée en 2010. Aujourd'hui, certains estiment que plus de 90 % des zones racine, TLD et autres zones d'infrastructure sont signées, tandis que les estimations pour la signature en bas de l'arborescence oscillent autour de 10 %. Actuellement, la seule TA gérée à grande échelle est celle de la zone racine.

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 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 dorsal à 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.

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 de clé s'est appuyée sur des observations faites lors d'ateliers : lorsque DNSSEC exigeait du parent qu'il modifie les enregistrements sur la base des changements de clé de l'enfant, le parent pouvait être lent à réagir. Pour permettre une plus grande flexibilité dans la gestion des changements de clés, une ZSK qui peut être modifiée sans nécessiter de mises à jour de la part du parent a été introduite.

Cependant, le fait d'avoir deux clés double instantanément la charge de travail d'un 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 DNSSEC a été confronté à des pratiques rigides.

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 du DNSSEC. Contrairement aux autres zones qui ont des zones parentes pour établir la sécurité des clés publiques, la zone racine est autonome et ne peut pas compter sur une zone parente pour la validation. Il est donc nécessaire d'utiliser des TA - des clés de confiance préconfigurées disponibles dans tous les validateurs DNSSEC. La gestion des TA, en particulier pour la zone racine, reste un défi. Rétrospectivement, la distribution et la gestion à grande échelle des AT pour la zone racine auraient dû être une considération primordiale dès le départ.

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 eu lieu dans de nombreuses régions du monde afin d'attirer des experts pour aider à façonner la conception du DNSSEC. Les résultats de ces ateliers ont permis d'élaborer la définition actuelle des DNSSEC.

Le plan initial de développement des DNSSEC était solide. Cependant, les participants impliqués ne représentaient pas nécessairement le paysage opérationnel d'aujourd'hui. S'ils avaient l'expérience de l'exploitation des services DNS, nombre d'entre eux étaient également des adeptes de l'élaboration de protocoles et possédaient des compétences en programmation, ce qui leur permettait de naviguer dans les complexités sans s'appuyer uniquement sur les outils disponibles. Cette dynamique a conduit à un excès de confiance dans la conception du protocole, suggérant souvent que l'amélioration de la formation ou des outils est la première nécessité.

Il est nécessaire de reconnaître que les statistiques de faible adoption sont une critique du développement des DNSSEC, plutôt que de supposer qu'il faudrait davantage de promotion ou d'éducation. 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 recueillies, traitées et utilisées dans toute démarche future.

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 avait é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 ces 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 donnent également la priorité aux paramètres cryptographiques par défaut fournis par les logiciels, en équilibrant 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, garantissant à la fois la sécurité et l'efficacité.

Ces observations ne changeront peut-être pas la voie vers un DNS sécurisé ; elles peuvent simplement servir de leçons historiques. Elles pourraient également guider la conception des futurs remplaçants du DNSSEC ou inspirer des approches visant à renforcer la sécurité au sein des systèmes existants. Toutefois, elles 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 originale qui a conçu et réalisé le prototype du DNSSEC. Il est actif dans les forums de l'industrie et intervient fréquemment en tant que conférencier.

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.