Mon blog

Protéger la vie privée sur l'Internet nécessite au moins deux techniques : chiffrer les données en transit pour éviter leur lecture par des tiers et minimiser les données qu'on envoie, pour éviter les abus par les récepteurs des données. Ce deuxième point, pourtant bien mis en avant dans la loi Informatique & Libertés ou dans le RGPD est souvent oublié. Ce RFC applique ce principe au DNS : il ne faut pas envoyer aux serveurs faisant autorité le nom de domaine complet mais seulement la partie du nom de domaine qui lui est strictement nécessaire pour répondre, le minimum. Cette norme succède au RFC 7816, qui était purement expérimental alors que cette minimisation de la requête (QNAME minimisation) est désormais une norme. Le principal changement est la recommandation d'utiliser le type de données A (adresse IPv4) et plus NS (serveurs de noms).

Ce principe de minimisation, qui devrait être central dans toute approche de la protection de la vie privée est également exposé dans le RFC 6973, section 6.1. Le DNS violait ce principe puisque, traditionnellement, un résolveur DNS qui recevait une demande d'information sur www.foobar.example transmettait aux serveurs faisant autorité la question complète, alors que, par exemple, les serveurs faisant autorité pour la racine ne connaissent que les TLD et que leur demander simplement des informations sur le TLD .example aurait suffi. (Voir le RFC 7626 pour une analyse complète des relations entre le DNS et la vie privée.) Cette tradition (qui ne s'appuyait sur aucune norme technique) est remise en cause par la QNAME minimisation qui demande au contraire qu'on n'envoie aux serveurs faisant autorité que le nom minimal (example à la racine, foobar.example aux serveurs du TLD .example, etc).

Cette minimisation est unilatérale, elle ne nécessite qu'un changement des résolveurs, sans toucher aux serveurs faisant autorité puisqu'elle ne change pas le protocole DNS. Depuis la sortie du RFC 7816, en 2016, elle a été largement déployée (si le résolveur que vous utilisez ne le fait pas, réclamez-le à votre service informatique !).

Le précédent RFC sur cette technique, le RFC 7816 avait le statut d'expérimentation alors que notre RFC 9156 est désormais une norme. En effet, une expérience considérable a été accumulée depuis le RFC 7816, qui a été mis en œuvre dans pratiquement tous les résolveurs, et souvent activé. Le FUD souvent entendu comme quoi la QNAME minimisation allait tuer Internet et des chatons a été largement réfuté. Les leçons tirées sont documentées dans « DNSThought QNAME minimisation results. Using Atlas probes », « Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution », « Measuring Query Name Minimization » et « A First Look at QNAME Minimization in the Domain Name System ».

Maintenant, la pratique, comment fait-on de la QNAME minimisation ? La question envoyée par le résolveur au serveur faisant autorité comprend un QNAME (Query Name, le nom demandé) et un QTYPE (Query Type, le type de données, par exemple serveur de courrier, adresse IP, texte libre, etc). Avec la QNAME minimisation, le nom doit être le nom le plus court possible. Quand le résolveur interroge un serveur racine, il n'envoie comme QNAME que le TLD, par exemple. Trouver « le plus court possible » n'est pas forcément trivial en raison des coupures de zone. Dans un nom comme miaou.foo.bar.example, foo.bar.example et bar.example font peut-être partie de la même zone (et ont donc les mêmes serveurs faisant autorité) et peut-être pas. Rien dans la syntaxe du nom ne l'indique. Contrairement à une idée fausse et répandue, il n'y a pas forcément une coupure de zone pour chaque point dans le nom. Trouver les coupures de zone est expliqué dans le RFC 2181, section 6. Un résolveur qui valide avec DNSSEC doit savoir trouver ces coupures, pour savoir à qui demander les enregistrements de type DS. Les autres (mais quelle idée, en 2021, d'avoir un résolveur qui ne valide pas) doivent s'y mettre. Si, par exemple, foo.bar.example et bar.example sont dans la même zone, le résolveur qui veut trouver des données associées à miaou.foo.bar.example va envoyer le QNAME example à la racine, puis bar.example au serveur du TLD, puis miaou.foo.bar.example au serveur de bar.example. (Avant la QNAME minimisation, il aurait envoyé le QNAME miaou.foo.bar.example à tout le monde.)

Cela, c'était pour le QNAME. Et le QTYPE ? On peut choisir celui qu'on veut (à l'exception de ceux qui ne sont pas dans la zone, comme le DS), puisque les délégations de zones ne dépendent pas du type. Mais, et c'est un sérieux changement depuis le RFC 7816, notre RFC recommande le type A (ou AAAA), celui des adresses IP, et plus le type NS (les serveurs de noms), que recommandait le RFC 7816. Deux raisons à ce changement :

• Certaines middleboxes boguées jettent les questions DNS portant sur des types qu'elles ne connaissent pas. Le type A passe à coup sûr.
• Le but de la QNAME minimisation étant la protection de la vie privée, il vaut mieux ne pas se distinguer et, notamment, ne pas dire franchement qu'on fait de la QNAME minimisation (les requêtes explicites pour le type NS étaient rares). Un serveur faisant autorité, ou un surveillant qui espionne le trafic, ne peut donc pas déterminer facilement si un client fait de la QNAME minimisation.

Vous voyez ici le schéma de la résolution DNS sans la QNAME minimisation puis avec :

Dans certains cas, la QNAME minimisation peut augmenter le nombre de requêtes DNS envoyées par le résolveur. Si un nom comporte dix composants (ce qui arrive dans des domaines ip6.arpa), il faudra dans certains cas dix requêtes au lieu de deux ou trois. Les RFC 8020 et RFC 8198 peuvent aider à diminuer ce nombre, en permettant la synthèse de réponses par le résolveur. Une autre solution est de ne pas ajouter un composant après l'autre en cherchant le serveur faisant autorité mais d'en mettre plusieurs d'un coup, surtout après les quatre premiers composants.

Un algorithme complet pour gérer la QNAME minimisation figure dans la section 3 du RFC.

Notez que, si vous voulez voir si votre résolveur fait de la QNAME minimisation, vous pouvez utiliser tcpdump pour voir les questions qu'il pose mais il y a une solution plus simple, la page Web de l'OARC (dans les DNS features).

Un test avec les sondes RIPE Atlas semble indiquer que la QNAME minimisation est aujourd'hui largement répandue (les deux tiers des résolveurs utilisés par ces sondes) :

% blaeu-resolve --requested 1000 --type TXT   qnamemintest.internet.nl 
["hooray - qname minimisation is enabled on your resolver :)!"] : 651 occurrences 
["no - qname minimisation is not enabled on your resolver :("] : 343 occurrences 
Test #33178767 done at 2021-11-05T14:41:02Z
  

Comme son prédécesseur, ce RFC utilise (prétend Verisign) un brevet. Comme la plupart des brevets logiciels, il n'est pas fondé sur une réelle invention (la QNAME minimisation était connue bien avant le brevet).

Ah, et vous noterez que le développement de ce RFC, par trois auteurs, a été fait sur FramaGit.

L'IETF distribuait un certain nombre de documents en FTP anonyme. Ce service, ftp.ietf.org, va être interrompu. Mais un certain nombre de RFC continuent à le citer comme source. Comme on ne peut pas modifier un RFC après publication, notre RFC 9141 fait la liste des mises à jour à lire pour corriger ces RFC et indiquer la nouvelle source des documents.

FTP, qui avait été le premier protocole de transfert de fichiers de l'Internet, avant même l'adoption de TCP/IP, a été pendant longtemps le principal moyen de copier des fichiers à travers le réseau. Une de ces fonctions, le FTP anonyme (qui n'était en fait pas anonyme du tout) permettait d'accéder aux fichiers, lorsque le serveur le voulait bien, sans avoir de compte sur le serveur. D'immenses archives de logiciels, de documents, d'images, ont été ainsi distribuées pendant des années. Aujourd'hui, FTP n'est guère plus utilisé (entre autres parce qu'il fonctionne en clair, cf. la section 4 sur la sécurité) et maintenir un service FTP anonyme n'a plus guère de sens. D'où la décision de l'IETF en 2020 de fermer le sien (cf. l'annonce). Le plan élaboré à cette occasion (une lecture recommandée sur les détails de cette décision, par exemple les statistiques d'utilisation) notait qu'il y avait trente RFC qui référençaient ce service, le dernier, le RFC 7241, datant de 2014. Tous ces RFC sont donc formellement mis à jour par notre RFC 9141. (Comme le note GuB, « C'est pire que légifrance cette histoire ».)

Par exemple, le RFC 2077 dit « Copies of RFCs are available on: ftp://ftp.isi.edu/in-notes/ » alors qu'il faudra désormais lire « Copies of RFCs are available on: https://www.rfc-editor.org/rfc/ ».

Voici par exemple, pour la nostalgie, le fonctionnement du serveur en novembre 2021, avant sa fermeture. On cherche les archives indiquées par le RFC 5098, et qui sont désormais en https://www.ietf.org/ietf-ftp/ietf-mail-archive/ipcdn/ :

% ncftp ftp.ietf.org    
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).

Copyright (c) 1992-2011 by Mike Gleason.
All rights reserved.

Connecting to 4.31.198.44...                                                                                                            
FTP server ready
Logging in...                                                                                                                           
Anonymous access granted, restrictions apply
Logged in to ftp.ietf.org.                                                                                                              
ncftp / > ls
charter/                         ietf/                            internet-drafts/                 slides/
concluded-wg-ietf-mail-archive/  ietf-mail-archive/               review/                          status-changes/
conflict-reviews/                ietf-online-proceedings/         rfc/                             yang/
ncftp / > 
ncftp / > cd ietf-mail-archive/ipcdn
ncftp /ietf-mail-archive/ipcdn > ls
...
1996-12               1999-07.mail          2001-09.mail          2003-11.mail          2006-01.mail          2008-03.mail
1997-01               1999-08.mail          2001-10.mail          2003-12.mail          2006-02.mail          2008-04.mail
1997-02               1999-09.mail          2001-11.mail          2004-01.mail          2006-03.mail          2008-05.mail
1997-03               1999-10.mail          2001-12.mail          2004-02.mail          2006-04.mail          2008-06.mail
...
  

Ce livre est consacré à l'étude des fans, notamment de série télé. Souvent présentés comme un peu bizarres, monomaniaques, fanatiques (cf. l'étymologie de « fan »), sans « vraie vie » et vivant dans l'imaginaire, les fans sont au contraire des sujets d'études dignes d'intérêt.

J'ai découvert dans ce livre qu'il existait même une catégorie de SHS sur la question, les fan studies. Les fans ne sont pas une nouveauté de l'Internet, l'auteure cite les regroupements de fans de Sherlock Holmes dès le 19e siècle. La thèse de l'auteure est que les fans ne sont pas des abrutis qui suivent passivement une série mais qu'ils interagissent, qu'ils critiquent, qu'ils utilisent la série dans tel ou tel but, par exemple politique (le sous-titre du livre est « publics actifs et engagés »). Le livre parle du militantisme autour des séries (des féministes utilisant Wonder Woman ou Leia comme référence), de création à partir de séries (fanfiction), etc.

J'ai eu du mal avec les références, toutes étatsuniennes. Par exemple, la dernière étude de cas couvre une série dont j'ignorais même l'existence, Wynonna Earp, qui a apparemment un club de fans particulièrement motivé·es et organisé·es. Il est parfois difficile de suivre le livre si on ne connait pas ces séries.

Les fans sont, par définition, passionnés par leur sujet et cela peut mener à des comportements négatifs, par exemple contre les fans d'autres séries, ou contre les fans de la même série, mais qui préfèrent tel personnage plutôt que tel autre. L'auteur parle assez peu de ces aspects néfastes, qu'on peut facilement observer sur Twitter dans l'univers de la téléréalité, avec les insultes et menaces des fans de tel ou tel personnage.

Les fans peuvent aussi s'estimer en droit d'influencer la série et ses futurs épisodes, menant des campagnes, par exemple pour qu'on donne une place plus importante à tel personnage particulièrement apprécié (parfois pour des raisons politiques). Je trouve personnellement que le livre est un peu court sur l'analyse critique de ce phénomène, par exemple lorsqu'il cite des acteurs et actrices de séries qui tiennent publiquement des discours en accord avec celui de leur personnage dans la série : sincérité ou marketing ? Ce n'est pas étudié.

Les fans, on l'a dit, ne sont pas des spectateurs passifs. Une des parties les plus intéressantes du livre est consacré au travail que font certains fans autour de leur série favorite, par exemple en construisant des formidables encyclopédies en ligne comme le Wiki of Ice and Fire (non cité dans le livre, je crois) ou le Battlestar Galactica Museum. Un tel travail, avec ce qu'il implique, non seulement de temps passé, mais également de coordination dans le groupe, et de mentorat des nouveaux, est bien loin de l'image du fan asocial claquemuré dans sa chambre et s'adonnant au binge-watching. Bref si, comme moi, vous ne connaissez pas tellement ce monde des fans, vous apprendrez plein de choses dans ce livre.

Autre article, plus détaillé, sur ce livre, celui de Christine Hébert.

Ce RFC revisite la notion de capacité du RFC 5136 et spécifie une nouvelle métrique, Type-P-One-way-Max-IP-Capacity.

Il y a déjà plusieurs RFC qui spécifient rigoureusement des métriques pour déterminer la capacité réseau. (Attention, les publicités des FAI et les articles dans les médias parlent souvent à tort de débit pour désigner ce qui est en fait la capacité, c'est-à-dire le débit maximum.) Une définition rigoureuse est en effet nécessaire car il peut y avoir, pour une même connexion et un même chemin, des capacités différentes selon ce qu'on mesure. Par exemple, est-ce qu'on compte les bits/s à la couche 3 ou à la couche 7 ? Compte-tenu de l'encapsulation et des retransmissions, la seconde est forcément plus basse. Les définitions actuelles sont surtout dans le RFC 5136 et le RFC 3148 mais le travail n'est jamais terminé et ce nouveau RFC vient donc compléter le RFC 5136. Vu l'importance de cette notion de capacité dans les publicités (« Nouveau : accès Premium Gold Plus à 10 Gb/s ! »), il est crucial que des associations de consommateurs ou des régulateurs puissent mesurer et vérifier les annonces.

Une des raisons pour lesquelles le travail sur la définition des métriques ne cesse jamais est que l'Internet évolue. Ainsi, note le RFC, depuis quelques années :

• Ce n'est plus forcément le premier kilomètre qui limite la capacité du chemin,
• le protocole UDP prend plus d'importance, grâce à WebRTC et QUIC,
• avec les CDN, le contenu se rapproche des utilisateurs (et franchit moins souvent des frontières entre AS).

Première métrique défnie dans notre RFC (section 5), et venant s'ajouter à celles du RFC 5136, Type-P-One-way-IP-Capacity. C'est le nombre de bits par seconde, mesurés en couche 3 et au-dessus (donc incluant l'en-tête IP, par exemple). Le Type-P est là pour rappeler que cette métrique n'a de sens que pour un certain type de trafic, car des équipements réseau « intelligents » peuvent faire que, par exemple, les paquets vers le port 22 passent plus vite que ceux pour un autre port. Type-P est donc la description complète des paquets utilisés. À noter que le RFC recommande d'indiquer la valeur de cette métrique en mégabits par seconde (et pas en mébibits, on utilise plutôt les préfixes des télécoms que ceux de l'informatique).

Deuxième métrique (section 6), Type-P-One-way-Max-IP-Capacity, qui indique la capacité maximum (la différence avec la métrique précédente vient du fait que certains réseaux peuvent avoir une capacité variable, par exemple les réseaux radio, oui, je sais, c'est compliqué).

Troisième métrique (section 7), Type-P-IP-Sender-Bit-Rate. Elle désigne la capacité de l'émetteur à envoyer des bits. En effet, lors d'une mesure, le goulet d'étranglement peut être l'expéditeur et on croit alors que le réseau a une capacité inférieure à ce qu'elle est réellement.

La section 8 se penche sur la mesure effective de ces valeurs. Il faut une mesure active (envoi de bits sur le réseau uniquement pour faire la mesure), et elle possiblement très perturbatrice puisqu'on va chercher à remplir les tuyaux le plus possible. Le RFC inclut un algorithme d'ajustement du trafic mais qui n'est pas un vrai algorithme de contrôle de congestion. Le pseudo-code de cet algorithme est dans l'annexe A.

La mesure est bidirectionnelle (envoyeur et récepteur doivent coopérer) même si la métrique est unidirectionnelle (le One-Way dans le nom). Le RFC recommande de la faire sur UDP (attention au RFC 8085, UDP n'ayant pas de contrôle de congestion propre, c'est à l'application de mesure de faire attention à ne pas écrouler le réseau).

Jouons maintenant un peu avec une mise en œuvre de ce RFC, le programme udpst, sur deux machines Arch Linux (un Raspberry Pi 1, donc avec un réseau très lent) et Debian, sur le même commutateur. On l'installe :

% git clone https://github.com/BroadbandForum/obudpst.git
% cd obudpst
% cmake .
% make

On peut alors lancer le serveur :

% ./udpst
UDP Speed Test
Software Ver: 7.2.1, Protocol Ver: 8, Built: Sep 28 2021 15:46:40
Mode: Server, Jumbo Datagrams: Enabled, Authentication: Available, sendmmsg syscall: Available
  

Et le client, le Raspberry Pi :

    
% ./udpst -u  2001:db8:fafa:35::1
UDP Speed Test
Software Ver: 7.2.1, Protocol Ver: 8, Built: Sep 28 2021 18:25:23
Mode: Client, Jumbo Datagrams: Enabled, Authentication: Available, sendmmsg syscall: Available
Upstream Test Interval(sec): 10, DelayVar Thresholds(ms): 30-90 [RTT], Trial Interval(ms): 50, Ignore OoO/Dup: Disabled,
    SendingRate Index: <Auto>, Congestion Threshold: 3, High-Speed Delta: 10, SeqError Threshold: 10, IPv6 TClass: 0
...
Sub-Interval[10](sec): 10, Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 2/8/18, RTTVar(ms): 2-16, Mbps(L3/IP): 65.73
Upstream Summary Delivered(%): 100.00, Loss/OoO/Dup: 0/0/0, OWDVar(ms): 0/3/23, RTTVar(ms): 0-16, Mbps(L3/IP): 49.87
Upstream Minimum One-Way Delay(ms): 2 [w/clock difference], Round-Trip Time(ms): 1
Upstream Maximum Mbps(L3/IP): 67.29, Mbps(L2/Eth): 67.45, Mbps(L1/Eth): 67.63, Mbps(L1/Eth+VLAN): 67.67

  

En sens inverse, avec l'option -d, où le Raspberry Pi va envoyer des données :

Downstream Summary Delivered(%):  84.90, Loss/OoO/Dup: 8576/0/0, OWDVar(ms): 0/641/956, RTTVar(ms): 0-39, Mbps(L3/IP): 38.86
Downstream Minimum One-Way Delay(ms): -927 [w/clock difference], Round-Trip Time(ms): 1
Downstream Maximum Mbps(L3/IP): 46.98, Mbps(L2/Eth): 47.68, Mbps(L1/Eth): 48.46, Mbps(L1/Eth+VLAN): 48.62

(Notez le taux de pertes élevé, la pauvre machine n'arrive pas à suivre.)

Vous l'avez remarqué, la France a été confinée en mars 2020 et cela a entre autres concerné l'École, qui était fermée ou, plus exactement, sortie de l'école (avec un petit é) pour se faire à distance depuis la maison. D'un tel bouleversement, décidé dans l'urgence, il y a forcément des leçons à tirer. C'est le but de ce petit livre collectif qui réunit un certain nombre d'analyses sur cette « période spéciale ».

À ma connaissance, le ministère n'a pas produit de texte officiel de bilan de cette « expérience ». (Sauf si on considère que le livre du ministre en tient lieu.) Pourtant, il y en a des choses à dire, un grand nombre de gens, des enseignants, élèves, parents, employés non enseignants de l'École ont dû s'adapter dans l'urgence, et ont souvent brillamment innové. Le livre alterne des témoignages du terrain, et des analyses plus générales. Goundo Diawara raconte ce qu'une CPE dans un établissement difficile (REP+) pouvait faire pour maintenir le moral des élèves et de leurs familles (comme pour beaucoup de choses, confinement et travail à la maison sont plus agréables quand on est riche que quand on est pauvre). Stéphanie de Vanssay rappelle que se focaliser sur le numérique, vu parfois comme danger, et parfois comme solution à tout pendant le confinement, est insuffisant. Ainsi, les inégalités ne relèvent pas uniquement de la « fracture numérique ». Serge Pouts-Lajus décrit ce que faisait le personnel non-enseignant, par exemple en préparant des repas et en les apportant aux élèves. Hélène Mulot parle du travail qu'elle a fait avec les élèves autour des masques. Et Pierre-Yves Gosset fait le bilan des relations de l'École avec le numérique, et notamment de sa capitulation, bien antérieure au confinement, devant Microsoft et autres entreprises. (Mais le confinement a aggravé les choses ; « nous avons tous émigré aux États-Unis » en matière d'outils numériques.)

J'espère que ce livre servira à ce que cette « expérience » ne soit pas oubliée et que les leçons du confinement serviront à quelque chose, et permettront de faire évoluer l'École (oui, je suis optimiste). Vous connaissez d'autres livres (à part celui du ministre) qui ont fait le bilan de ce confinement dans le milieu scolaire ?

Sur ce livre, il y a aussi une présentation d'une heure en vidéo et un article de Bruno Devauchelle dans le Café Pédagogique.

Le TLD .arpa sert pour différentes fonctions techniques et est géré directement par l'IAB. Ce RFC décrit un futur changement dans ses serveurs de noms.

Ce TLD est décrit dans le RFC 3172. Le nom de .arpa fait référence à l'ancien nom de la DARPA, l'agence qui avait financé le développement de l'Internet. Mais, aujourd'hui, il veut dire « Address and Routing Parameter Area » et le TLD sert à diverses fonctions techniques comme la résolution d'adresses IP en noms de domaine via des sous-domaines comme ip6.arpa. Par exemple, l'adresse IP du serveur Web de l'IAB a pour nom correspondant :

% dig -x 2001:1900:3001:11::2c
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53150
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
c.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.0.0.1.0.0.3.0.0.9.1.1.0.0.2.ip6.arpa. 3600 IN PTR mail.ietf.org.

Comme vous le voyez, dig a inversé l'adresse IP et ajouté ip6.arpa à la fin. .arpa sert également à d'autres fonctions comme le home.arpa du RFC 8375.

Traditionnellement, le domaine .arpa était hébergé sur une partie des serveurs de noms de la racine. Le 22 octobre 2021, voici quels étaient les serveurs faisant autorité pour .arpa :

% dig +nodnssec NS arpa 
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43670
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
arpa.			15910 IN NS b.root-servers.net.
arpa.			15910 IN NS f.root-servers.net.
arpa.			15910 IN NS d.root-servers.net.
arpa.			15910 IN NS l.root-servers.net.
arpa.			15910 IN NS e.root-servers.net.
arpa.			15910 IN NS a.root-servers.net.
arpa.			15910 IN NS c.root-servers.net.
arpa.			15910 IN NS i.root-servers.net.
arpa.			15910 IN NS h.root-servers.net.
arpa.			15910 IN NS g.root-servers.net.
arpa.			15910 IN NS k.root-servers.net.
arpa.			15910 IN NS m.root-servers.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Oct 22 20:35:36 CEST 2021
;; MSG SIZE  rcvd: 241

  

Le changement ne concerne que l'hébergement DNS, pas la gestion de .arpa (section 2 de notre RFC), qui reste un TLD critique, et soumis au RFC 3172. Le choix des sous-domaines et de leur administration est inchangé (par exemple, pour ip6.arpa, c'est décrit dans le RFC 5855).

La section 3 du RFC décrit le nouveau système qui, à la date de publication du RFC, n'est pas encore déployé. Le principe est de commencer par utiliser des noms différents pour les serveurs, mais qui pointeront vers les mêmes machines, au moins au début. Les nouveaux noms seront dans le futur sous-domaine ns.arpa, on aura donc a.ns.arpa, b.ns.arpa, etc. Aucune modification dans les serveurs ne sera nécessaire pour cette première étape, qui n'affectera que la zone racine et la zone .arpa. Comme tous les noms seront dans la zone qu'ils servent, il faudra ajouter de la colle aux réponses DNS (ne pas juste dire « le serveur est c.ns.arpa » mais également indiquer son adresse IP). Une fois que tout cela sera réalisé, il n'y aura plus de nom de serveur commun à la racine et à .arpa, et il sera possible dans le futur de migrer vers d'autres serveurs. (Toujours en respectant le RFC 3172.)

Vous pouvez voir l'état actuel de .arpa à l'IANA ou bien dans le DNS.

Notez enfin que certains des serveurs de .arpa autorisent le transfert de zones. Voici une copie faite le 24 octobre 2021.

Aujourd'hui le routage IPv4 chez OVH a été en panne pendant environ une heure. J'indique ici quelques observations effectuées puis j'en profite pour donner un avis sur la fiabilité de l'Internet, sur OVH et sur les yakafokons qui nous expliquent comment il aurait fallu faire. (Si vous n'êtes pas informaticien·ne, allez directement à la fin, la partie qui commence par « Maintenant, les leçons à en tirer. ».)

Pour son travail de normalisation technique, l'IETF tient normalement trois réunions physiques par an. La pandémie de Covid-19 a évidemment changé tout cela. Les premières décisions d'annulation ont été prises selon un procédure ad hoc, mais ce nouveau RFC fournit des critères plus rigoureux pour les prochaines décisions d'annulation.

La dernière réunion physique de l'IETF a eu lieu à Singapour en novembre 2019. Depuis, les conditions sanitaires ont forcé à annuler toutes les réunions. Mais notre nouveau RFC ne se limite pas au cas de la Covid-19. Une réunion, après tout, peut devoir être annulée pour d'autres raisons, un problème de dernière minute dans le bâtiment où elle devait se tenir, une catastrophe naturelle dans le pays d'accueil, un brusque changement dans la politique de visa de ce pays, etc. (Le RFC cite même le cas d'une guerre civile, mais ce n'est encore jamais arrivé à une réunion IETF.) Dans ces cas, l'IETF LLC (la direction administrative de l'IETF) et l'IESG vont devoir décider si on maintient la réunion ou pas.

La section 3 du RFC expose les critères de décision. L'IETF LLC (cf. RFC 8711) détermine si la réunion peut se tenir, l'IESG si cela vaut la peine de la tenir. L'IETF LLC doit évidemment travailler en toute transparence, informant l'IETF de la situation, des décisions possibles et d'un éventuel « plan B ». Il n'est pas toujours possible de procéder proprement et démocratiquement si la situation est urgente (tremblement de terre trois jours avant la réunion…). Dans ce cas, l'IETF LLC doit déterminer seule si la réunion peut se tenir (ce qui implique certaines garanties de sécurité pour les participants, de la restauration mais également un accès Internet qui marche ; les participants à l'IETF n'ont pas juste besoin de dormir et de manger, il leur faut aussi du réseau). L'IETF LLC doit aussi intégrer des paramètres internes comme la disponibilité de ses employés et des bénévoles, et bien sûr les conséquences financières du maintien ou de l'annulation (si le lieu de la réunion considère qu'il n'y avait pas force majeure et ne veut pas rembourser…). La section 3 du RFC 8718 contient des indications utiles à cette évaluation.

L'IESG, lui, doit déterminer s'il y aura suffisamment de monde à la réunion pour que ça vaille la peine. Il ne serait pas malin de maintenir une réunion pour que personne ne vienne.

La section 4 du RFC couvre les alternatives. Si on annule, que peut-on proposer à la place ? Il faut évaluer ces alternatives en tenant compte de leur efficacité (une réunion en ligne est moins efficace) et de leur coût (changer les billets d'avion au dernier moment coûte cher). Ces alternatives peuvent être, dans l'ordre décroissant de préférence :

• Changer le lieu de la réunion. C'est ce qui dérange le moins le travail, surtout si le nouveau lieu est proche de l'ancien. Naturellement, le nouveau lieu doit correspondre aux critères des RFC 8718 et RFC 8719.
• Passer en ligne, à une réunion « virtuelle », ce qui a été fait pour toutes les réunions annulées en raison de la Covid-19.
• Repousser la réunion à plus tard. Ce n'est en général pas facilement faisable, puisque cela perturbe les agendas de tout le monde.
• Annuler complètement, sans alternative. Le RFC note que cela aura des conséquences, non seulement sur le travail de normalisation, mais également sur des processus politiques comme la détermination de qui peut siéger dans des comités comme le NomCom (comité de nomination, cf. RFC 8788 et RFC 8989).

La section 5 de notre RFC couvre les questions financières. En gros, l'IETF ne remboursera pas les dépenses engagées par les participants (avion, hôtel, etc), seulement les frais d'inscription à la réunion, en totalité s'il y a annulation complète et partiellement dans les autres cas.

Le protocole DOTS (Distributed Denial-of-Service Open Threat Signaling) vise à permettre au client d'un service anti-dDoS de demander au service de mettre en route des mesures contre une attaque. Ce RFC décrit le canal de signalisation de DOTS, celui par lequel passera la demande d'atténuation de l'attaque. Il remplace le RFC 8782, mais les changements sont mineurs.

Si vous voulez mieux comprendre DOTS, il est recommandé de lire le RFC 8612, qui décrit le cahier des charges de ce protocole, et le RFC 8811, qui décrit l'architecture générale. Ici, je vais résumer à l'extrême : un client DOTS, détectant qu'une attaque par déni de service est en cours contre lui, signale, par le canal normalisé dans ce RFC, à un serveur DOTS qu'il faudrait faire quelque chose. Le serveur DOTS est un service anti-dDoS qui va, par exemple, examiner le trafic, jeter ce qui appartient à l'attaque, et transmettre le reste à son client.

Ces attaques par déni de service sont une des plaies de l'Internet, et sont bien trop fréquentes aujourd'hui (cf. RFC 4987 ou RFC 4732 pour des exemples). Bien des réseaux n'ont pas les moyens de se défendre seuls et font donc appel à un service de protection (payant, en général, mais il existe aussi des services comme Deflect). Ce service fera la guerre à leur place, recevant le trafic (via des manips DNS ou BGP), l'analysant, le filtrant et envoyant ce qui reste au client. Typiquement, le client DOTS sera chez le réseau attaqué, par exemple en tant que composant d'un IDS ou d'un pare-feu, et le serveur DOTS sera chez le service de protection. Notez donc que client et serveur DOTS sont chez deux organisations différentes, communiquant via le canal de signalisation (signal channel), qui fait l'objet de ce RFC.

La section 3 de notre RFC expose les grands principes du protocole utilisé sur ce canal de signalisation. Il repose sur CoAP, un équivalent léger de HTTP, ayant beaucoup de choses communes avec HTTP. Le choix d'un protocole différent de HTTP s'explique par les spécificités de DOTS : on l'utilise quand ça va mal, quand le réseau est attaqué, et il faut donc pouvoir continuer à fonctionner même quand de nombreux paquets sont perdus. CoAP a les caractéristiques utiles pour DOTS, il est conçu pour des réseaux où il y aura des pertes, il tourne sur UDP, il permet des messages avec ou sans accusé de réception, il utilise peu de ressources, il peut être sécurisé par DTLS… TCP est également utilisable mais UDP est préféré, pour éviter le head-of-line blocking. CoAP est normalisé dans le RFC 7252. Parmi les choses à retenir, n'oubliez pas que l'encodage du chemin dans l'URI est un peu spécial, avec une option Uri-Path: par segment du chemin (RFC 7252, section 5.10.1). Par abus de langage, j'écrirai « le client CoAP demande /foo/bar/truc.cbor » alors qu'il y aura en fait trois options Uri-Path: :

Uri-Path: "foo"
Uri-Path: "bar"
Uri-Path: "truc.cbor" 
  

Par défaut, DOTS va utiliser le port 4646 (et non pas le port par défaut de CoAP, 5684, pour éviter toute confusion avec d'autres services tournant sur CoAP). Ce port a été choisi pour une bonne raison, je vous laisse la chercher, la solution est à la fin de cet article. Le plan d'URI sera coaps ou coaps+tcp (RFC 7252, section 6, et RFC 8323, section 8.2).

Le fonctionnement de base est simple : le client DOTS se connecte au serveur, divers paramètres sont négociés. Des battements de cœur peuvent être utilisés (par le client ou par le serveur) pour garder la session ouverte et vérifier son bon fonctionnement. En cas d'attaque, le client va demander une action d'atténuation. Pendant que celle-ci est active, le serveur envoie de temps en temps des messages donnant des nouvelles. L'action se terminera, soit à l'expiration d'un délai défini au début, soit sur demande explicite du client. Le serveur est connu du client par configuration manuelle, ou bien par des techniques de découverte comme celles du RFC 8973.

Les messages sont encodés en CBOR (RFC 8949). Rappelez-vous que le modèle de données de CBOR est très proche de celui de JSON, et notre RFC spécifie donc les messages avec une syntaxe JSON, même si ce n'est pas l'encodage utilisé sur le câble. Pour une syntaxe formelle des messages, le RFC utilise YANG (cf. RFC 7951). Le type MIME des messages est application/dots+cbor.

La section 4 du RFC décrit les différents messages possibles plus en détail. Je ne vais pas tout reprendre ici, juste donner quelques exemples. Les URI commencent toujours par /.well-known/dots (.well-known est normalisé dans le RFC 8615, et dots est désormais enregistré à l'IANA). Les différentes actions ajouteront au chemin dans l'URI /mitigate pour les demandes d'actions d'atténuation, visant à protéger de l'attaque, /hb pour les battements de cœur, etc.

Voici par exemple une demande de protection, effectuée avec la méthode CoAP PUT :

Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
Content-Format: "application/dots+cbor"

{
       ... Données en CBOR (représentées en JSON dans le RFC et dans
       cet article, pour la lisibilité).
}    
  

L'URI, en notation traditionnelle, sera donc /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123. CUID veut dire Client Unique IDentifier et sert à identifier le client DOTS, MID est Mitigation IDentifier et identifie une demande d'atténuation particulière. Si ce client DOTS fait une autre demande de palliation, le MID changera mais le CUID sera le même.

Que met-on dans le corps du message ? On a de nombreux champs définis pour indiquer ce qu'on veut protéger, et pour combien de temps. Par exemple, on pourrait avoir (je rappelle que c'est du CBOR, format binaire, en vrai) :

     {
       "ietf-dots-signal-channel:mitigation-scope": {
         "scope": [
           {
             "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
              ],
             "target-port-range": [
               {
                 "lower-port": 80
               },
               {
                 "lower-port": 443
               }
              ],
              "target-protocol": [
                6
              ],
             "lifetime": 3600
           }
         ]
       }
     }
  

Ici, le client demande qu'on protège 2001:db8:6401::1 et 2001:db8:6401::2 (target veut dire qu'ils sont la cible d'une attaque, pas qu'on veut les prendre pour cible), sur les ports 80 et 443, en TCP, pendant une heure. (lower-port seul, sans upper-port indique un port unique, pas un intervalle.)

Le serveur va alors répondre avec le code 2.01 (indiquant que la requête est acceptée et traitée) et des données :

  {
     "ietf-dots-signal-channel:mitigation-scope": {
        "scope": [
           {
             "mid": 123,
             "lifetime": 3600
           }
         ]
      }
   }
  

La durée de l'action peut être plus petite que ce que le client a demandé, par exemple si le serveur n'accepte pas d'actions trop longues. Évidemment, si la requête n'est pas correcte, le serveur répondra 4.00 (format invalide), si le client n'a pas payé, 4.03, s'il y a un conflit avec une autre requête, 4.09, etc. Le serveur peut donner des détails, et la liste des réponses possibles figure dans des registres IANA, comme celui de l'état d'une atténuation, ou celui des conflits entre ce qui est demandé et d'autres actions en cours.

Le client DOTS peut ensuite récupérer des informations sur une action de palliation en cours, avec la méthode CoAP GET :

Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"    
  

Ce GET /.well-known/dots/mitigate/cuid=dz6pHjaADkaFTbjr0JGBpw/mid=123 va renvoyer de l'information sur l'action d'identificateur (MID) 123 :

   {
     "ietf-dots-signal-channel:mitigation-scope": {
       "scope": [
         {
           "mid": 123,
           "mitigation-start": "1507818393",
           "target-prefix": [
                "2001:db8:6401::1/128",
                "2001:db8:6401::2/128"
           ],
           "target-protocol": [
             6
           ],
           "lifetime": 1755,
           "status": "attack-stopped",
           "bytes-dropped": "0",
           "bps-dropped": "0",
           "pkts-dropped": "0",
           "pps-dropped": "0"
         }
       ]
     }
   }
  

Les différents champs de la réponse sont assez évidents. Par exemple, pkts-dropped indique le nombre de paquets qui ont été jetés par le protecteur.

Pour mettre fin aux actions du système de protection, le client utilise évidemment la méthode CoAP DELETE :

Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
  

Le client DOTS peut se renseigner sur les capacités du serveur avec un GET de /.well-known/dots/config.

Ce RFC décrit le canal de signalisation de DOTS. Le RFC 8783, lui, décrit le canal de données. Le canal de signalisation est prévu pour faire passer des messages de petite taille, dans un environnement hostile (attaque en cours). Le canal de données est prévu pour des données de plus grande taille, dans un environnement où les mécanismes de transport normaux, comme HTTPS, sont utilisables. Typiquement, le client DOTS utilise le canal de données avant l'attaque, pour tout configurer, et le canal de signalisation pendant l'attaque, pour déclencher et arrêter l'atténuation.

Les messages possibles sont modélisés en YANG. YANG est normalisé dans le RFC 7950. Notez que YANG avait été initialement créé pour décrire les commandes envoyées par NETCONF (RFC 6241) ou RESTCONF (RFC 8040) mais ce n'est pas le cas ici : DOTS n'utilise ni NETCONF, ni RESTCONF mais son propre protocole basé sur CoAP. La section 5 du RFC contient tous les modules YANG utilisés.

La mise en correspondance des modules YANG avec l'encodage CBOR figure dans la section 6. (YANG permet une description abstraite d'un message mais ne dit pas, à lui tout seul, comment le représenter en bits sur le réseau.) Les clés CBOR sont toutes des entiers ; CBOR permet d'utiliser des chaînes de caractères comme clés mais DOTS cherche à gagner de la place. Ainsi, les tables de la section 6 nous apprennent que le champ cuid (Client Unique IDentifier) a la clé 4, suivie d'une chaîne de caractères en CBOR. (Cette correspondance est désormais un registre IANA.) D'autre part, DOTS introduit une étiquette CBOR, 271 (enregistrée à l'IANA, cf. RFC 8949, section 3.4) pour marquer un document CBOR comme lié au protocole DOTS.

Évidemment, DOTS est critique en matière de sécurité. S'il ne fonctionne pas, on ne pourra pas réclamer une action de la part du service de protection. Et s'il est mal authentifié, on risque de voir le méchant envoyer de faux messages DOTS, par exemple en demandant l'arrêt de l'atténuation. La section 8 du RFC rappelle donc l'importance de sécuriser DOTS par TLS ou plutôt, la plupart du temps, par son équivalent pour UDP, DTLS (RFC 6347). Le RFC insiste sur l'authentification mutuelle du serveur et du client, chacun doit s'assurer de l'identité de l'autre, par les méthodes TLS habituelles (typiquement via un certificat). Le profil de DTLS recommandé (TLS est riche en options et il faut spécifier lesquelles sont nécessaires et lesquelles sont déconseillées) est en section 7. Par exemple, le chiffrement intègre est nécessaire.

La section 11 revient sur les questions de sécurité en ajoutant d'autres avertissements. Par exemple, TLS ne protège pas contre certaines attaques par déni de service, comme un paquet TCP RST (ReSeT). On peut sécuriser la communication avec TCP-AO (RFC 5925) mais c'est un vœu pieux, il est très peu déployé à l'heure actuelle. Ah, et puis si les ressources à protéger sont identifiées par un nom de domaine, et pas une adresse ou un préfixe IP (target-fqdn au lieu de target-prefix), le RFC dit qu'évidemment la résolution doit être faite avec DNSSEC.

Question mises en œuvre, DOTS dispose d'au moins quatre implémentations, dont l'interopérabilité a été testée plusieurs fois lors de hackathons IETF (la première fois ayant été à Singapour, lors de l'IETF 100) :

• Le travail de NTT, en Go, en logiciel libre,
• Les travaux non-libres de NCC, Arbor et Huawei

Notez qu'il existe des serveurs de test DOTS publics comme coaps://dotsserver.ddos-secure.net:4646.

Ah, et la raison du choix du port 4646 ? C'est parce que 46 est le code ASCII pour le point (dot en anglais) donc deux 46 font deux points donc dots.

L'annexe A de notre RFC résume les principaux changements depuis le RFC 8782. Le principal changement touche les modules YANG, mis à jour pour réparer une erreur et pour tenir compte du RFC 8791. Il y a aussi une nouvelle section (la 9), qui détaille les codes d'erreur à renvoyer, et l'espace des valeurs des attributs a été réorganisé… Rien de bien crucial, donc.

Le RFC 8955 spécifie comment utiliser BGP pour diffuser des règles de filtrage (dites « FlowSpec ») aux routeurs. On voit facilement qu'une annonce de règles de filtrage maladroite ou malveillante pourrait faire bien des dégâts et c'est pour cela que le RFC 8955 insiste sur l'importance de valider ces annonces. Mais les règles de validation étaient trop strictes et ce nouveau RFC les adoucit légèrement.

Le changement ? Le RFC 8955 imposait que la machine qui annonce une règle de filtrage pour un préfixe de destination donné soit également le routeur suivant (next hop) pour le préfixe en question. Cela limitait l'annonce aux routeurs situés sur le trajet des données. En iBGP (BGP interne à un AS, où les routeurs qui annoncent ne sont pas toujours ceux qui transmettent les paquets), cette règle était trop restrictive. (Pensez par exemple à un réflecteur de routes interne, par exemple géré par le SOC, réflecteur qui n'est même pas forcément un routeur.)

La règle nouvelle, plus libérale, ne concerne que du iBGP, interne à un AS ou à une confédération d'AS (RFC 5065). Entre des AS gérés par des organisations différentes (par exemple un AS terminal informant son opérateur Internet de ses désirs de filtrage), la règle de validation reste inchangée.

Plus formellement, la section 6 du RFC 8955, sur la validation des annonces de filtrage, est modifiée, l'étape « l'annonceur doit être également l'annonceur de la meilleure route » devient « l'annonceur doit être l'annonceur de la meilleure route ou bien le chemin d'AS doit être vide (ou n'inclure que des AS de la confédération, s'il y en a une) ». Le RFC précise également que cette validation relâchée doit pouvoir être désactivée par l'administrateur réseaux (s'ielle sait qu'il n'y aura pas d'annonces de filtrage par un routeur qui n'est pas sur le chemin des paquets). Vous noterez plus bas que, pour l'instant, seul Huawei le permet.

Il y a également un léger changement des règles de validation du chemlin d'AS, pour les cas des serveurs de route (a priori, ils ne relaient pas ce genre d'annonces et peuvent donc les rejeter). Le RFC note que, même avec une validation stricte, certaines faiblesses de BGP permettent quand même dans certains cas à tort l'envoi de règles de filtrage. C'est un problème fondamental du RFC 8955, qui n'est donc pas nouveau.

Les nouvelles règles de ce RFC sont déjà largement mises en œuvre chez les routeurs.

Nous sommes désormais noyés sous les publications qui parlent de l'empreinte environnementale du numérique et notamment de l'Internet. Mais ce nouveau livre est plus approfondi que beaucoup de ces publications et contient des récits intéressants.

Au passage, je ne sais pas si quelqu'un a calculé l'empreinte environnementale des livres qui critiquent l'empreinte environnementale de l'Internet ☺. Plus sérieusement, une bonne partie de ces livres sont juste de l'anti-numérique primaire, par des auteurs nostalgiques d'un passé où seule une minorité d'experts pouvaient décider et s'exprimer, auteurs qui regrettent le bon vieux temps (ils critiquent le numérique mais jamais l'automobile). Ces défauts se retrouvent aussi dans le livre de Guillaume Pitron (par exemple quand il mentionne, même s'il n'insiste pas là-dessus, qu'il faudrait que des autorités décident des usages légitimes de l'Internet) mais heureusement cela ne fait pas la totalité du livre.

Donc, de quoi parle ce livre ? De beaucoup de choses mais surtout des conséquences environnementales et (à la fin) géopolitiques de l'usage de l'Internet. L'auteur insiste sur la matérialité du monde numérique : loin des discours marketing lénifiants sur le « virtuel » ou sur le « cloud », le monde numérique s'appuie sur la matière, des métaux rares, des centrales électriques fonctionnant au charbon ou au nucléaire, des centres de données énormes. Ce discours n'est pas très original, cet argument de la matérialité a été souvent cité ces dernières années mais le poids du discours commercial est tel que beaucoup d'utilisateurs du numérique n'ont pas encore conscience de cette matérialité. Et elle a des conséquences concrètes, notamment en matière environnementale. Le numérique consomme de l'énergie, ce qui a des conséquences (par exemple en matière de relâchement de gaz à effet de serre, qui contribuent au réchauffement planétaire) et des matériaux dont l'extraction se fait dans des conditions souvent terribles et pas seulement pour l'environnement, mais surtout pour les humains impliqués.

Quelle que soit la part réelle du numérique dans les atteintes à l'environnement (les chiffres qui circulent sont assez « doigt mouillé »), il n'y a pas de doute que, face à la gravité du changement climatique, tout le monde devra faire un effort, le numérique comme les autres. Des techniques frugales comme LEDBAT (RFC 6817) ou Gemini sont des briques utiles de cet effort (mais l'auteur ne les mentionne pas).

C'est après que les choses se compliquent. Qui doit agir, où et comment ? Le livre contient beaucoup d'informations intéressantes et de reportages variés et met en avant certaines initiatives utiles. C'est par exemple le cas du Fairphone, un ordiphone conçu pour limiter l'empreinte environnementale et sociale. Beaucoup de critiques ont été émises contre ce projet, notant que les objectifs n'étaient pas forcément atteints, mais je les trouve injustes : une petite société locale n'a pas les mêmes armes qu'un GAFA pour changer le monde, et ses efforts doivent être salués, il vaut mieux ne faire qu'une partie du chemin plutôt que de rester assis à critiquer. C'est à juste titre que le projet Fairphone est souvent cité dans le livre. (Sur ce projet, je recommande aussi l'interview d'Agnès Crepet dans la série audio « L'octet vert ».)

Ces reportages sont la partie la plus intéressante du livre et une bonne raison de recommander sa lecture. Il comprend également une partie géopolitique intéressante, détaillant notamment l'exploitation de plus en plus poussée de l'Arctique (à la fois rendue possible par le changement climatique, et l'aggravant) et les projets gigantesques et pas du tout bienveillants de la Chine. Même si beaucoup de projets (comme le câble Arctic Connect) se sont cassés la figure, bien d'autres projets leur succèdent.

Par contre, le livre ne tient pas les promesses de son sous-titre « Voyage au bout d'un like ». S'il explique rapidement que le simple fait de cliquer sur un bouton « J'aime » va mettre en action de nombreuses machines, parcourir un certain nombre de kilomètres, et écrire dans plusieurs bases de données, il ne détaille pas ce parcours et ne donne pas de chiffres précis. Il est vrai que ceux-ci sont très difficiles à obtenir, à la fois pour des raisons techniques (la plupart des équipements réseau ont une consommation électrique constante et donc déterminer « la consommation d'un Like » n'a donc guère de sens) et politiques (l'information n'est pas toujours disponible et le greenwashing contribue à brouiller les pistes). L'auteur oublie de rappeler la grande faiblesse méthodologique de la plupart des études sur la question, et des erreurs d'ordre de grandeur comme l'affirmation p. 157 que les États-Unis produisent… 640 tonnes de charbon par an n'aident pas à prendre aux sérieux les chiffres.

Mais le livre souffre surtout de deux problèmes : d'abord, il réduit l'utilisation de l'Internet au Like et aux vidéos de chat, souvent citées. D'accord, c'est amusant et, comme beaucoup d'utilisateurs, je plaisante moi-même souvent sur ce thème. Mais la réalité est différente : l'Internet sert à beaucoup d'activités, dont certaines sont cruciales, comme l'éducation, par exemple. L'auteur critique le surdimensionnement des infrastructures par les opérateurs, jugeant qu'il s'agit d'un gaspillage aux conséquences environnementales lourdes. Mais il oublie que ce surdimensionnement est au contraire indispensable à la robustesse de l'Internet, comme on l'a bien vu pendant le confinement, avec l'augmentation du trafic (voir le RFC 9075). Outre les pandémies, on pourrait également citer les attaques par déni de service (la cybersécurité est absente du livre), qui sont une excellente raison de surdimensionner les infrastructures.

Et le deuxième problème ? Parce que l'auteur pourrait répondre qu'il est bien conscient de la coexistence d'usages « utiles » et « futiles » de l'Internet et qu'il suggère de limiter les seconds. C'est là qu'est le deuxième problème : qui va décider ? Personnellement, je pense que le sport-spectacle (par exemple les scandaleux jeux olympiques de Paris, monstruosité environnementale) est à bannir des réseaux (et du reste du monde, d'ailleurs). Mais je ne serais probablement pas élu avec un tel programme. Personne n'est d'accord sur ce qui est sérieux et ce qui est futile. Qui va décider ? Des phrases du livre comme le fait d'ajouter « sacro-sainte » devant chaque mention de la neutralité de l'Internet ont de quoi inquiéter. J'avais déjà relevé ce problème dans ma critique du dernier livre de Ruffin. Une décision démocratique sur les usages, pourquoi pas ; mais je vois un risque sérieux de prise de pouvoir par des sages auto-proclamés qui décideraient depuis leurs hauteurs de ce qui est bon pour le peuple ou pas.

Je ne vais pas citer les articles publiés dans les médias sur ce livre, tous unanimement élogieux et sans jamais une seule critique. La corporation médiatique se serre les coudes, face à un Internet qui a écorné leur monopole de la parole. Mais, sinon, une autre critique de ce livre, sous un angle assez différent, celle de laem.

Ce nouveau RFC décrit un profil du protocole ACME d'obtention de certificat, profil qui permet de déléguer la demande à un tiers. C'est surtout utile pour le cas où vous sous-traitez l'hébergement de votre site Web (par exemple sur un CDN) : le sous-traitant peut alors demander un certificat, avec sa clé privée à lui, pour un nom de domaine que vous contrôlez et prouver qu'il héberge bien le serveur pour ce nom. Serveurs et clients TLS n'ont pas besoin d'être modifiés (seuls les serveurs et clients ACME le seront), et, bien entendu, le titulaire du nom de domaine garde un complet contrôle et peut, par exemple, révoquer les certificats obtenus par ses sous-traitants.

Ce profil utilise lui-même le profil STAR (Short-Term, Automatically Renewed) décrit dans le RFC 8739 donc faites bien attention à avoir lu le RFC 8739 avant. Le cas typique d'utilisation de ce mécanisme de délégation est le CDN. Un webmestre (l'IdO pour Identifier Owner car il est titulaire du nom de domaine, mettons foobar.example) a un site Web et sous-traite tout ou partie du service à un CDN, appelé ici NDC pour Name Delegation Consumer (et la ressemblance entre les sigles CDN et NDC est volontaire). Le CDN devra pouvoir répondre aux requêtes HTTPS pour www.foobar.example et donc présenter un certificat au nom www.foobar.example. Avec ACME, l'IdO peut obtenir un tel certifiat mais il ne souhaite probablement pas transmettre la clé privée correspondante au NDC. La solution de notre RFC est d'utiliser une extension à ACME, permettant la délégation du nom. Le NDC pourra alors obtenir un certificat STAR (de courte durée de vie, donc) pour www.foobar.example. Pas besoin de partager une clé privée, ni de transmettre des secrets de longue durée de vie (les délégations sont révocables, et les certificats STAR ne durent pas longtemps, le NDC devra renouveller souvent et ça cessera en cas de révocation). C'est l'utilisation typique de la délégation mais d'autres sont possibles (par exemple avec des certificats ordinaires, non-STAR). Le RFC note que la solution de délégation ne modifie qu'ACME, et pas TLS, et qu'elle marche donc avec les clients et serveurs TLS actuels (contrairement à d'autres propositions qui sont étudiées).

Pour que la délégation fonctionne, l'IdO doit avoir un serveur ACME, auquel le NDC devra se connecter, et s'être mis d'accord avec le NDC sur les paramètres à utiliser. C'est donc une étape relativement nouvelle, l'utilisateur d'ACME typique n'ayant qu'un client ACME, seule l'AC a un serveur. Mais c'est quand même plus simple que de monter une AC. Le serveur ACME chez l'IdO ne signera pas de certificats, il relaiera simplement la requête. Quand le NDC aura besoin d'un certificat, il enverra une demande à l'IdO, qui la vérifiera et, devenant client ACME, l'IdO enverra une demande à l'AC. Si ça marche, l'IdO prévient le NDC, et celui-ci récupérera le certificat chez l'AC (par unauthenticated GET, RFC 8739, section 3.4).

Le protocole ACME gagne un nouveau type d'objet, les délégations, qui indiquent ce qu'on permet au NDC. Comme les autres objets ACME, elles sont représentées en JSON et voici un exemple :

{
     "csr-template": {
       "keyTypes": [
         {
           "PublicKeyType": "id-ecPublicKey",
           "namedCurve": "secp256r1",
           "SignatureType": "ecdsa-with-SHA256"
         }
       ],
       "subject": {
         "country": "FR",
         "stateOrProvince": "**",
         "locality": "**"
       },
       "extensions": {
         "subjectAltName": {
           "DNS": [
             "www.foobar.example"
           ]
         },
         "keyUsage": [
           "digitalSignature"
         ],
         "extendedKeyUsage": [
           "serverAuth"
         ]
         }
     }
}
  

(Les champs des extensions comme keyUsage sont dans un nouveau registre IANA ; on peut ajouter des champs, selon la politique « spécification nécessaire ».) Ici, le NDC est autorisé à demander des certificats ECDSA pour le nom www.foobar.example. Quand le NDC enverra sa requête de certificat à l'IdO, il devra inclure cet objet « délégation », que l'IdO pourra comparer avec ce qu'il a configuré pour ce NDC. Voici un exemple partiel, envoyé lors d'un POST HTTPS au serveur ACME de l'IdO :

   {
     "protected": base64url({
       "alg": "ES256",
       "kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
       "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
       "url": "https://acme.ido.example/acme/new-order"
     }),
     "payload": base64url({
       "identifiers": [
         {
           "type": "dns",
           "value": "www.foobar.example"
         }
       ],
       "delegation":
         "https://acme.ido.example/acme/delegation/gm0wfLYHBen"
     }),
     "signature":    ...
  

(Le nouveau champ delegation a été placé dans le registre IANA.) Le NDC enverra ensuite le CSR, et l'IdO relaiera la requête vers le serveur ACME de l'AC (moins l'indication de délégation, qui ne regarde pas l'AC).

Quand on utilise un CDN, il est fréquent qu'on doive configurer un alias dans le DNS pour pointer vers un nom indiqué par l'opérateur du CDN. Voici par exemple celui de l'Élysée :

% dig CNAME www.elysee.fr 
...
;; ANSWER SECTION:
www.elysee.fr.		3600 IN	CNAME 3cifmt6.x.incapdns.net.
...

L'extension au protocole ACME spécifiée dans notre RFC permet au NDC d'indiquer cet alias dans sa requête, l'IdO peut alors l'inclure dans sa zone DNS.

Tous les serveurs ACME ne seront pas forcément capables de gérer des délégations, il faudra donc l'indiquer dans les capacités du serveur, avec le champ delegation-enabled (mis dans le registre IANA).

Comme indiqué plus haut, l'IdO peut arrêter la délégation quand il veut, par exemple parce qu'il change de CDN. Cet arrêt se fait par une interruption explicite de la demande STAR (RFC 8739, section 3.1.2). Si les certificats ne sont pas des STAR, le mécanisme à utiliser est la révocation normale des certificats.

Après cet examen du protocole, la section 3 de notre RFC décrit le comportement de l'AC. Il n'y a pas grand'chose à faire pour l'AC (le protocole est entre le NDC et l'IdO) à part à être capable d'accepter des récupérations non authentifiées de certificats (car le NDC n'a pas de compte à l'AC).

On a parlé plus haut du CSR. Il doit se conformer à un certain gabarit, décidé par l'IdO. Ce gabarit est évidemment au format JSON, comme le reste d'ACME. La syntaxe exacte est décrite avec le langage CDDL (RFC 8610) et figure dans l'annexe A ou bien, si vous préférez, avec le langage JSON Schema, utilisé dans l'annexe B. Voici l'exemple de gabarit du RFC :

  {
     "keyTypes": [
       {
         "PublicKeyType": "rsaEncryption",
         "PublicKeyLength": 2048,
         "SignatureType": "sha256WithRSAEncryption"
       },
       {
         "PublicKeyType": "id-ecPublicKey",
         "namedCurve": "secp256r1",
         "SignatureType": "ecdsa-with-SHA256"
       }
     ],
     "subject": {
       "country": "CA",
       "stateOrProvince": "**",
       "locality": "**"
     },
     "extensions": {
       "subjectAltName": {
         "DNS": [
           "abc.ido.example"
         ]
       },
       "keyUsage": [
         "digitalSignature"
       ],
       "extendedKeyUsage": [
         "serverAuth",
         "clientAuth"
       ]
     }
   }

Dans cet exemple, l'IdO impose au NDC un certificat RSA ou ECDSA et rend impérative (c'est le sens des deux astérisques) l'indication de la province et de la ville. L'IdO doit évidemment vérifier que le CSRT reçu se conforme bien à ce gabarit.

Le RFC présente (en section 5) quelques autres cas d'utilisation de cette délégation. Par exemple, un IdO peut déléguer à plusieurs CDN, afin d'éviter que la panne d'un CDN n'arrête tout. Avec la délégation, ça se fait tout seul, chacun des CDN est authentifié, et demande séparément son certificat.

Autre cas rigolo, celui où le CDN délègue une partie du service à un CDN plus petit. Le modèle de délégation ACME peut s'y adapter (le petit CDN demande un certificat au gros, qui relaie à l'IdO…), si les différentes parties sont d'accord.

Enfin, la section 7 du RFC revient sur les propriétés de sécurité de ces délégations. En gros, il faut avoir confiance en celui à qui on délègue car, pendant la durée de la délégation, il pourra faire ce qu'il veut avec le nom qu'on lui a délégué, y compris demander d'autres certificats en utilisant sa délégation du nom de domaine. Il existe quelques mesures techniques que l'IdO peut déployer pour empêcher le NDC de faire trop de bêtises. C'est le cas par exemple des enregistrements DNS CAA (RFC 8659) qui peuvent limiter le nombre d'AC autorisées (voir aussi le RFC 8657).

Je ne connais pas encore d'opérateur de CDN qui mette en œuvre cette solution.