Vers un DNS moins indiscret

L’Afnic travaille, notamment au sein du CENTR et de l’IETF, à améliorer la protection de la vie privée pour les utiisateurs du DNS.

Le protocole DNS est un élément peu connu mais crucial de l’infrastructure de l’Internet. Aujourd’hui où les préoccupations sur la vie privée ont pris beaucoup d’ampleur, il est donc normal de se pencher sur la question « DNS et vie privée ». Tout utilisateur de l’Internet se sert abondamment du DNS, même s’il ne s’en rend pas compte, et même s’il ignore tout du DNS et des noms de domaine. À chaque fois que cet utilisateur envoie un message, qu’il clique sur un lien hypertexte, que son ordinateur met à jour ses logiciels, il y a une (et souvent bien plus d’une) requête DNS. Mais, autant les questions de vie privée liées au protocole du Web, HTTP, ont été longuement discutées (qu’on songe aux débats comme « faut-il une autorisation explicite de l’utilisateur pour placer des cookies ? » ou bien « l’adresse IP est-elle une donnée nominative ? »), autant celles liées au DNS ont été d’abord négligées, puis ensuite étudiées uniquement dans un petit cercle, essentiellement à l’IETF. La sortie prochaine du RFC « DNS privacy considerations » sera la première manifestation officielle de cet intérêt.

Quelles sont au juste les questions de vie privée que pose le DNS ? Imaginez que vous vous connectez au site Web des Alcooliques Anonymes. Vous tapez le nom de domaine, ou le sélectionnez dans un signet, ou le trouvez grâce à un moteur de recherche. Dans tous les cas, votre navigateur Web va faire une requête DNS pour trouver les informations associées au nom de domaine. Aussi bien les gérants des serveurs DNS qui traiteront cette requête, que les tiers qui espionnent le réseau, sauront donc ce que vous faites sur le Web, ce qui n’est pas forcément de votre goût. Bien sûr, la connexion HTTP elle-même révélera aussi des choses sur votre visite. Mais il y a deux raisons de se pencher sur le rôle du DNS : la première est que les autres protocoles sont sécurisés petit à petit contre la surveillance, et que le DNS, s’il ne fait rien, pourrait devenir « le maillon faible » de la confidentialité, et la deuxième, c’est que le DNS met en jeu d’autres acteurs. Ainsi, si un résident en France visite un site Web français, il peut avoir l’impression que des acteurs étrangers ne peuvent pas suivre son activité, puisque, apparemment, tout se passe sur le territoire français. Mais cette « analyse de sécurité » est trop sommaire. Si, par exemple, le site Web a un nom en .com, les requêtes DNS ont été traitées et observées par des serveurs états-uniens, même si client et serveur HTTP étaient tous les deux en France.

Notez qu’on parle bien ici de la nécessaire confidentialité des requêtes. Les données, elles, posent nettement moins de problèmes puisqu’elles sont publiques. En d’autres termes, ce n’est pas l’adresse IP des Alcooliques Anonymes qu’il faut maintenir confidentielle, c’est le fait que M. Michu l’ait demandée.

Il faut donc renforcer la protection de la vie privée dans le DNS. L’Afnic participe à cette activité depuis le début, au sein du CENTR puis de l’IETF, et en a été moteur, avant même les révélations de Snowden, puisque le travail avait commencé à la réunion générale du CENTR à Amsterdam en juin 2013. La réunion de l’IETF à Vancouver, en novembre 2013, a été l’occasion de faire passer ce travail au sein du principal organisme de normalisation de l’Internet.

La méthode habituelle, pour améliorer la protection de la vie privée, est de marcher sur deux jambes : minimiser la quantité de données envoyées et chiffrer cet envoi. La première solution protège notamment contre un serveur indiscret, la seconde contre un tiers qui écouterait sur le réseau. Ces deux approches sont toutes les deux nécessaires, puisqu’elles ne protègent pas contre les mêmes adversaires.

Aujourd’hui, trois travaux différents sont en cours à l’IETF :

1. documenter la question, et c’est le rôle du futur RFC « DNS privacy considerations », déjà mentionné. Il n’y aura pas forcément de solutions techniques parfaites mais, au moins, les acteurs de l’Internet qui font des analyses de sécurité pourront avoir un document de référence sur les questions liées au DNS. Les deux travaux suivants portent sur les solutions (les « deux jambes » dont j’ai parlé plus haut).
2. chiffrer le trafic DNS, dans la mesure du possible. Le débat technique est actuellement vif, avec plusieurs solutions proposées. Une fois adoptée, la solution retenue devra être déployée dans tous les serveurs DNS, aussi bien les résolveurs que les serveurs faisant autorité (par exemple ceux de l’Afnic).
3. minimiser la quantité de données envoyées, en cessant de transmettre la question complète à tous les serveurs (y compris ceux de la racine). Aujourd’hui, si M. Michu fait une requête DNS pour tracker.thepiratebay.se, les serveurs de la racine (et tous les autres serveurs DNS impliqués) voient la requête complète alors que, puisqu’ils ne connaissent que les TLD, il suffirait de leur demander les serveurs de noms de .se. C’est le mécanisme suggéré par le futur RFC « QNAME minimisation ». Une fois adopté, il devra être déployé dans une catégorie particulière de serveurs DNS, les résolveurs.

L’Afnic, on l’a vu, était pionnière dans ce travail, et continue à consacrer les efforts nécessaires à son aboutissement.