Navigation – Plan du site

AccueilNuméros132-133Quand la gouvernance d'Internet f...La prise de décision dans la norm...

Quand la gouvernance d'Internet fait controverse

La prise de décision dans la normalisation technique Internet : l’exemple de DoH

Stéphane Bortzmeyer

Résumé

L’Internet repose sur de nombreuses techniques normalisées. C’est par exemple le cas du protocole HTTP, qui permet à un navigateur Web de visiter un site Web, même si les deux logiciels, le client et le serveur, ont été écrits par des équipes complètement différentes. C’est également le cas de protocoles plus techniques, comme IP ou le DNS. Mais qui décide de ces normes techniques et comment ? La question n’est pas de pure curiosité car les normes déterminent en grande partie ce qui sera facile ou au contraire difficile à faire sur l’Internet. Prenons l’exemple du protocole DoH qui a fait l’objet de vives controverses. Pourquoi ce qui semble un choix purement technique soulève des passions ? Quels sont les camps en présence, leurs opinions, et leurs moyens d’action ?

Internet depends on standardised techniques. One example is HTTP, the protocol that allows a Web browser to visit a Web site. HTTP works even if the two programs, the client and the server, were written by different software teams. There are other, more technical protocols, like IP and DNS. Who decides on these protocols ? How is that decision taken ? It is not just idle curiosity since these standards will set what is easy to do or difficult to achieve on the Internet. As an exemple, we will study the design of the DoH protocol. Despite the fact that it may seen a purely technical subject, DoH raised some controversy. Who were the parties, what were the arguments and how the final outcome will be decided ?

Haut de page

Texte intégral

Introduction

1La principale innovation de l’Internet avait été l’idée d’un réseau hétérogène, formé de machines et de logiciels d’origines différentes, mais parlant la même langue, plus exactement les mêmes protocoles. La définition et la rédaction de ces protocoles se nomment la normalisation technique, et c’est habituellement un sujet discret, qui reste « sous le radar » de nombre d’observateurs de l’Internet. Ces protocoles forment pourtant une part importante de l’infrastructure de l’Internet et permettent d’expliquer certaines de ses propriétés ; ainsi, la discrétion qui entoure habituellement le monde de la normalisation technique se voit parfois mise à l'épreuve lorsqu’une controverse émerge du milieu des organismes de normalisation.

2Une illustration récente, et particulièrement efficace, de cette affirmation concerne la controverse qui entoure le protocole DNS over HTTPS, ou « DoH ». DoH est un protocole qui permet d’effectuer une résolution DNS (obtenir des informations techniques à partir d’un nom de domaine), via le protocole HTTPS, afin d’accroître la confidentialité et l’intégrité du système de noms de domaine (DNS). Dès son déploiement effectif, le protocole DoH a fait l’objet de vives controverses.

3Cet article explore les raisons pour lesquelles ce qui semble un choix purement technique soulève des passions et montre quels sont les camps en présence, leurs opinions, et leurs moyens d’action. En conclusion, l’article propose des éléments de réflexion sur la normalisation technique d’Internet, ses acteurs et ses tendances à venir.

Pour commencer cette étude de cas, notons que l’analyse de la normalisation technique et de ses conséquences politiques a une particularité : les questions techniques et politiques sont entremêlées. Il faut donc rappeler deux ou trois éléments techniques avant de commencer.

Un peu de technique pour commencer

  • i Les protocoles qui ne sont pas client/serveur sont souvent appelés « pair-à-pair », mais ce terme r (...)

4D’abord, rappelons la notion de protocole, si cruciale au bon fonctionnement de l’Internet. Internet ne se limite pas à un type particulier de machines, ce qui en fait sa principale caractéristique et ce qui le distingue de la plupart des autres projets de réseaux informatiques du passé : l’Internet connecte des équipements très variés, issus d’équipes différentes, et utilisant des logiciels développés de manière indépendante. Pour assurer l’interopérabilité, c’est à dire le fait que ces équipements différents puissent communiquer, on utilise la notion de protocole : un protocole est un ensemble de règles que les machines doivent suivre afin de se comprendre. En général, le protocole est décrit par un texte, la spécification, et cette spécification est parfois formalisée dans une norme, lorsqu’elle a été développée et approuvée par un organisme de normalisation. Beaucoup de protocoles Internet sont « client/serveur », avec une machine qui attend les requêtes (le serveur) et une machine qui a quelque chose à demander (le client)i

5Un des protocoles les plus connus est HTTP (Hypertext Transfer Protocol), le protocole de base du Web. Pour qu’un navigateur Web (par exemple Mozilla Firefox) puisse se connecter à un serveur Web, il faut qu’ils parlent le même protocole, en l’occurrence HTTP. Chaque protocole a des caractéristiques techniques propres, qui ont des conséquences pour les utilisateurs. Ainsi, HTTP est bavard, le protocole permettant, voire obligeant de nombreux envois d’informations depuis le navigateur vers le serveur contacté, ce qui a des conséquences pour la vie privée.

  • ii Le terme technique pour ces adresses Web est URL (Uniform Resource Locator).
  • iii Ce nom comporte un caractère composé (le e avec accent). De tels noms, permettant d’utiliser tous l (...)

6Moins connu, mais essentiel à la bonne marche de l’Internet, il y a aussi le protocole DNS (Domain Name System). Les ressources disponibles sur l’Internet sont désignées par des identificateurs (par exemple l’adresse du site Webii de l’Afnic est https://www.afnic.fr/​ et ce https://www.afnic.fr/​ est un identificateur). Ces identificateurs comprennent souvent un nom de domaine, comme www.ox.ac.uk, potamochère.friii ou video.exodus-privacy.eu.org. Le DNS est le protocole qui permet, à partir de ces noms, d’obtenir les informations techniques nécessaires aux logiciels. La très grande majorité des activités sur l’Internet nécessite au début un appel au DNS, et ce protocole s’avère donc critique. Le DNS est un protocole client/serveur et il existe deux sortes de serveurs, nous évoquerons ici principalement les serveurs résolveurs, les seuls auxquels l’utilisateur ordinaire parle directement. Ils sont typiquement gérés par votre fournisseur d’accès à l’Internet, ou par le service informatique d’une entreprise ou université, mais il existe aussi des résolveurs publics, accessibles à tous.

Contexte

7L’auteur a participé directement au travail qui a mené à DoH (DNS sur HTTPS) et cet article est donc en grande partie issu d’une expérience personnelle. Le point de départ était la prise de conscience, à peu près à l’époque des révélations d’Edward Snowden, du fait que le DNS était souvent le maillon faible de la vie privée. Cela a contribué à la constitution d’un projet « DNS et vie privée » à l’IETF (Internet Engineering Task Force), à l’écriture de la description du problème (Bortzmeyer, 2015), et aux développements de plusieurs solutions techniques (Hu et al., 2016 ; Bortzmeyer, 2016). Ensuite, l’auteur a participé au développement de DoH, entre autres à l’occasion des hackathons (séances de développement logiciel collectives) de l’IETF, puis aux débats qui ont émergé par la suite. Les observations effectuées à ces occasions, aussi bien pendant les réunions physiques que via les listes de diffusion où s’effectue une grande partie du travail, forment la base de cet article.

  • iv Une adresse Web qui commence par « https » (le s signifiant « secure ») indique que la communicatio (...)
  • v Bien des solutions de chiffrement actuellement existantes nécessitent une action explicite de l’uti (...)

8Voyons d’abord le problème que DoH (DNS over HTTPS, c’est-à-dire DNS sur la version sécurisée de HTTP) essaye de résoudre. Comme le notent Farrell et al. (2014), la surveillance des utilisateurs s’avère massive et systématique dans l’Internet d’aujourd’hui. Tout le monde peut se retrouver exposé à une surveillance ciblée, facilitée par les capacités du numérique. Protéger la vie privée des utilisateurs est aujourd’hui l’un des critères les plus importants à considérer lors de la mise au point d’un nouveau service, et de nombreuses techniques sont développées pour protéger cette vie privée. Une des plus fréquentes, le chiffrement du trafic, empêche un surveillant de pouvoir comprendre les données échangées. Si des protocoles comme HTTP sont aujourd’hui très largement chiffrésiv, le DNS reste encore largement en clair, donc analysable par un tiers qui observe les communications. Bortzmeyer (2015) détaille les menaces sur la vie privée liées au DNS. En l'absence de chiffrement généralisév, protéger sa vie privée demeure difficile, alors que cela devrait être un droit de base, avec un chiffrement par défaut.

9Plusieurs solutions ont été développées pour traiter ces menaces liées au DNS. L’une d’elles concerne le chiffrement de la communication entre la machine de l’utilisateur final et le résolveur, la machine qui recevra les requêtes DNS et les fera suivre aux serveurs appropriés. Plus précisément, deux méthodes ont été normalisées, DoT (DNS over TLS), décrit dans Hu et al. (2016) et DoH (DNS over HTTPS), dans Hoffman et al. (2018). Ces deux méthodes fournissent un service très proche : chiffrer la requête DNS envoyée par la machine de l’utilisateur au résolveur, ainsi que la réponse. Ainsi, un surveillant ne pourra pas déterminer si l’utilisateur final a fait une requête pour journals.openedition.org ou pour alcooliques-anonymes.fr. Les différences entre DoT et DoH sont subtiles, mais importantes afin de comprendre les débats entrainés par ces deux protocoles. DoT utilise un port, un identificateur de service, à lui, numéroté 853. Un équipement réseau peut donc facilement le reconnaître et le bloquer, par exemple pour forcer l’utilisation d’une communication en clair, analysable. DoH, au contraire, utilise le même port que HTTPS, le 443 et le trafic DoH est donc indistinguable du trafic HTTPS, rendant son filtrage plus difficile. En outre, DoH utilise les mêmes techniques que le Web et peut plus facilement être directement intégré au navigateur Web. Aucune de ces deux méthodes n’est spécialement privilégiée par l’IETF. Comme toujours sur l’Internet, c’est le déploiement qui décide.

Chiffrer ou ne pas chiffrer

  • vi Formé à partir des noms de Google, Apple, Facebook et Amazon, ce terme désigne toutes les entrepris (...)

10Publiquement, tout le monde reconnaît aujourd’hui l’importance du chiffrement pour la sécurité. À ne considérer que les déclarations publiques, on pourrait croire que le chiffrement fait l’objet d’un consensus. Toutefois, beaucoup des personnes ou des organisations qui affirment soutenir le chiffrement sont en réalité « pour le chiffrement, mais… ». Régulièrement, on voit des tentatives, plus ou moins assumées, d’affaiblir le chiffrement. En effet, le monde des acteurs de l’Internet n’est pas homogène. Loin de l’image d’une mythique « communauté Internet », qui aurait des valeurs et des opinions communes, les acteurs de l’Internet sont variés et divisés. Ces divisions recoupent souvent les lignes qui séparent différentes places dans le processus de production. Ainsi, les GAFAvi sont souvent favorables au chiffrement car, comme ils sont situés à un bout de la communication, ils ont de toute façon accès au contenu en clair, et se soucient surtout de ne pas laisser cet accès à d’autres acteurs. Au contraire, les FAI (Fournisseurs d’Accès à l’Internet) sont souvent plus hostiles au chiffrement (ou plutôt « favorables, mais ») car ils ne contrôlent pas ou plus les extrémités de la communication et ne peuvent surveiller les communications qu’en chemin, lorsqu’elles passent dans les tuyaux qu’ils gèrent. De même, la fracture des opinions reflète souvent des fractures nationales puisque, en Europe, les FAI sont nationaux et les fournisseurs de services, les GAFA, sont états-uniens.

  • vii Payment Card Industry Data Security Standard, une norme de processus dans le secteur financier, imp (...)

11On voit que la sécurité, dont on parle souvent au singulier, est en fait plurielle, tout le monde n’ayant pas les mêmes intérêts. Et puis il n’y a jamais de solution parfaite en sécurité, uniquement des compromis. Prenons l’exemple du réseau d’une entreprise où la direction informatique voudrait regarder les requêtes DNS sortantes, pour détecter les machines internes qui ont été infectées par un logiciel malveillant, et cherchent à contacter le centre de contrôle de ce logiciel, identifié par un nom de domaine. La détection de ces machines infectées, et la protection de la vie privée sont en nette opposition, il faudra donc faire un choix. Notons que peu d’acteurs assument ouvertement leur position de défense de leurs intérêts, et emballent leur discours derrière des références à l’« intérêt des utilisateurs » ou à « la sécurité » présentée comme un service monolithique, alors qu’elle comprend au contraire de nombreux aspects, souvent contradictoires. Ainsi, une banque peut être à la fois soumise à des obligations de surveillance généralisée de son personnel, en raison de normes de traçabilité comme PCI-DSSvii, et aux lois qui protègent la vie privée des travailleurs, même au sein de l’entreprise.

12On voit ainsi, dans le monde de la normalisation technique, des débats agités au sujet du chiffrement. Un exemple typique fut la discussion à l’IETF, de 2014 à 2018, sur une nouvelle version du protocole de cryptographie TLS (Transport Layer Security), la 1.3. Cette version avait pour but de combler plusieurs failles de sécurité des versions précédentes. Mais certains acteurs, par exemple des entreprises (Housley et al., 2018), utilisaient ces failles, à des fins de « visibilité » (surveillance du trafic). Ils s’étaient donc opposés à TLS 1.3, réclamant que des mesures soient prises dans la norme pour rétablir une certaine visibilité. Moriarty et al. (2018) donnent la parole aux organisations qui défendent l’importance de la « visibilité » sur le trafic réseau.

La normalisation technique

13La normalisation demeure l’un des aspects les moins étudiés de la « gouvernance Internet ». Peut-être en raison de son caractère technique, peut-être aussi parce que ses acteurs préfèrent la discrétion. On voit donc bien, comme le notait l’appel à proposition pour ce numéro de Terminal, que les analyses de la « gouvernance de l'Internet » ont trop souvent un « caractère centré sur les institutions formelles », les jeux politiciens de l’ICANN suscitant plus d’intérêt que les discussions technico-politiques dans les SDO (Standard Development Organisation). Il est également possible qu’une autre raison de ce manque d’intérêt soit la complexité du paysage. Il n’y a pas d’organisme de normalisation officiel, mais une multitude d’organisations, sans mécanisme de décision entre leurs normes, à part les décisions de déploiement ou non, effectuées par une multitude d’acteurs. Ainsi, il peut être tentant, quand on a échoué dans une SDO, d’aller en voir une autre. Après que l’IETF ait normalisé TLS 1.3 sans introduire de faille permettant la « visibilité », l’ETSI (European Telecommunications Standards Institute) a accepté de normaliser une version affaiblie de TLS, ETLS (Enterprise TLS). Comme pour toute autre technologie Internet, son déploiement effectif ne dépend pas des décisions des SDO, mais de celles des auteurs de logiciels qui incorporeront ou pas ce standard, des administrateurs de systèmes informatiques et de réseaux, qui choisiront ou pas d’activer tel ou tel protocole, avec telle ou telle option, et des utilisateurs, lorsque logiciels et administrateurs les laissent choisir.

14Certains auteurs ont fait une différence entre « norme » et « standard ». Les définitions données sont variées, et pas toujours correctes, par exemple quand on lit que, contrairement aux « standards », les normes auraient un caractère obligatoire, ou bien que les normes, elles, seraient issues d’organismes de normalisation « officiels ». Mais il n’existe pas de tels organismes (l’Afnor, Association française de normalisation, n’est pas le Parlement et, pour décrire ses propres activités, elle parle de « normalisation volontaire »). Bref, « norme » et « standard » seront traités ici comme des termes équivalents. Et on ne parle que de norme technique, car les textes de loi suivent un processus différent.

15Parmi les études qui ont porté sur les aspects politiques de la normalisation dans le domaine des réseaux informatiques, on peut citer celles de (Lapowsky, 2021) ou (Sire, 2017), sur le W3C (World-Wide Web Consortium). D’autres études ont porté sur la normalisation dans d’autres secteurs, comme celles de (Easterling, 2016) sur la SDO ISO (International Organization for Standardization), ou bien de l’excellent (Levinson, 2008) sur un objet emblématique de la normalisation, le conteneur. Un débat fréquent concerne le pouvoir exact de la normalisation : peut-on faire respecter un choix politique (par exemple la défense des droits humains) via de la normalisation technique ? Badiei (2021) estime, lui, que c’est illusoire, les mécanismes techniques n’étant jamais suffisant pour faire respecter une politique.

  • viii Ces « couches » font référence à un modèle souvent utilisé pour décrire les différentes fonctions q (...)

16La principale organisation de normalisation traitée dans cet article est l’IETF, qui gère les protocoles de l’Internet « de la couche 3 à la couche 7viii », c’est-à-dire en dehors des questions purement physiques, qui sont plutôt couvertes par l’IEEE (Institute of Electrical and Electronics Engineers), et sans compter les normes les plus proches des utilisateurs qui, pour le Web, sont en général traitées par le W3C (World Wide Web Consortium). Ainsi, si le protocole HTTP est du ressort de l’IETF, le format HTML (Hypertext Markup Language) est, lui, normalisé par le W3C. Le travail de l’IETF n’a pas suscité de nombreuses publications mais il existe des études comme comme celles de Morris et al. (2003), Mathew (2014), ou encore, plus récemment, Cath (2021).

17Les normes IETF sont publiées dans des documents nommés RFC (Request for Comments), qui sont librement et gratuitement disponibles. La plupart des RFC décrivent une norme technique, mais certains portent sur des questions d’architecture ou de politique. Les RFC « politiques », plus spectaculaires, comme (IAB, 1996), sont souvent les plus remarqués mais, dans cet article, on ne parlera que des RFC « techniques ». Relativement peu d’études ont porté sur ces RFC, mais on peut citer (Braman, 2010), qui porte surtout sur les RFC eux-mêmes davantage que sur la façon dont ils sont produits. L’auteure note que ces normes techniques sont proches d’une loi dans la mesure où elles déterminent bien des actions possibles et impossibles. Au contraire, ten Oever (2020) insiste plus sur leur processus de production.

18L’IETF affirme son ouverture à tous et toutes, chacun et chacun peut participer, et sans avoir à payer de droit d’entrée, comme c’est le cas dans d’autres SDO. Toutefois, comme pour toute organisation humaine, il existe une certaine distance entre la description que l’organisation fait d’elle-même et la réalité. Ainsi, une participation effective à l’IETF nécessite beaucoup de temps et de la compétence technique, ce qui limite son ouverture. Ce n’est pas vraiment un problème spécifique à l’IETF, toute organisation humaine demande un effort d’intégration lorsqu’on veut y peser. En pratique, l’IETF est donc largement dominée par des organisations puissantes, qui peuvent se permettre de dédier du personnel à cette tâche de normalisation. (Schneier, 2019) appelle d’ailleurs à ce que davantage de personnes s’impliquent dans les aspects politiques de la technique, ce qui inclut la normalisation.

L’histoire de DoH

19La création de la norme DoH est une bonne illustration de la façon dont fonctionne l’IETF. Le premier projet a été écrit en mai 2017, le groupe de travail DoH est créé en septembre, l’adoption officielle du projet par le groupe de travail date d’octobre de la même année, et le RFC (Hoffman et al., 2018) a été publié en octobre 2018. C’est assez rapide pour une norme IETF, mais il faut dire que DoH est simple techniquement, et qu’aucune objection de fond, ni de problème technique sérieux, n’avaient été soulevés pendant les travaux du groupe. Contrairement au cas de TLS 1.3, aucune opposition ne s’était manifestée lors de la mise au point du RFC. Le groupe de travail sera formellement dissous en mars 2020, sans avoir publié d’autres RFC (des projets avaient été évoqués, mais pas poursuivis). C’est le sort normal d’un groupe de travail IETF ayant terminé le travail prévu.

20Des personnes découvrant DoH après son déploiement se sont parfois demandées comment l’IETF avait pu prendre la décision de normaliser ce protocole. Très orientée vers l’efficacité, l’IETF est pragmatique : si suffisamment de personnes manifestent leur intérêt pour un travail donné (ici, le développement de DoH), si le travail est effectivement réalisé, s’il n’y a pas d’objection (ce qui était le cas pour DoH, auquel personne ne s’est opposé), l’IESG (Internet Engineering Steering Group), qui approuve ou pas les projets des groupes de travail de l’IETF, tend vers l’acceptation du protocole… et verra bien après s’il est effectivement déployé ou pas.

La controverse démarre

  • ix Le protocole de partage de fichiers BitTorrent et la cryptomonnaie Bitcoin fournissent deux bons ex (...)

21L’IETF, on l’a vu, n’a qu’une autorité morale. Cette autorité demeure importante mais l’IETF n’a aucun moyen, ni de forcer un déploiement (plusieurs protocoles IETF sont restés lettre morte), ni d’empêcher le déploiement de choses qu’elle désapprouve (comme la surveillance de masse) ou tout simplement de techniques développées en dehors de l’IETFix.

22Parfois, le déploiement précède même la normalisation. Ça n’a pas été le cas ici, et c’est seulement après la publication du RFC que des programmes mettant en œuvre DoH apparaissent. Et c’est aussi là que la controverse a commencé. L’organisation Mozilla a inclus DoH dans son navigateur Firefox en septembre 2019 (Mozilla, 2019) et (le détail est très important), par défaut, le navigateur utilise le résolveur public de la société états-unienne Cloudflare. De nombreuses objections sont alors émises. Comme souvent avec les débats politico-techniques, ils sont très confus, par ignorance ou par mauvaise foi. Ainsi, il est souvent difficile de déterminer si le problème soulevé concerne réellement DoH, ou bien un choix particulier fait par Mozilla, comme l’utilisation par défaut du résolveur de Cloudflare. Toutes les ressources de la rhétorique sont déployées. Ainsi, l’association des FAI britanniques (un pays dont les services d’espionnage sont particulièrement compétents et actifs sur le trafic Internet) décrète en juillet 2019 que Mozilla fait partie des « méchants de l’Internet » (Cimpanu, 2019).

23La prise de position la plus amusante étant certainement celle d’une aristocrate britannique parlant devant la Chambre des Lords pour fustiger le désir des utilisateurs de se mettre à l’abri de la surveillance et mettant en cause un « obscure technical group » (l’IETF) : un cas extrême de « poutre faisant des reproches à la paille » (Thornton, 2019)

24Les objections émises ( notez bien cependant que toutes ne sont pas spécifiques à DoH et que certaines ne concernent même pas DoH) sont que DoH va :

  • rendre plus difficile l’application des politiques de censure, en facilitant et en sécurisant l’utilisation d’un résolveur tiers,

  • rendre plus difficile la surveillance du trafic DNS,

  • aggraver la centralisation, déjà trop forte, de l’Internet,

  • modifier l’architecture de l’Internet, en séparant résolveur et réseau d’accès,

  • rendre moins efficace la sélection d’un serveur proche, faite en fonction de l’adresse IP du résolveur,

  • contourner au niveau de l’application (le navigateur Web) le résolveur configuré au niveau du système d’exploitation.

  • x Comme toute technique de sécurité, la cryptographie n’est pas parfaite. Le protocole TLS, qui est d (...)

25On voit également des reproches contradictoires faites à DoH : certaines personnes (Livingood et al., 2019 ; Bertola, 2019 ; Fidler et al., 2019) estiment que DoH est négatif car il empêche la visibilité du trafic par les opérateurs du réseau, et les mêmes, pour décourager le déploiement de DoH, affirment qu’il ne protège pas réellement la vie privéex.

  • xi DoT est pourtant mis en œuvre dans plusieurs systèmes d’exploitation, comme Android.

26Il est intéressant de noter que DoT est très largement épargné par la controverse. Il fournit pourtant un service équivalent. Si on estime, par exemple, qu’il est important que l’opérateur du réseau puisse voir les requêtes et les réponses DNS, DoT limite cette visibilité autant que DoH. La relative tranquillité dont jouit DoTxi est sans doute en partie due à l’ignorance (DoH, utilisant les techniques du Web, semble plus familier) et en partie à sa vulnérabilité face au risque de blocage, ce qui invite les partisans de la visibilité à penser qu’ils pourront toujours le neutraliser.

Retour à l’IETF

27Alors que le développement de DoH à l’IETF, au contraire de celui de TLS 1.3, avait été calme et sans polémique particulière, les controverses autour du déploiement de DoH entraînent un retour de la question à l’IETF. Comme toute technique de cryptographie, DoH ne protège que contre les tiers qui observent le trafic, et pas contre les extrémités de la communication (ici, l’utilisateur final, et le résolveur). Ainsi, si vous faites du DoH avec Cloudflare, un service d’espionnage comme le GCHQ (Government Communications Headquarters) britannique ne pourra pas facilement comprendre ce que vous racontez, mais Cloudflare le saura, évidemment. Le chiffrement sépare donc entre « ce qui ont l’information » et « ceux qui ne l’ont pas » et les lignes de fracture de la controverse suivent souvent cette séparation.

28À partir de cette observation, plusieurs personnes ont demandé que l’IETF relance le travail pour un mécanisme permettant de diriger les utilisateurs de DoH vers un résolveur DoH géré par l’opérateur du réseau où on se connecte. Ainsi, cet opérateur pourrait observer tout le trafic, tout en affirmant qu’il fait du DoH, le chiffrement étant considéré comme généralement bon pour la vie privée. Cette idée est évidemment alignée avec les intérêts des FAI et avec celui des gérants des réseaux locaux, et plusieurs FAI importants, comme Comcast ou British Telecom, l’ont soutenu, et ont déployé des résolveurs DoH internes.

  • xii Plusieurs personnes avaient espéré que le passage en « tout distanciel » améliore la diversité des (...)

29Cette idée de relancer le travail pour « neutraliser » DoH a mené à plusieurs réunions en 2019, puis à la création officielle du groupe de travail ADD (Adaptive DNS Discovery) en février 2020. À l’heure où j’écris cet article, en novembre 2021, le groupe n’a encore publié aucun RFC, et c’est seulement en février 2021 qu’il a adopté comme base de travail trois documents. La pandémie de Covid-19 n’a évidemment pas aidéxii mais le groupe ADD a également été freiné par des sérieuses divergences, notamment entre ceux qui souhaitaient un mécanisme obligatoire pour les machines terminales et ceux qui auraient préféré une simple indication « il y a un résolveur DoH ici, vous pouvez l’utiliser si vous voulez ». Le document de « cahier des charges » a ainsi dû être très sévèrement réduit afin d’être adopté. L’avenir du travail du groupe ADD est donc incertain.

  • xiii On peut également observer un net déséquilibre dans le genre, qui ne se retrouve toutefois pas dans (...)

30La controverse suivant le déploiement de DoH a également mené à des débats au sein de l’IETF sur le mécanisme de décision. On a dit que la participation à l’IETF, nécessitant du temps et de la compétence technique, le simple « M. Toutlemonde » n’a guère de possibilité d’influencer le résultat. Autant l’IETF est ouverte (tout le monde peut observer le travail en cours et, à part le W3C, aucune organisation de normalisation n’est aussi transparente), mais une participation effective nécessite un sérieux investissement. L’IETF est nettement biaisé vers une population d’ingénieursxiii travaillant pour des entreprises importantes, ou pour des universités ayant des contrats avec ces entreprises. Bien sûr, l’appartenance de telle ou telle personne à tel groupe n’implique pas forcément une adhésion aveugle aux intérêts matériels de ce groupe. En effet, ce n’est pas parce quelqu’un défend les intérêts des FAI qu’il est toujours secrètement payé par les FAI. En théorie, à l’IETF, on n’est pas censé représenter son employeur, mais agir individuellement. Sans même prendre en compte la dépendance matérielle (qui paie le voyage vers les réunions ?), il est difficile de croire que le fait de travailler dans une organisation actrice de l’Internet n’a aucune influence sur la perception qu’on a de ce qui est souhaitable.

31Or, le travail effectué pour améliorer l’Internet doit profiter à tous. C’est la position prise par (Nottingham, 2020) qui affirme bien haut que, parmi les différentes parties prenantes de l’Internet, l’IETF doit toujours trancher en faveur des intérêts des utilisateurs finaux.

32A priori, c’est le cas : dans toutes les discussions autour de DoH, chacun se réclame fort des utilisateurs finaux et affirme défendre leurs intérêts. Personne n’intervient en disant « je défends mon employeur » et tout le monde se réclame au contraire de l’idéal collectif. Ce n’est pas forcément de la malhonnêteté intellectuelle : le problème est que les utilisateurs finaux ne forment pas un groupe homogène, et il n’existe de toute façon pas de mécanisme de représentation de ces utilisateurs et utilisatrices. Nottingham (2020) est d’ailleurs bien conscient de ce problème. Après avoir affirmé la position de principe, et après avoir discuté des raisons de privilégier ainsi les utilisateurs, ce RFC expose en détail les difficultés concrètes que pose l’application de cette position. Qu’est-ce qui est dans l’intérêt de l’utilisateur final ? Comment savoir ce qui est bon pour lui ou elle ?

33Une idée évidente est de le leur demander. Ce qui fait parfois rire certains participants à l’IETF, persuadés que l’utilisateur n’a pas de réelle intelligence et qu’il faudrait faire son bonheur malgré lui. Cela dit, ces rires ne se font qu’en sourdine , car ils ne sont pas considérés comme acceptables. Le principe comme quoi l’utilisateur peut décider est largement accepté, au moins en théorie. Après tout, c’est la base de la démocratie, et l’Internet étant une infrastructure commune, il est logique de le gérer de manière démocratique (Régnauld et al., 2020). Mais il n’existe pas actuellement de mécanisme pour cela. Si on trouve sans peine, dans toute réunion de « gouvernance Internet », des personnes se réclamant des « utilisateurs finaux », dans la réalité, M. Toutlemonde est absent de toutes ces instances.

  • xiv Sur les forums de joueurs en ligne, une population impatiente et qui dépend beaucoup de l’Internet, (...)

34Dans l’Internet, les utilisateurs ont normalement un autre pouvoir. Ils et elles peuvent faire des choix techniques. Par exemple, un certain nombre d’utilisateurs changent la configuration de leur ordinateur ou de leur réseau local pour utiliser un autre résolveur DNS que le résolveur indiqué par défaut, et qui est en général géré par le FAIxiv. Dans les débats au sujet de DoH, le thème « Mozilla a violé la liberté des utilisateurs en activant par défaut le résolveur de Cloudflare » revient souvent. L’argument est curieux car de nombreux autres choix sont faits par les auteurs de logiciel dont nous dépendons tant. On n’imagine pas, à l’installation d’un nouvel ordinateur, de demander à l’utilisateur de répondre à des centaines de questions sur la configuration qu’il préfère. Mais ce point met en évidence l’importance du choix par défaut. Comme la plupart des utilisateurs ne le modifieront pas, soit par ignorance de cette possibilité, soit par crainte que cela ne casse quelque chose, le choix des auteurs du logiciel est crucial.

Conclusion

  • xv (Fairhurst et al., 2021) est peut-être un premier pas vers cette critique.

35Lors de rédaction de cet article, un autre groupe de travail de l’IETF a terminé la première partie de son travail et a vu son approbation par l’IESG puis sa publication en RFC. Ce groupe, nommé QUIC, a normalisé un nouveau protocole de transport, qui pourra remplacer en grande partie le traditionnel TCP. Une des différences : le protocole QUIC chiffre beaucoup plus de choses que TCP, même quand celui-ci ajoute TLS (Transport Layer Security) et QUIC diminue donc la « visibilité » pour les opérateurs réseau. Si QUIC a déjà vécu des controverses actives, il n’a pas encore rencontré d’objections fondamentales, mais on peut supposer que son déploiement effectif entraînera des remous analogues à ceux créés par DoHxv.

  • xvi Anecdote : une grande partie du débat au sein du groupe de travail QUIC a tourné sur un seul bit, l (...)

36Le problème de fond, celui des mécanismes de décision, demeurera. Comment faire participer tous les utilisateurs et toutes les utilisatrices de l’Internet (c’est-à-dire tout le monde) à des décisions qui sont à la fois très techniquesxvi et d’une importance pratique cruciale pour ces utilisateurs et utilisatrices ? (Nottingham, 2020) cite comme principale piste une médiation par des organisations qui ont la compétence technique et l’intérêt pour les problèmes politiques, comme l’ACLU (American Civil Liberties Union) ou la Quadrature du Net, tout en notant leur manque de représentativité.

Haut de page

Bibliographie

Badiei, F., Fidler, B. (2021), « The Would-Be Technocracy : Evaluating Efforts to Direct and Control Social Change with Internet Protocol Design », Journal of Information Policy, vol. 11 (2021), pp. 376-402 https://www.jstor.org/stable/10.5325/jinfopoli.11.2021.0376

Bertola, V. (2019) document de travail IETF, « Recommendations for DNS Privacy Client Applications ». https://datatracker.ietf.org/doc/draft-bertola-bcp-doh-clients

Braman, S. (2010) « Internet RFCs as social policy : Network design from a regulatory perspective », Proceedings of the American Society for Information Science and Technology, Volume46, Issue1 2009 Pages 1-29 https://asistdl.onlinelibrary.wiley.com/doi/full/10.1002/meet.2009.1450460254

Bortzmeyer, S. (2015) RFC 7626 « DNS privacy considerations ». https://www.rfc-editor.org/info/rfc7626

Bortzmeyer, S. (2016) RFC 7816 « DNS query name minimisation to improve privacy ». https://www.rfc-editor.org/info/rfc7816

Cath, C. (2021), « Changing Minds and Machines : A Case Study of Human Rights Advocacy in the Internet Engineering Task Force (IETF) », Thèse Oxford University, https://corinnecath.com/wp-content/uploads/2021/09/CathCorinne-Thesis-DphilInformationCommunicationSocialSciences.pdf

Cimpanu, C. (2019) « UK ISP group names Mozilla 'Internet Villain' for supporting 'DNS-over-HTTPS' » Article dans ZDNet https://www.zdnet.com/article/uk-isp-group-names-mozilla-internet-villain-for-supporting-dns-over-https/

Easterling, K. (2016) « Extrastatecraft : The Power of Infrastructure Space », ISBN 9781784783648

Fairhurst, G. et Perkins, C. (2021) RFC 9065 « Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols ». https://www.rfc-editor.org/info/rfc9065

Farrell, S. et Tschofenig, H. (2014) RFC 7258 « Pervasive Monitoring Is an Attack ». https://www.rfc-editor.org/info/rfc7258

Fidler, A. Hubert, B., Livingood, J., Reid, J. et Leymann, N. (2019), document de travail IETF « DNS over HTTPS (DoH) Considerations for Operator Networks ». https://datatracker.ietf.org/docdraft-reid-doh-operator

Hoffman, P. et McManus, P. (2018) RFC 8484 « DNS Queries over HTTPS (DoH) ». https://www.rfc-editor.org/info/rfc8484

Housley, R. et Droms, R. (2018), document de travail IETF « TLS 1.3 Option for Negotiation of Visibility in the Datacenter ». https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/

Hu, Z. Zhu, L., Heidemann, J., Mankin, A., Wessels, D. et Hoffman, P. (2016), RFC 7858 « Specification for DNS over Transport Layer Security (TLS) ». https://www.rfc-editor.org/info/rfc7858

IAB et IESG (1996), RFC 1984 « Statement on Cryptographic Technology and the Internet ». https://www.rfc-editor.org/info/rfc1984

Lapowsky I. (2021), « Concern trolls and power grabs : Inside Big Tech’s angry, geeky, often petty war for your privacy », article de Protocol. https://www.protocol.com/policy/w3c-privacy-war

Levinson, M. (2008) , « The box », Princeton University Press, ISBN 978-0691136400

Livingood, J., Antonakakis M., Sleigh B. et Winfield, A. (2019), document de travail IETF « Centralized DNS over HTTPS (DoH) Implementation Issues and Risks ». https://datatracker.ietf.org/doc/draft-livingood-doh-implementation-risks-issues

Mathew, A. J. (2014) « Where in the World is the Internet ? Locating Political Power in Internet Infrastructure », Thèse University of California, Berkeley https://www.ischool.berkeley.edu/research/publications/2014/where-world-internet-locating-political-power-internet-infrastructure

Moriarty, K. et Morton, A. (2018) RFC 8404 « Effects of Pervasive Encryption on Operators ». https://www.rfc-editor.org/info/rfc8404

Morris, J. et Davidson, A. (2003) « Policy Impact Assessments : Considering the Public Interest in Internet Standards Development », TPRC 2003. https://papers.ssrn.com/sol3/papers.cfm ?abstract_id =2060656

Fondation Mozilla (2019), « What’s next in making Encrypted DNS-over-HTTPS the Default ». https://blog.mozilla.org/futurereleases/2019/09/06/whats-next-in-making-dns-over-https-the-default/

Nottingham, M. (2020) RFC 8890 « The Internet is for End Users ». https://www.rfc-editor.org/info/rfc8890

Régnauld, I. et Benayoun, Y. (2020), « Technologies partout, démocratie nulle part », ISBN 978-2-36405-202-4 https://boutique.fypeditions.com/products/echnologies-partout-democratie-nulle-part-plaidoyer-pour-que-les-choix-technologiques-deviennent-l-affaire-de-tous

Schneier, B. (2019), « Cybersecurity for the Public Interest », https://www.schneier.com/essays/archives/2019/02/public-interest_tech.html

Sire, G. (2017), « Gouverner le HTML », Réseaux 2017/6 (n° 206), pages 37 à 60 https://www.cairn.info/revue-reseaux-2017-6-page-37.htm

Ten Oever, N. (2020) « Wired Norms : Inscription, resistance, and subversion in the governance of the Internet infrastructure », thèse Universiteit van Amsterdam https://nielstenoever.net/wp-content/uploads/2020/09/WiredNorms-NielstenOever.pdf

Thornton (2019), débat à la Chambre des Lords britannique, dans Hansard Volume 797, 14 mai 2019 https://hansard.parliament.uk/Lords/2019-05-14/debates/E84CBBAE-E005-46E0-B7E5-845882DB1ED8/InternetEncryption

Haut de page

Note de fin

i Les protocoles qui ne sont pas client/serveur sont souvent appelés « pair-à-pair », mais ce terme regroupe beaucoup de protocoles très différents.

ii Le terme technique pour ces adresses Web est URL (Uniform Resource Locator).

iii Ce nom comporte un caractère composé (le e avec accent). De tels noms, permettant d’utiliser tous les caractères et pas seulement ceux utilisés pour la langue anglaise, se nomment IDN (Internationalized Domain Names), et leur introduction avait suscité une autre virulente controverse politico-technique.

iv Une adresse Web qui commence par « https » (le s signifiant « secure ») indique que la communication est chiffrée.

v Bien des solutions de chiffrement actuellement existantes nécessitent une action explicite de l’utilisateur pour être activées. Cette action n’est pas forcément compliquée à faire, mais l’utilisateur peut ne pas être conscient de sa nécessité. Faire dépendre la protection de la vie privée d’une telle action par l’utilisateur risque donc de limiter la vie privée aux plus technophiles et aux plus informés.

vi Formé à partir des noms de Google, Apple, Facebook et Amazon, ce terme désigne toutes les entreprises étatsuniennes qui ont aujourd’hui une position dominante dans les services accessibles via le Web.

vii Payment Card Industry Data Security Standard, une norme de processus dans le secteur financier, imposant notamment une forte traçabilité des décisions et des opérations.

viii Ces « couches » font référence à un modèle souvent utilisé pour décrire les différentes fonctions qui vont faire que le réseau fonctionne. On parle de « couches basses » (par exemple les couches 1 et 2) pour les fonctions les plus proches du matériel, et de « couches hautes » (comme la 7) pour celles les plus proches des utilisateurs. L’IETF est donc en charge des « couches intermédiaires ».

ix Le protocole de partage de fichiers BitTorrent et la cryptomonnaie Bitcoin fournissent deux bons exemples.

x Comme toute technique de sécurité, la cryptographie n’est pas parfaite. Le protocole TLS, qui est derrière DoH et DoT, ne dissimule pas, par défaut, la taille des messages. Dans certains cas, cela permet de reconstituer une partie du trafic chiffré.

xi DoT est pourtant mis en œuvre dans plusieurs systèmes d’exploitation, comme Android.

xii Plusieurs personnes avaient espéré que le passage en « tout distanciel » améliore la diversité des participants, en faisant sauter l’obstacle du coût des voyages (sans compter les récurrents problèmes de visas) et finalement la productivité de l’IETF. Le bilan tiré par l’IETF en mars 2021 montre au contraire une chute de la participation, puisque, en fait, l’essentiel du travail était fait de manière informelle, dans les couloirs ou les bars.

xiii On peut également observer un net déséquilibre dans le genre, qui ne se retrouve toutefois pas dans les instances de direction, où une politique volontariste aboutit à un pourcentage de femmes plus élevé que parmi les participants.

xiv Sur les forums de joueurs en ligne, une population impatiente et qui dépend beaucoup de l’Internet, le conseil « mets 8.8.8.8 comme DNS et tout marchera » est souvent systématiquement donné dès qu’un problème réseau est signalé. Parfois, cela résout le problème. Une autre motivation courante est de pouvoir contourner la censure qui, en Europe, est généralement mise en œuvre dans les résolveurs des FAI.

xv (Fairhurst et al., 2021) est peut-être un premier pas vers cette critique.

xvi Anecdote : une grande partie du débat au sein du groupe de travail QUIC a tourné sur un seul bit, le spin bit, qui doit redonner aux équipements réseau un peu (un seul bit…) de la visibilité perdue.

Haut de page

Pour citer cet article

Référence électronique

Stéphane Bortzmeyer, « La prise de décision dans la normalisation technique Internet : l’exemple de DoH »Terminal [En ligne], 132-133 | 2022, mis en ligne le 14 février 2022, consulté le 21 juin 2024. URL : http://journals.openedition.org/terminal/8221 ; DOI : https://doi.org/10.4000/terminal.8221

Haut de page

Droits d’auteur

Le texte et les autres éléments (illustrations, fichiers annexes importés), sont « Tous droits réservés », sauf mention contraire.

Haut de page
Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search