L’Union européenne élabore actuellement sa deuxième directive sur la sécurité des réseaux et de l’information (NIS2) et je suis préoccupé par le langage utilisé pour décrire le système de noms de domaine (DNS) ainsi que par les effets négatifs que la législation aura sur la sécurité et la résilience du DNS.
À l’heure actuelle, trois projets différents de NIS2 sont en circulation. Le Parlement européen vient d’approuver un projet qui sera ensuite comparé aux versions élaborées par le Conseil européen (États membres de l’Union européenne) et la Commission européenne (branche exécutive de l’UE à Bruxelles) en vue d’être négocié jusqu’à ce que les parties s’accordent sur un texte unique.
Nous avons déjà parlé du NIS2. J’aimerais maintenant que l’on se concentre sur le projet du Conseil européen et sur un aspect spécifique du DNS, pour montrer à quel point la réalité technique diffère de l’intention réglementaire.
L’objectif du NIS2 est de s’assurer que l’infrastructure sur laquelle l’Europe s’appuie pour son activité économique est sûre et fiable. C’est un objectif louable. À vrai dire, l’Internet Society estime que toute infrastructure Internet sur laquelle les gens doivent compter pour leur activité sociale et économique se doit d’être sûre et digne de confiance, quel que soit l’endroit où ils vivent.
Afin d’atteindre cet objectif de sécurité, le NIS2 veut réglementer le système des noms de domaine (DNS). Le considérant 15 de la version du Conseil européen du projet NIS2 se lit désormais comme suit :
“Therefore, this Directive should apply to all providers of DNS services along the DNS provisioning and resolution chain that are of importance for the internal market, the entities providing domain name registration services, the including operators of root name servers with a significant footprint in the EU, top-level-domain (TLD) name registries servers, the entities providing domain name registration services,operators of authoritative name servers for domain names and operators of recursive resolvers”
(Ce passage est tiré du document 12019/2/21 Rev2 d.d. du 25 octobre 2021, qui n’est pas accessible au public, les textes barrés et les caractères gras indiquant les modifications récentes apportées au projet de texte).
L’annexe de la version du Conseil se lit désormais comme suit : « Les fournisseurs de services DNS, notamment les opérateurs de serveurs de noms racine ayant une empreinte significative dans l’UE (plus de 10 sites dans l’UE). »
Si nous examinons ce langage à travers le prisme des piliers de sécurité de l’infrastructure des serveurs DNS, le langage du Conseil n’ajoute aucune mesure de sécurité ni fiabilité. Ci-dessous, nous examinons d’abord l’intégrité et l’authenticité, puis la disponibilité [1].
Intégrité et authenticité
Au sujet de la sécurité et la fiabilité, nous devons d’abord considérer la question de l’intégrité des informations fournies par le DNS. Les informations sur un domaine que l’utilisateur reçoit d’un résolveur DNS sont-elles les informations correctes et précises que l’opérateur du domaine a introduites dans le DNS ? L’intégrité est garantie par les extensions de sécurité du DNS (DNSSEC). Avec DNSSEC, les informations fournies ont été signées cryptographiquement par l’éditeur de l’information. Quel que soit le mode de réception de ces informations, les utilisateurs peuvent vérifier de manière cryptographique que les réponses sont exactement les mêmes que celles publiées par le propriétaire du domaine. Peu importe l’endroit où se trouve le serveur de noms, ou même son degré de sécurité, les informations sont signées et ne peuvent donc pas être modifiées. L’intégrité est donc préservée. Grâce aux propriétés cryptographiques des signatures, nous savons quelle entité a publié une information DNS particulière, ce qui garantit également l’authenticité.
Indépendamment de la taille de l' »empreinte », le fait d’avoir plus ou moins de serveurs de noms n’a pas d’impact sur l’authenticité et l’intégrité des informations DNS. Le fait d’avoir des DNSSEC en a. Heureusement, l’état du déploiement des DNSSEC au niveau national dans l’UE est assez avancé (voir ici nos cartes de déploiement).
En ce qui concerne l’intégrité et l’authenticité du DNS, les dispositions de NIS2 concernant les serveurs de noms ne feront aucune différence. Elles peuvent avoir un impact sur la fourniture des informations DNS elles-mêmes (par l’intermédiaire des bureaux d’enregistrement et des registres) mais pas sur la manière dont ces informations sont mises à disposition sur Internet.
Disponibilité
L’authenticité et l’intégrité n’étant pas affectées par les dispositions relatives aux serveurs de noms de NIS2, est-on certain que NIS2 améliorera au moins la disponibilité, et donc la fiabilité et la sécurité ?
Pour comprendre cela, examinons la disponibilité depuis la perspective de l’utilisateur. Lorsque l’utilisateur saisit un nom de domaine dans un navigateur Web, par exemple, ce nom de domaine est envoyé à un résolveur récursif DNS local pour rechercher une adresse IP. Le résolveur récursif interroge ensuite les serveurs de noms faisant autorité, tels que les serveurs racine, pour obtenir une réponse au nom de l’utilisateur.
Au cours de ce processus, le résolveur récursif établit une liste interne de toutes les adresses IP des serveurs de noms faisant autorité sur lesquels des informations sur un certain nom de domaine sont disponibles.
Le résolveur récursif choisit ensuite au hasard l’une des adresses IP des serveurs de noms faisant autorité pour demander une réponse. L’endroit où se trouve ce serveur faisant autorité n’a aucune importance pour le résolveur récursif. Au moins une implémentation courante des résolveurs récursifs ne se soucie pas de savoir sur quel continent ou dans quelle région économique se trouve l’adresse IP, elle choisit au hasard dans le monde entier[2].
(Soit dit en passant, la raison pour laquelle il fait cela est d’empêcher l’attaque dite de Kaminsky à laquelle le DNS est vulnérable en l’absence de DNSSEC, voir https://www.nlnetlabs.nl/documentation/unbound/patch-announce102/ et https://www.nlnetlabs.nl/documentation/unbound/info-timeout/).
Pour améliorer la résilience, la disponibilité et les performances du système DNS, les opérateurs de services DNS ont largement utilisé une technique appelée « anycast ». L’idée est que des copies exactes d’un serveur DNS, incluant son adresse IP, sont déployées à de nombreux endroits dans l’infrastructure du réseau. Ces serveurs sont appelés « instances » (et non sites, comme dans l’annexe) et s’il existe plusieurs instances sur Internet, chacune attirera le trafic qui lui est proche en termes de topologie du réseau. Ce sont des aimants à trafic.
Créer plus d’instances d’un serveur de noms vous permet de réaliser deux choses. Premièrement, si la sélection aléatoire choisit l’adresse IP du serveur de noms, le fait de disposer d’une instance proche dans la topologie du réseau vous permettra d’obtenir une réponse plus rapide. Deuxièmement, une instance attirera tout le trafic local. Ainsi, si l’IP d’un serveur de noms fait l’objet d’une attaque par déni de service (DOS) de grande ampleur, ces instances attireront le trafic d’attaque local, permettant aux opérateurs de réseau de mieux identifier les attaquants et d’y répondre. Un plus grand nombre d’instances signifie une plus grande capacité à faire face aux attaques DOS, ce qui signifie à son tour que les résultats seront moins débilitants. Plus le nombre d’instances est élevé, moins les citoyens européens sont touchés par les attaques DOS de grande envergure.
Par conséquent, plus il y a d’instances de serveurs de noms sur le réseau, plus celui-ci est sécurisé. Idéalement, pour la racine, il faudrait que tous les opérateurs déploient plusieurs instances de serveurs de noms sur le sol européen. De cette façon, vous pouvez être sûr que l’algorithme aléatoire répondra toujours rapidement. La résilience et les performances s’en trouvent améliorées.
Cependant, NIS2 incitera-t-il à la création de plus de serveurs de noms ? En particulier des serveurs racine ?
Je ne pense pas que ce sera le cas. En fait, les opérateurs de serveurs de noms risquent d’envisager de réduire le nombre de serveurs de noms à moins de 10 afin d’échapper au champ d’application de la réglementation. Par conséquent, en l’état, la directive incite à réduire la résilience et la disponibilité.
Responsabilité
Plus généralement, si l’on regarde la dernière phrase du considérant 15.
« les entités fournissant des services d’enregistrement de noms de domaine, les opérateurs de serveurs de noms faisant autorité pour les noms de domaine et les opérateurs de résolveurs récursifs. »
Les opérateurs de résolveurs récursifs font partie de la chaîne d’approvisionnement des entreprises et des fournisseurs de services Internet (ISP) qui choisissent de les utiliser. De même, les serveurs de noms faisant autorité font partie d’une chaîne d’approvisionnement dont le détenteur du domaine est responsable en dernier ressort. De même, les serveurs de noms faisant autorité font partie d’une chaîne d’approvisionnement dont le détenteur du domaine est responsable en dernier ressort. En définitive, ceux qui mettent à disposition un service reposant sur un nom de domaine sont responsables de la disponibilité de ce service. Cette responsabilité se répercute sur les contrats et crée ainsi une culture de la sécurité. La responsabilité est garantie de bas en haut, et non de haut en bas.
Si le Conseil européen et la Commission européenne entendent prévenir les risques d’une approche descendante de la réglementation du DNS qui pourrait sérieusement fragmenter l’Internet et réduire la sécurité en ligne, ils devraient s’inspirer de la version du Parlement européen du texte NIS2, qui a exclu les serveurs de noms racine du champ d’application. En fait, il faudrait aller plus loin et exclure le système de serveurs racine dans son ensemble, à la fois en raison des arguments techniques ci-dessus, mais aussi parce qu’il est déjà régi par les meilleures pratiques dans un processus ouvert et multipartite.
[1] Les piliers de la sécurité sont la confidentialité, l’intégrité, l’authenticité et la disponibilité. Nous ne discutons pas de la confidentialité, car bien qu’il s’agisse d’un élément important pour rendre le DNS plus sûr et digne de confiance, elle ne joue aucun rôle dans le projet de texte.
[2] Je décris le comportement du serveur de noms récursif Unbound, à la conception duquel j’ai participé. Ce serveur traite tous les serveurs qui sont à moins de 400 ms de temps aller-retour (n’importe où dans le monde) comme des serveurs analogues.