Mon blog

Vous le savez, le protocole DNS permet plusieurs sortes de messages, identifiés par un code d'opération. Si le classique QUERY, pour demander à résoudre un nom en informations pratiques, est le plus connu, il y a aussi le UPDATE (modifier les données), le DSO (DNS Stateful Operations) et quelques autres. Et puis il y a le NOTIFY, qui sert à indiquer à un serveur DNS qu'il y a quelque chose de nouveau et d'intéressant. NOTIFY est surtout connu pour son utilisation afin de… notifier un serveur secondaire que le primaire a une nouvelle version de la zone (c'est dans le RFC 1996). Ce nouveau RFC généralise le concept et permet d'utiliser NOTIFY pour d'autres choses comme un changement dans la liste des serveurs faisant autorité ou un changement de clé DNSSEC.

Si vous avez oublié à quoi servait initialement NOTIFY, relisez le RFC 1996. Il permettait de donner une indication (uniquement une indication, le NOTIFY ne fait pas autorité) comme quoi il faudrait envisager un nouveau transfert de zone (RFC 5936) pour mettre à jour un serveur. Cela permettait des mises à jour plus rapides qu'avec le système traditionnel où chaque serveur esclave devait de temps en temps demander à son maître s'il y avait du nouveau. Mais il y a d'autres cas où un serveur DNS voudrait dire à un autre qu'il y a quelque chose à regarder, par exemple si une nouvelle clé doit être utilisée. D'où l'extension d'utilisation que permet notre RFC 9859. Elle ne change pas le protocole, elle se contente d'utiliser plus largement une fonction existante.

Bon, mais c'est bien joli de dire qu'on peut notifier pour bien des choses mais on notifie qui ? Dans le cas traditionnel d'une nouvelle version de la zone, le primaire savait qu'il devait notifier ses secondaires, qu'il connait (après tout, il doit leur autoriser le transfert de zone et, dans le pire des cas, il peut toujours regarder l'ensemble d'enregistrements NS de sa zone). Mais si on généralise le NOTIFY, on peut ne pas savoir qui notifier (les autres mécanismes de notification, comme une API ou comme la mise à jour dynamique du RFC 2136, ont d'ailleurs le même problème). La section 3 du RFC couvre ce problème. La méthode recommandée est de publier un enregistrement de type DSYNC, normalisé dans notre RFC, section 2. Il se place sous le nom _dsync de la zone :

sousdomaine._dsync  IN DSYNC  CDS   NOTIFY 5359 cds-scanner.example.net.
  

Notez qu'un joker est possible, par exemple :

*._dsync  IN DSYNC  CDS   NOTIFY 5359 cds-scanner.example.net.
*._dsync  IN DSYNC  CSYNC NOTIFY 5359 cds-scanner.example.net.
  

Ce nom _dsync a été ajouté dans le registre des noms précédés d'un trait bas (RFC 8552). Voici un autre exemple d'enregistrement DSYNC :

_dsync.example.net.   IN DSYNC  CDS   NOTIFY 5359 cds-scanner.example.net.
  

Que dit-il ? Qu'example.net, a priori un hébergeur DNS, voudrait que ses clients, lorsqu'ils ont un nouvel enregistrement CDS (indiquant l'activation d'une nouvelle clé DNSSEC, cf. RFC 8078), notifient cds-scanner.example.net sur le port 5359. Ce nouveau type DSYNC a été ajouté au registre des types, avec la valeur 66.

La section 4.1 détaille comment on trouve le serveur à qui envoyer la notification en utilisant _dsync. Imaginons qu'on gère extra.sub.exodus-privacy.eu.org et qu'on veuille notifier la zone parente. On insère le composant _dsync après le premier composant (cela donne extra._dsync.sub.exodus-privacy.eu.org) et on fait une requête pour ce nom et le type DSYNC. Si ça marche, c'est bon, sinon, on utilise le SOA dans la réponse pour trouver la zone parente, et on met le _dsync devant. Si ça ne donne toujours rien, on retire les composants avant la zone parente et on recommence. Donc, on interrogera successivement (jusqu'au premier succès), extra._dsync.sub.exodus-privacy.eu.org, extra.sub._dsync.exodus-privacy.eu.org et _dsync.exodus-privacy.eu.org.

Et le NOTIFY dans l'enregistrement DSYNC d'exemple plus haut ? C'est le plan (scheme, à ne pas confondre avec le code d'opération - opcode - NOTIFY) car DSYNC, dans le futur, pourra servir à autre chose que les notifications. Pour l'instant, dans le nouveau registre des plans, il n'y a que NOTIFY mais dans le futur, d'autres pourront être ajoutés (suivant la politique « Examen par un expert » du RFC 8126).

Comment utiliser ce mécanisme de notification généralisé pour traiter les enregistrements CDS et CDNSKEY des RFC 7344, RFC 8078 et RFC 9615 ? Ces enregistrements servent à signaler à la zone parente la disponibilité de nouvelles clés DNSSEC. La section 4 de notre RFC détaille comment le mécanisme de notification permet d'indiquer qu'un CDS ou un CDNSKEY a changé. Cela évite au gestionnaire de la zone parente de balayer toute la zone ce qui, pour un TLD de plusieurs millions de noms comme .fr serait long et pénible. La solution de ce RFC 9859 est donc de chercher les DSYNC puis d'envoyer les NOTIFY, au moins deux, un pour le type CDS et un pour le type CDNSKEY (on ne sait pas forcément à l'avance lesquels utilisent la zone parente). La zone parente doit effectuer les mêmes vérifications que lorsqu'elle a détecté un nouveau CDS (ou CDNSKEY) : RFC 9615 si on active une zone signée pour la première fois et RFC 7344 et RFC 8078 autrement.

Les messages utilisant le code d'opération NOTIFY sont censés produire une réponse (RFC 1996, section 4.7). Si aucune réponse n'arrive avant l'expiration du délai de garde, on réessaie. Si on a trop réessayé, on peut signaler le problème avec la technique du RFC 9567.

Il est important de se souvenir qu'une notification n'est pas sérieusement authentifiée, et que le récepteur doit donc, s'il choisit d'agir sur une notification, être prudent. Dans le RFC 1996, rien de grave ne pouvait arriver, le récepteur du NOTIFY demandait juste le SOA de la zone puis, si nécessaire, un transfert de zone. Mais avec les CDS et CDNSKEY, des attaques plus sérieuses sont possibles et le destinataire de la notification doit donc effectuer davantage de vérifications (par exemple, si la zone est déjà signée, faire une requête pour le CDS ou le CDNSKEY et vérifier que la réponse est valide et sécurisée, si elle ne l'est pas, faire tous les contrôles du RFC 9615). La notification elle-même n'est pas un problème de sécurité (elle dit juste « tu devrais regarder cela »), c'est l'action qui en résulte qui doit être bien réfléchie. Voilà pourquoi les notifications, même généralisées, ne sont pas plus sécurisées que cela. (Voir aussi la section 5 du RFC, qui insiste sur ce point ; la notification peut accélérer les choses mais ne doit pas à elle-même changer quelque chose.) Il est quand même préférable de limiter le nombre de notifications qu'on traite, au cas où un client malveillant vous bombarde de notifications.

Ces notifications généralisées pourront aussi s'utiliser pour les CSYNC du RFC 7477.

Qui met en œuvre ce RFC à l'heure actuelle ? Des opérateurs comme deSEC ont annoncé que c'était en cours, côté client. Côté serveur, les registres de .ch et .se ont annoncé que c'était en cours, ou bien prévu.

Voici un exemple d'un client en Python (utilisant dnspython) qui notifie pour un nouveau CDS :

import dns.message
import dns.query    
import dns.opcode

notify = dns.message.make_query("bortzmeyer.fr", "CDS")
notify.set_opcode(dns.opcode.NOTIFY)
response = dns.query.udp(notify, "192.0.2.211")
print(response)
  

Et en C ? Vous pouvez utiliser le programme d'exemple generalized-notify.c, qui utilise l'excellente bibliothèque ldns. Compiler et exécuter :

% gcc -o generalized-notify -Wall generalized-notify.c -lldns 

% ./generalized-notify bortzmeyer.fr 192.0.2.211
Reply code: NOERROR
  

Je note à ce sujet que certains serveurs faisant autorité, lorsqu'ils ne font pas autorité pour le domaine signalé, répondent REFUSED, ce qui est logique, mais on voit aussi des FORMERR ou NXDIOMAIN (!), sans doute parce que le type CDS ne leur plait pas.

L'annexe A du RFC prend de la hauteur et décrit plus en détail le problème du balayage DNS. Comment savoir qu'il y a du nouveau, sans tout examiner (dans le cas du SOA, au rythme indiqué par le champ Refresh ; mais il n'y a pas de telle solution pour les CDS et CDNSKEY). Le DNS traditionnel ne marchait que sur un modèle pull (et c'est pour cela qu'il est faux de parler de propagation DNS) mais les NOTIFY du RFC 1996 introduisaient un peu de push. Heureusement car balayer .com à la recherche de nouveaux enregistrements serait lent (et attirerait probablement l'attention des IDS). Pour les CDS et CDNSKEY, cela serait d'autant plus agaçant qu'ils seront a priori peu nombreux et que la plupart des requêtes ne donneront donc rien.

Dans un registre de noms de domaine, il existe une classe d'objets pour les domaines et parfois une pour les serveurs de noms (hosts). C'est en se basant sur les objets de ces classes que des informations sont ensuite publiées dans le DNS. Que se passe-t-il si on retire un objet de ces classes, alors que d'autres objets en dépendaient ? Va-t-on scier une branche sur laquelle quelqu'un est assis ? Ce RFC fait le point sur les solutions existantes, notant que certaines sont moins bonnes que d'autres, notamment pour la sécurité.

Prenons un exemple simple : le domaine monbeaudomaine.example est enregistré auprès du registre du TLD .example. Ses serveurs de noms sont ns1.domaine-d-un-copain.example et ns1.hébergeur.example et on va supposer que le registre de .example traite les serveurs de noms comme une classe distincte dans sa base de données. Maintenant, supposons que le domaine domaine-d-un-copain.example soit supprimé parce que son titulaire n'en voit plus l'utilité. Que va devenir le serveur de noms ns1.domaine-d-un-copain.example ? Il existe de nombreuses façons de traiter ce problème, et c'est le rôle de ce RFC de les analyser toutes.

Ainsi, la section 3.2.2 du RFC 5731 dit que ce n'est pas bien de détruire un domaine si des objets de type serveur de noms sont sous ce domaine. Dans l'exemple précédent, le registre de .example aurait refusé la suppression de domaine-d-un-copain.example. Mais cela laisse le problème entier : si le titulaire ne veut plus payer et donc veut supprimer le domaine, que faire ?

Un cas similaire se produit si on veut supprimer un serveur de noms. Si le client EPP demande au serveur EPP du registre de .example la suppression de l'objet ns1.domaine-d-un-copain.example, que doit faire le registre, sachant que ce serveur de noms est utilisé par monbeaudomaine.example ? La section 3.2.2 du RFC 5732 dit que le registre devrait refuser la suppression. C'est d'autant plus gênant que, dans le modèle RRR (Registrant-Registrar-Registry), domaine et serveur(s) peuvent être gérés par des BE différents, n'ayant pas le droit de toucher aux objets des autres BE.

Vous pouvez trouver des bonnes explications et des exemples réels dans les supports d'une présentation qui avait été faite à l'IETF.

Quelles sont donc les recommandations concrètes de ce RFC ? La section 6 les résume. Au choix :

• Renommer les serveurs de noms vers le nom d'un serveur maintenu par le client EPP (le BE), comme décrit dans la section 5.1.3.4.
• Demander au client EPP de supprimer les serveurs de noms mais avec possibilité de rétablissement (RFC 3915) comme décrit en section 5.2.2.3.
• Renommer les serveurs de noms dans un nom de domaine spécial, dont il est garanti qu'il ne sera jamais utilisé, comme décrit en section 5.1.4.3. Pour éviter d'avoir à créer une nouvelle entrée dans le registre des noms de domaine spéciaux, le nom sacrificial.invalid, utilisant un TLD existant, est recommandé.

Le protocole EPP permet de changer le nom d'un serveur de noms (section 3.2.5 du RFC 5732). Une pratique déjà observée est donc de renommer les serveurs de noms. Dans l'exemple ci-dessus, recevant la demande de suppression de domaine-d-un-copain.example, le registre (ou le BE s'il le peut) renommerait ns1.domaine-d-un-copain.example en, mettons, ns1.domaine-d-un-copain.renamed.invalid. Ici, .invalid, TLD réservé par le RFC 6761, ne poserait pas vraiment de problème mais renommer dans un domaine ouvert à l'enregistrement pourrait créer un risque de sécurité, si le domaine de destination n'existe pas, un méchant pouvant alors l'enregistrer et être ainsi en mesure de répondre aux requêtes DNS.

La section 3 du RFC explique brièvement pourquoi les RFC 5731 et RFC 5732 déconseillent fortement de permettre la suppression d'un domaine tant que des serveurs de noms dans ce domaine existent. Il y a deux risques de sécurité si on détruisait le domaine en laissant les serveurs de noms tels quels dans la base de données du registre : un de déni de service (le nom ne se résout plus et le serveur va donc être inutile) et un de détournement (si un méchant peut ré-enregistrer le nom de domaine supprimé). Il y a aussi le problème de la colle orpheline, décrit dans le rapport du SSAC, « Comment on Orphan Glue Records in the Draft Applicant Guidebook ».

Si la clé qui identifie un serveur de noms est un numéro quelconque et pas son nom, on peut renommer le serveur sans changer les délégations, ce qui est particulièrement utile si le client EPP n'a pas le droit de changer des délégations qui appartiennent à un autre client du registre. Le nouveau nom ne va en général pas être associé à un serveur opérationnel : on sacrifie un serveur pour pouvoir supprimer le domaine parent. Mais cela entraine quelques risques (section 4 du RFC et l'article d' Akiwate, G., Savage, S., Voelker, G., et K. Claffy, « Risky BIZness: Risks Derived from Registrar Name Management »). Si on renomme vers un nom actuellement inexistant, le domaine peut être détourné si un malveillant enregistre ensuite ce domaine.

Compte tenu de tout cela, la section 5 du RFC étudie les différentes pratiques possibles, leurs avantages et leurs inconvénients. Pour les illustrer, je vais utiliser une base de données simple, décrite en SQL (les essais ont été faits avec PostgreSQL). Voici par exemple une création d'une telle base :

CREATE TABLE Domains (name TEXT UNIQUE);

-- Ici, la table Nameservers n'offre aucune valeur ajoutée par rapport
-- au fait de tout mettre dans Domains. Mais ce ne sera pas le cas par
-- la suite. 
CREATE TABLE Nameservers (name TEXT UNIQUE);

CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name),
                         server TEXT REFERENCES Nameservers(name));

INSERT INTO Domains VALUES ('monbeaudomaine.example');
INSERT INTO Domains VALUES ('domaine-d-un-copain.example');

INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example');
INSERT INTO Nameservers VALUES ('ns1.hébergeur.example');

INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example');
INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example');
  

Dans ce premier cas très simple, la suppression du domaine domaine-d-un-copain.example est triviale :

registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example';
DELETE 1
  

Mais elle laisse la possibilité de colle orpheline et surtout d'un détournement de monbeaudomaine.example si quelqu'un ré-enregistre domaine-d-un-copain.example. Ce premier essai n'est pas conforme aux exigences des RFC 5731 et RFC 5732. On va essayer de faire mieux.

Si on interdit (à juste titre) la suppression d'un domaine lorsque des serveurs de noms sont nommés dans ce domaine, on peut arriver à supprimer un domaine en supprimant d'abord les serveurs de noms qui sont nommés dans ce domaine (section 5.2) :

CREATE TABLE Domains (name TEXT UNIQUE);

-- Ajout d'une dépendance au domaine parent, pour éviter les suppressions. 
CREATE TABLE Nameservers (name TEXT UNIQUE, parent TEXT REFERENCES Domains(name));

CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name),
                         server TEXT REFERENCES Nameservers(name));

INSERT INTO Domains VALUES ('monbeaudomaine.example');
INSERT INTO Domains VALUES ('domaine-d-un-copain.example');
INSERT INTO Domains VALUES ('hébergeur.example');

-- Pour une vraie base, on écrirait du code SQL qui extrait le parent
-- automatiquement.
INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example');
INSERT INTO Nameservers VALUES ('ns1.hébergeur.example', 'hébergeur.example');

INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example');
INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example');

registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example';
ERROR:  update or delete on table "domains" violates foreign key constraint "nameservers_parent_fkey" on table "nameservers"
DETAIL:  Key (name)=(domaine-d-un-copain.example) is still referenced from table "nameservers".
-- Ce comportement est ce que recommandent les RFC 5731 et 5732.

-- Cela oblige le client à supprimer les serveurs de noms d'abord, ce qui à
-- son tour nécessite potentiellement de changer les délégations :

registry=> DELETE FROM Delegation WHERE server = 'ns1.domaine-d-un-copain.example';
DELETE 1
registry=>  DELETE FROM Nameservers WHERE name='ns1.domaine-d-un-copain.example';
DELETE 1
registry=>  DELETE FROM Domains WHERE name='domaine-d-un-copain.example';
DELETE 1
  

Ici, il y a eu suppression explicite des serveurs de noms par le client (section 5.2.2.1). Cela peut poser des problèmes de permission, dans le cadre du système RRR, si tous les objets ne sont pas chez le même BE. Mais la suppression explicite est une des trois solutions recommandées, notamment si on ajoute la possibilité de rétablir l'état précédent (commande EPP <restore>, RFC 3915).

On peut aussi envisager une suppression implicite (section 5.2.1.1), le registre se chargeant du nettoyage (c'est le rôle de la directive SQL ON DELETE CASCADE) :

CREATE TABLE Domains (name TEXT UNIQUE);

CREATE TABLE Nameservers (name TEXT UNIQUE,
                          parent TEXT REFERENCES Domains(name) ON DELETE CASCADE);

CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name) ON DELETE CASCADE,
                         server TEXT REFERENCES Nameservers(name) ON DELETE CASCADE);

INSERT INTO Domains VALUES ('monbeaudomaine.example');
INSERT INTO Domains VALUES ('domaine-d-un-copain.example');
INSERT INTO Domains VALUES ('hébergeur.example');

-- Pour une vraie base, on écrirait du code SQL qui extrait le parent
-- automatiquement.
INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example');
INSERT INTO Nameservers VALUES ('ns1.hébergeur.example', 'hébergeur.example');

INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example');
INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example');

registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.name;
          name          |              name               
------------------------+---------------------------------
monbeaudomaine.example | ns1.domaine-d-un-copain.example
monbeaudomaine.example | ns1.hébergeur.example
(2 rows)

registry=>  DELETE FROM Domains WHERE name='domaine-d-un-copain.example';
DELETE 1

-- Serveur de noms et délégation ont été détruits en cascade. Ce n'est
-- pas déraisonnable mais c'est quand même un peu effrayant.

registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.name;
          name          |         name          
------------------------+-----------------------
monbeaudomaine.example | ns1.hébergeur.example
(1 row)
  

Cette solution est simple et efficace mais détruire implicitement des objets de la base de données peut inquiéter les responsables de cette base. Et cela peut laisser un domaine avec trop peu de serveurs de noms pour assurer sa continuité de service voire, dans le pire des cas, sans serveurs du tout. Et il serait bon de prévenir le client de cette suppression implicite, par exemple par le mécanisme de poll d'EPP (RFC 8590).

Si on interdit (à juste titre, le RFC le recommande) la suppression d'un domaine lorsque des serveurs de noms sont nommés dans ce domaine, une solution possible est de renommer les serveurs avant de supprimer le domaine (section 5.1). Le nouveau nom permet d'indiquer clairement la raison du renommage. Mais ce renommage laisse dans la base des « déchets » qu'il faudra nettoyer un jour. Cette catégorie contient de nombreuses variantes. Par exemple, on peut renommer dans un TLD spécial (RFC 6761), ici, .invalid :

CREATE TABLE Domains (name TEXT UNIQUE);

-- On introduit un identificateur du serveur de noms qui n'est *pas*
-- son nom, pour permettre le renommage.
CREATE TABLE Nameservers (id SERIAL UNIQUE, name TEXT UNIQUE,
                                 parent TEXT REFERENCES Domains(name));

CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name),
                         server INTEGER REFERENCES Nameservers(id));

INSERT INTO Domains VALUES ('monbeaudomaine.example');
INSERT INTO Domains VALUES ('domaine-d-un-copain.example');
INSERT INTO Domains VALUES ('hébergeur.example');
-- Pour le renommage, un nom qui indique clairement le but :
INSERT INTO Domains VALUES ('renamed.invalid');

-- Pour une vraie base, on écrirait du code SQL qui extrait le parent
-- automatiquement.
INSERT INTO Nameservers (name, parent) VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example');
INSERT INTO Nameservers (name, parent) VALUES ('ns1.hébergeur.example', 'hébergeur.example');

INSERT INTO Delegation VALUES ('monbeaudomaine.example',
     (SELECT id FROM Nameservers WHERE name='ns1.domaine-d-un-copain.example'));
INSERT INTO Delegation VALUES ('monbeaudomaine.example',
     (SELECT id FROM Nameservers WHERE name='ns1.hébergeur.example'));

registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.id;
          name          |              name               
------------------------+---------------------------------
monbeaudomaine.example | ns1.domaine-d-un-copain.example
monbeaudomaine.example | ns1.hébergeur.example
(2 rows)

registry=> UPDATE Nameservers SET name='ns1.domaine-d-un-copain.example.renamed.invalid', parent='renamed.invalid' WHERE id=1;
UPDATE 1
registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example';
DELETE 1

registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.id;
          name          |                      name                       
------------------------+-------------------------------------------------
monbeaudomaine.example | ns1.domaine-d-un-copain.example.renamed.invalid
monbeaudomaine.example | ns1.hébergeur.example
(2 rows)

Par contre, il ne faut pas utiliser .alt, qui est explicitement réservé aux protocoles non-DNS (RFC 9476). Notez que certains serveurs EPP peuvent tester le nom des serveurs de noms et refuser des TLD « inconnus ».

Dans la nature, on a pu observer d'autres pratiques, comme de renommer dans un sous-domaine de as112.arpa, nom garanti ne pas exister (RFC 7535), mais qui n'est pas censé servir à cela (RFC 6305). On a vu aussi des renommages vers des résolveurs DNS publics, ce qui est également une horreur, la délégation doit être faite vers des serveurs faisant autorité, pas des résolveurs.

Certains clients EPP maintiennent des serveurs de noms actifs qui servent pour le renommage. Cela fait davantage de travail mais cela protège contre le détournement. Le DNS va continuer à fonctionner normalement. On pourrait aussi imaginer des serveurs de noms actifs, répondant NXDOMAIN (« ce domaine n'existe pas »), qui soient gérés collectivement (section 5.1.4.4) ; un tel service serait certainement utile. On pourrait même créer un nom de domaine pour ce service (sacrificial.arpa ?) mais personne ne l'a encore fait. Pour l'instant, la solution des serveurs maintenus par le client EPP (section 5.1.3.4) fait partie des trois solutions recommandées. Le client prudent doit bien verrouiller le domaine dans lequel ces serveurs sont nommés (enregistrement multi-années, verrouillage par le registre, etc).

On peut aussi renommer les serveurs de noms vers un nom non-existant dans un TLD existant. Ça s'est déjà vu mais il ne faut surtout pas faire cela : un attaquant pourrait enregistrer le nom et capter ainsi le trafic (.invalid n'a pas ce problème). Idem si le nom n'est pas sous votre contrôle. Un exemple est donné par le domaine lenvol.re : ses serveurs de noms étaient ns.hostin.io, ns.hostin.mu et ns.hostin.re. Lors de la suppression de hostin.re en octobre 2024, le dernier serveur de noms a été renommé host1.renamedbyregistry.com (et, en dépit du nom, pas par le registre). Ce domaine renamedbyregistry.com étant enregistré, et par un autre BE, on voit le risque.

%  whois lenvol.re
domain:                        lenvol.re
status:                        ACTIVE
…
nserver:                       host1.renamedbyregistry.com
nserver:                       ns.hostin.io
nserver:                       ns.hostin.mu
  

D'autres noms qui utilisaient ce même serveur ont également le problème :

% dig @d.nic.fr savanna.re. NS       
…
;; AUTHORITY SECTION:
savanna.re.		3600	IN	NS	host1.renamedbyregistry.com.
savanna.re.		3600	IN	NS	ns.hostin.mu.
savanna.re.		3600	IN	NS	ns.hostin.io.

;; Query time: 8 msec
;; SERVER: 2001:678:c::1#53(d.nic.fr) (UDP)
;; WHEN: Tue Jun 24 14:33:32 CEST 2025

En lecture supplémentaire, notre RFC recommande le rapport « SSAC 125 "Report on Registrar Nameserver Management" », ainsi que l'article « Risky BIZness: Risks Derived from Registrar Name Management ».

Ce livre parle de géopolitique de l'Internet. Banal, vous allez me dire, plein de livres ont déjà été écrits sur ce sujet. Mais celui-ci parle bien de l'Internet, pas des services qui tournent dessus, comme le font la très grande majorité des livres qui prétendent parler de l'Internet, mais ne connaissent que de ce qu'on voit sur l'écran. Ici, au contraire, c'est bien l'infrastructure, le cœur de l'Internet, qui est étudiée par les auteures.

Car l'infrastructure n'est pas neutre et les questions politiques liées à l'Internet ne concernent pas que les trois ou quatre réseaux sociaux centralisés étatsuniens que mentionnent la plupart des auteurs. Ce livre va donner de nombreux exemples, du choix et du déploiement d'IPv6 à la gestion des serveurs racine du DNS, en passant par la censure ou les demandes de blocage des réseaux russes suite à l'invasion de l'Ukraine, ainsi que des sujets très peu traités quand on parle de « gouvernance de l'Internet » comme la distribution d'adresses IP, avec l'exemple des attaques contre Afrinic. Mais pas d'Instagram (cité uniquement à propos d'un problème BGP) ou de Twitch.

De nombreux autres sujets d'infrastructure sont traités, montrant à chaque fois les conséquences politiques de choix que l'on pourrait croire plutôt techniques. Et ce sont aussi bien des sujets déjà largement décrits (la « guerre des protocoles » entre TCP/IP et OSI), que des sujets un peu plus rares comme la normalisation technique ou dont les conséquences politiques sont vraiment très peu discutées, comme la sécurisation de BGP ou les certificats (mais DANE n'est pas mentionné dans cette section, ce qui est dommage).

En prime, le livre est correct techniquement, ce qui n'est pas le cas de tous les textes parlant des aspects sociaux ou politiques de l'Internet, par exemple il ne reprend pas le cliché « les adresses IPv4 sont composées de quatre groupes de chiffres », expliquant même leur format binaire.

Par contre, je regrette que le livre ait un biais très étatsunien. Cela se voit dans des clichés comme parler de «  constitutional protections of free expression » (alors que le fameux premier amendement ne s'applique qu'à l'État, et qu'il laisse les entreprises privées s'attaquer à la liberté d'expression tant qu'elles veulent), dans une présentation peu critique de l'ICANN (création du gouvernement étatsunien et qui ne représente pas du tout la mythique « communauté Internet »), ou lorsque des termes juridiques étatsuniens sont utilisés sans être expliqués (sans être lecteur de Grisham, savez-vous ce qu'est un amicus curiae ?). De même, l'Internet Society est présentée en termes vraiment acritiques. Un autre exemple est la place excessive donnée à New IP, projet qui a été beaucoup plus mis en avant par les Étatsuniens, en termes chauvins (« Mon Dieu, les Chinois veulent faire un nouveau protocole »), que par les Chinois eux-mêmes (qui se sont contentés de quelques PowerPoint).

La préface de Fiona Alexander pose un autre problème : elle a été un des acteurs principaux du feuilleton de la « privatisation » de l'ICANN. D'un côté, c'est bien d'avoir comme auteure quelqu'un qui connait le dossier de l'intérieur. De l'autre, elle se donne le beau rôle et fait une présentation très unilatérale (le politicien de droite extrême Ted Cruz étant bien pratique comme repoussoir).

Bref, sur un sujet aussi complexe, il y a plusieurs points de vue, ce qui est logique en politique, donc n'hésitez pas à demander à votre institution de se procurer ce livre (très cher à l'achat, malheureusement ; on peut avoir toutes les conneries qu'on veut en ligne gratuitement mais l'information sérieuse est souvent payante).

(Au passage : j'ai reçu un exemplaire gratuit de l'ouvrage.)

Dans ce livre, William Blanc, avec Justine Breton et Jonathan Fruoco, poursuit son exploration des mythes nés de héros de fiction. Car, si Robin des Bois n'a probablement jamais existé, le mythe, lui, est bien réel, et a été repris par d'innombrables créateurs, bien différents.

Ce livre commence par creuser les racines du mythe. Au Moyen Âge, il était suffisamment connu pour que les premières mentions écrites du héros, au détour d'autres ouvrages, ne soient pas expliquées : tous les lecteurs connaissaient la référence, grâce à la tradition orale. Puis Robin des Bois a eu droit à ses propres livres et pièces de théâtre, après le Moyen Âge, et a commencé une carrière médiatique que le cinéma, au XXe siècle, a puissamment relancé. Je rappelle que ce livre ne porte pas sur le personnage historique (qui est sans doute imaginaire) mais sur sa reprise par les créateurs. C'est l'histoire du mythe, pas l'histoire de Robin.

Comme avec tous les mythes, Robin des Bois a été utilisé par de nombreux courants artistiques et politiques. Si le roi Arthur, sujet d'un précédent livre du même auteur, est plutôt « de droite » (après tout, c'est un roi), Robin des Bois, proscrit caché dans la forêt, qui affronte les autorités, serait plutôt « de gauche ». Mais attention, c'est bien plus compliqué que cela et les auteurices du livre montrent que Robin des Bois a été présenté de nombreuses façons différentes, et parfois en allié du roi, ou, au XXe siècle, en libertarien partisan des esclavagistes. De même, Robin a souvent changé de classe sociale, parfois yeoman (paysan propriétaire), parfois noble. Bien des bandits et des rebelles ont été qualifiés de « Robin des Bois moderne » (y compris les plus contestables).

Le livre analyse aussi un certain nombre de points spécifiques : le rôle des femmes dans la légende, Robin des Bois en France, les questions que se posent les médias pour enfants (présenter un voleur comme personnage positif…), l'importance du déguisement dans la légende (et, de manière plus générale, de l'inversion), bref, un livre d'une grande richesse où vous découvrirez plein de choses.

Le protocole ACME, normalisé dans le RFC 8555, permet d'automatiser le processus de création et de renouvellement de certificats utilisables, par exemple, pour TLS. L'extension normalisée dans ce nouveau RFC permet d'obtenir et de renouveler des certificats pour un service utilisant le .onion de Tor. Si vous voulez passer à la télévision en disant « j'ai obtenu un certificat pour le Dark Web », ce RFC est la bonne lecture.

Ces services en .onion sont décrits dans la spécification de Tor. Le nom .onion a été enregistré comme « nom spécial » (RFC 6761) par le RFC 7686. Ces noms en .onion ne sont pas résolvables via le DNS et on ne peut donc pas utiliser les défis ACME (RFC 8555, section 8) classiques avec une AC habituelle.

La norme ACME, le RFC 8555, définit dans sa section 9.7.7 des types d'identificateurs. Pour les .onion, ce sera le type dns, même si Tor n'utilise pas le DNS. J'aurais préféré que ce type se nomme domainname, ça aurait été plus cohérent (voir l'annexe A du RFC, qui discute ce choix, qui prend place dans un cadre très embrouillé, avec beaucoup de gens qui confondent noms de domaine et DNS). L'identificateur est le nom dans .onion, éventuellement avec des sous-domaines. Par exemple, le JSON envoyé par ACME, pour la version en .onion de ce blog, serait :

{
  "type": "dns",
  "value": "sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion"
}
  

Reste à permettre au serveur ACME (l'AC) de le valider. Le forum AC/Navigateur permet les .onion (annexe B.2 de ses « Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates »). ACME utilise le concept de défi pour ces validations. Le client ACME demande un certificat pour un certain identificateur, le serveur lui renvoie un défi, une tâche à accomplir, du genre « prouve-moi que tu peux mettre ces données que je t'envoie dans un endroit accessible en HTTP via le nom pour lequel tu veux un certificat ». Il existe plusieurs défis utilisables avec les .onion :

• http-01 (section 8.3 du RFC 8555), notre RFC dit qu'il faut suivre les redirections HTTP, même si elles mènent à un serveur HTTP qui n'est pas en .onion ; c'est ce défi que j'ai utilisé pour mon blog.
• tls-alpn-01 (RFC 8737).
• onion-csr-01, qui, contrairement aux deux précédents, est spécifique aux .onion et normalisé dans ce RFC 9799. C'est aussi le seul des trois défis utilisables qui permettre des jokers dans l'identificateur (*.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion). Je le décris en détail plus loin. Cette méthode de validation figure désormais dans le registre des types de défis.
• dns-01 (section 8.4 du RFC 8555), par contre, ne peut pas être utilisé pour les .onion, ceux-ci ne se servant pas du DNS.

Le défi onion-csr-01 consiste à demander au client de générer une CSR (RFC 2986) signée avec la clé privée du nom en .onion (je rappelle qu'un nom en .onion est une clé publique, plus exactement est dérivé d'une clé publique). Pour cela, le serveur ACME envoie un numnique et sa clé publique Ed25519, qu'il utilise pour Tor. Le client doit répondre avec le CSR, signé avec sa clé privée, CSR contenant parmi ses attributs le numnique choisi par le serveur, et un autre choisi par le client. Le serveur vérifie alors ce CSR (le nom en .onion, et bien sûr la signature).

Notez qu'on peut imaginer une AC qui ne soit elle-même accessible que via un nom en .onion, ce qui serait cohérent (section 5 du RFC). Par contre, en sortie, une AC doit utiliser Tor pour se connecter aux .onion (je veux dire l'utiliser directement, pas en passant par une passerelle, cf. section 8.8) mais une AC ne doit pas utiliser Tor pour se connecter à des domaines non-onion (section 8.4) car il y a des nœuds de sortie méchants.

Et les enregistrements de type CAA, normalisés dans le RFC 8659, et qui augmentent la sécurité du système en indiquant à quelles AC le client ACME a recours ? On ne peut pas utiliser le CAA traditionnel puisqu'il dépend du DNS. La solution, décrite dans la section 6 du RFC, est de mettre cette information dans le descripteur de service Tor (celui que le serveur en .onion envoie aux serveurs d'annuaire Tor).

Passons à la pratique. Il existe une AC expérimentale (et qui ne prétend pas offrir les garanties de sécurité d'une « vraie »), par l'auteure du RFC, documentée sur le site Web du projet. Je m'en suis servi pour obtenir un certificat pour mon blog. Vous pouvez donc désormais vous connecter en HTTPS, à https://sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/ (votre navigateur va sans doute râler car il ne connait pas cette AC). Attention, l'AC a enregistré ce certificat via Certificate Transparency (RFC 9162) et est donc publiquement visible. Ne demandez pas de certificat à une AC qui utilise Certificate Transparency si ça vous dérange (section 8.9 du RFC).

Quelle est la marche à suivre pour obtenir un tel certificat ? D'abord, configurer Tor pour accepter le port de HTTPS :

  
  HiddenServiceDir /var/lib/tor/blogv2/
  HiddenServicePort 80 127.0.0.1:80
  HiddenServicePort 443 127.0.0.1:443

Ensuite, configurer son serveur HTTP, Apache dans mon cas :

  
# Pour le client ACME (qui écoutera sur le port 8080) :
ProxyPass /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge
ProxyPassReverse /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge
ProxyPreserveHost on
# Ne pas oublier d'activer mod_proxy *et* mod_proxy_http.

# HTTPS :
<VirtualHost _default_:443>
   ServerName sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion

   # Liens symboliques vers les certificats obtenus par ACME, dans mon
   # cas /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/…
   SSLCertificateFile	/etc/apache2/server.pem
   SSLCertificateKeyFile /etc/apache2/server.key

On lance ensuite le client ACME. J'ai utilisé certbot :

% sudo certbot certonly -v --server https://acme.api.acmeforonions.org/directory \
             --standalone --http-01-port 8080 --http-01-address 127.0.0.1 \
             -d sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
…
Performing the following challenges:
http-01 challenge for sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
Waiting for verification...
Cleaning up challenges
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/privkey.pem
This certificate expires on 2025-05-28.
…

(Et pensez à configurer le renouvellement automatique du certificat, normalement, certbot l'a fait tout seul, mais vérifiez.)

Un tcpdump montre le trafic échangé entre Apache (qui a reçu le défi de l'AC, via Tor) et certbot (qui avait envoyé la demande et stocké le défi du serveur ACME), sur ma machine :

    
127.0.0.1.60978 > 127.0.0.1.8080: Flags [P.] … HTTP, length: 376
	GET /.well-known/acme-challenge/G4JwaWsRDG42H_FAESGCQrY7ZYk3D3mY9Ob_j458z6M HTTP/1.1
	Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	X-Forwarded-For: 127.0.0.1
	X-Forwarded-Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	X-Forwarded-Server: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion
	
127.0.0.1.8080 > 127.0.0.1.60978: Flags [P.] … HTTP, length: 92
	HTTP/1.0 200 OK
	Server: BaseHTTP/0.6 Python/3.11.2
	Date: Thu, 27 Feb 2025 17:04:53 GMT

  

Si vous voulez ajouter cette AC (mais rappelez-vous qu'elle est expérimentale et sans garanties de sécurité) au Tor Browser, vous devrez sans doute, dans about:config, configurer, avant d'importer l'AC :

security.nocertdb false
browser.privatebrowsing.autostart false
security.ssl.enable_ocsp_stapling false
  

Mais je répète mon avertissement : cela peut affecter votre vie privée. Ne le faites pas si vous ne comprenez pas en détail les conséquences.

J'ai utilisé le défi http-01, avec un certbot ordinaire. Le défi onion-01 nécessite un certbot modifié (du code est disponible).

Petite anecdote : l'auteure du RFC travaille pour l'AS 207960, dont l'objet RIPE annonce :

aut-num:        AS207960
as-name:        AS-TRANSRIGHTS
descr:          Trans Rights! Hell Yeah!

Et le site Web montre d'ailleurs le drapeau correspondant. Il est assez rare de voir des prises de position politiques dans la base des RIR.

Si vous utilisez Let's Encrypt (et tout le monde l'utilise, de nos jours), vous avez sans doute reçu les messages « Let's Encrypt Expiration Emails Update » qui vous préviennent que cette AC n'enverra plus de rappels que vos certificats vont bientôt expirer. C'est parce qu'un meilleur système est maintenant disponible, ARI (ACME Renewal Information). ARI permet à une AC utilisant le protocole ACME d'indiquer à ses clients des suggestions sur le renouvellement des certificats. Il est décrit dans ce RFC.

ACME est normalisé dans le RFC 8555 et est surtout connu via le succès de Let's Encrypt. Les certificats sont de courte durée (aujourd'hui trois mois mais ça va diminuer) et il faut donc les renouveler souvent. On peut le faire automatiquement via cron, ou bien analyser le certificat et renouveler quand sa date d'expiration approche. L'un des problèmes est que cela peut mener à ce que plusieurs demandes de renouvellement arrivent en même temps sur l'AC. Le pic d'activité qui en résulterait pourrait charger l'AC inutilement. L'idée est donc que ce soit le serveur ACME, l'AC, qui planifie les renouvellements, et pas le client ACME. Cela permettrait aussi des changements de planning, comme une réduction des durées de validité, ou bien une révocation.

Donc, ARI ajoute un nouvel URL à la description d'une AC, renewalInfo. Voici celui de Let's Encrypt (qui met en œuvre ARI depuis deux ans) :

% curl https://acme-v02.api.letsencrypt.org/directory
{
  "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change",
  "meta": {
    "caaIdentities": [
      "letsencrypt.org"
    ],
    "profiles": {
          …
    },
    "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf",
    …
  },
  "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct",
  "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce",
  "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order",
  "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo",
  "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
  

Ce nouveau membre a été ajouté au registre IANA.

Et comment on obtient quelque chose à cet URL https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo ? On doit passer un identificateur du certificat. Il est formé par la concaténation de l'identifiant de l'AC et du numéro de série du certificat (pour garantir qu'il soit unique). Je passe sur les détails de construction (lisez la section 4 du RFC pour cela) mais ce petit script Python ari-make-path.py vous fait le calcul. Utilisons-le sur l'actuel certificat de ce blog :

% openssl x509 -text -in cert.pem
[Notez les valeurs]

% python ari-make-path.py 93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2 00:06:7d:03:91:c6:49:b8:83:ba:e5:c6:da:8a:dc:be:4d:33:78
kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA

% curl -i https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo/kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA
…
retry-after: 21600
…
{
  "suggestedWindow": {
    "start": "2025-06-23T03:50:00Z",
    "end": "2025-06-24T23:00:50Z"
  }
}
  

Voilà, on a fait un URL en concaténant la valeur de renewalInfo avec celle obtenue à partir du certificat et on sait désormais quand est-ce que Let's Encrypt suggère de renouveler ce certificat. Le format de sortie est clair mais vous avez les détails dans la section 4.2. Les dates sont évidemment au format du RFC 3339. Au passage, la date d'expiration est le 24 juillet 2025 donc Let's Encrypt n'attend pas le dernier moment. (Comme le dit un commentaire dans le code source du serveur, « calculate a point 2/3rds of the way through the validity period (or halfway through, for short-lived certs) ».)

Le RFC précise qu'un membre explanationURL peut être ajouté mais Let's Encrypt ne le fait pas. Les membres possibles figurent dans un nouveau registre IANA, auquel on pourra ajouter de nouveaux membres, en fournissant une spécification (« Spécification nécessaire » du RFC 8126).

Et on utilise cet intervalle entre deux dates comment ? Le RFC recommande de choisir une date au hasard dans l'intervalle. Le client ACME ne doit pas dormir jusqu'à la date sélectionnée, il doit réessayer de temps en temps car l'AC a pu changer la date (c'est tout le principe d'ARI). Mais attention à respecter le Retry-After: (six heures, ici), cf. RFC 9110, section 10.2.3.

Notre RFC ajoute également un membre à la description d'une commande de certificat : replaces indique quel certificat on est censé remplacer. (En utilisant le même identificateur de certificat qu'indiqué plus haut.) Il a été ajouté au registre IANA.

ARI est mis en œuvre dans le serveur ACME de Let's Encrypt, Boulder. Regardez core/objects.go et notamment la fonction RenewalInfoSimple. Côté client, Lego, acmez et le CertMagic de Caddy ont ARI mais certbot ou dehydrated ne gèrent pas ARI. Si vous voulez vous y mettre, Let's Encrypt a écrit un guide d'intégration d'ARI.

Les API réseau, c'est très bien. Tout le monde en fait aujourd'hui, typiquement bâties au-dessus de HTTP. Mais il est parfois difficile de s'y retrouver parmi toutes les API. « Je suis sûr que l'INSEE avait une API pour faire ça mais où est-elle exactement et où est sa documentation ? La solution pour cela ? Les catalogues d'API, rassemblant nom, description, URL, etc, des API. Il ne reste plus qu'à trouver le catalogue… Ce RFC fournit pour cela un URL standard et un mécanisme de lien. Il fournit également un format standard pour écrire ce catalogue, bâti sur Linkset (RFC 9264, section 4.2).

Comme disait M. de la Palice, et comme le rappelle la section 1 du RFC, pour utiliser une API, il faut d'abord la découvrir. Cela veut dire apprendre son existence, quel va être l'URL à appeler (le endpoint), les paramètres à passer, quelles sont les conditions d'utilisation (gratuite ? nombre maximal de requêtes par jour ?), etc. Il existe des formats pour cela (le plus connu étant celui d'OpenAPI) mais il reste à trouver les fichiers de ce format. Pour faciliter cette tâche du développeur ou de la développeuse qui utilisera l'API, l'éditeur (publisher dans le RFC) qui publie l'API va fabriquer un joli catalogue, et le rendre lui-même découvrable. Un catalogue est une liste organisée des API offertes par une organisation donnée.

Première solution décrite par notre RFC (section 2) : un URL bien connu, et donc prévisible, https://www.example.net/.well-known/api-catalog (si l'éditeur est en www.example.net). Ces URL bien connus sont normalisés dans le RFC 8615. Évidemment, une redirection HTTP est possible. api-catalog a été ajouté au registre des URL bien connus.

Deuxième solution, un lien (section 3) api-catalog. Les liens, vous connaissez, et ils sont normalisés dans le RFC 8288. Ils peuvent se représenter de plusieurs façons, en HTML :

<!DOCTYPE HTML>
<html>
   <head>
         <title>Welcome to Example Publisher</title>
   </head>
   <body>
         <p>
          <a href="my_api_catalog.json" rel="api-catalog">
           Example Publisher's APIs
          </a>
         </p>
         <p>(remainder of content)</p>
   </body>
</html>

Ou bien en HTTP, dans la réponse :

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Location: /index.html
Link: </my_api_catalog.json>; rel=api-catalog
Content-Length: 356    

  

Désormais, api-catalog figure dans le registre des types de liens.

Cette norme concerne la découverte du catalogue, mais aussi la syntaxe de son contenu. La section 4 du RFC donne des indications sur le contenu du catalogue, sa sémantique (inclure la politique d'utilisation, lien vers une spécification formelle, etc) et sa syntaxe, le format Linkset du RFC 9264. Des exemples figurent dans l'annexe A du RFC mais vous pouvez aussi regarder le catalogue des mes API (en construction). Voici le premier exemple de catalogue donné dans le RFC, utilisant les relations du RFC 8631 :

{
    "linkset": [
    {
      "anchor": "https://developer.example.com/apis/foo_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/foo_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/foo_api/doc",
          "type": "text/html"
        }
      ],
      "service-meta": [
        {
          "href": "https://developer.example.com/apis/foo_api/policies",
          "type": "text/xml"
        }
      ]
    },
    {
      "anchor": "https://developer.example.com/apis/bar_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/bar_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/bar_api/doc",
          "type": "text/plain"
        }
      ]
    }
  ]
}
  

D'autres formats que Linkset sont possibles (mais Linkset doit être présent), par exemple via la négociation de contenu. Quelques formats possibles cités par le RFC :

• APIs.json,
• RESTDesc,
• HAL,
• WebAPI.

Ce catalogue peut, et ce serait souhaitable, être écrit automatiquement par le cadriciel qu'on utilise pour développer ses API.

Et, sinon, où est-ce qu'on publie cette API ? La méthode recommandée (section 5) est de la publier à plusieurs endroits. Si on gère www.example.net et que les URL des API sont en api.example.com, le RFC recommande de les publier aux deux endroits. Rappelez-vous que les redirections HTTP sont permises, donc vous pouvez n'avoir qu'un seul exemplaire du catalogue, ce qui simplifie sa maintenance. Car, puisqu'on parle de maintenance, un gros défi sera clairement de garder ce catalogue à jour au fur et à mesure de l'évolution des API… (La section 8, sur la sécurité, revient sur ce problème.)

Je n'ai pas trouvé d'exemple réel dans le Web, même chez Vodafone, où travaille l'auteur. Mais j'ai fait un catalogue pour mes propres API. En l'absence d'outils de test et de validation pour les catalogues, il a peut-être quelques erreurs. (Si vous lisez la section 2 du RFC, vous verrez que mon serveur HTTP ne répond pas aux requêtes HEAD avec un lien dans l'en-tête, un Link:. Il devrait.)

La cryptographie post-quantique vise à développer des algorithmes de cryptographie qui résistent à des ordinateurs quantiques. Mais ces algorithmes sont relativement récents et peuvent avoir des faiblesses, voire des failles, que la cryptanalyse classique pourra exploiter. La tendance actuelle est donc aux protocoles et formats hybrides, combinant algorithmes classiques et post-quantiques. Ce RFC spécifie la terminologie de ces protocoles hybrides.

On peut aussi dire AQ, pour après-quantique car le sigle anglophone PQ de post-quantum peut faire drôle en France. D'ailleurs, les termes à utiliser (post-quantique ? résistant au quantique ?) ont fait l'objet de chaudes discussions dans le groupe de travail IETF.

Le point de départ de tout le tintouin autour de l'après-quantique, c'est l'algorithme de Shor. Conçu pour les calculateurs quantiques, et donc inutilisable encore aujourd'hui, il permet de résoudre des problèmes mathématiques qu'on croyait difficiles, comme la décomposition en facteurs premiers (qui est derrière RSA) ou le logarithme discret (qui est derrière ECDSA). Le jour, qui n'est pas encore arrivé, où on aura des CRQC (Cryptographically-Relevant Quantum Computer, un calculateur quantique qui puisse s'attaquer à des problèmes de taille réelle, et pas juste faire des démonstrations), ce jour-là, la cryptographie classique, ou traditionnelle, aura un problème.

Les CRQC sont loin dans le futur, un lointain dont il est très difficile d'estimer la distance. Comme on ne sait pas quand les CRQC seront disponibles, et que certains secrets qu'on chiffre maintenant devront rester secrets pendant de nombreuses années, il est prudent de travailler dès maintenant aux algorithmes AQ, après-quantique, ceux pour lesquels on ne connait pas d'algorithme (quantique ou classique) pour les casser. Ce travail a effectivement commencé depuis des années et on a déjà des algorithmes AQ normalisés comme ML-KEM (ex-Kyber). Notez toutefois qu'aucune norme IETF n'a encore été publiée en intégrant ces algorithmes, mais le travail est en cours, entre autres au sein du groupe de travail pquip.

Mais remplacer complètement les algorithmes traditionnels par les algorithmes AQ n'est pas forcément satisfaisant. Au contraire de RSA et ECDSA, testés au feu depuis longtemps et qui ont toujours résisté, les algorithmes AQ peuvent sembler un peu jeunes. Que se passerait-il si un·e cryptanalyste cassait un de ces algorithmes ? Pour limiter les dégâts, on envisage d'utiliser des mécanismes hybrides, combinant cryptographie classique (pré-quantique) et après-quantique. Ainsi, un chiffrement hybride verrait le texte en clair chiffré par un mécanisme classique puis par un mécanisme après-quantique. Une signature hybride se ferait en mettant deux signatures et en vérifiant ensuite que les deux sont valides. Cette méthode « ceinture et bretelles » est utilisée par exemple dans le RFC 9370 ou dans les Internet-Drafts draft-ietf-tls-hybrid-design, draft-ietf-lamps-pq-composite-kem ou draft-ietf-lamps-cert-binding-for-multi-auth. On peut aussi consulter la FAQ du NIST (« A hybrid key-establishment mode is defined here to be a key establishment scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes. ») ou bien le document ETSI TS 103 744 nommé « Quantum-safe Hybrid Key Exchanges ». Attention toutefois avec cette terminologie car l'adjectif « hybride » est également souvent utilisé en cryptographie pour désigner la combinaison d'un algorithme de cryptographie asymétrique avec un algorithme de cryptographie symétrique (quand on crée une clé de session échangée via de la cryptographie asymétrique puis qu'on chiffre les données avec cette clé et de la cryptographie symétrique ; c'est ce que font TLS et OpenPGP, par exemple). C'est le sens qu'utilisent les RFC 4949 et RFC 9180, par exemple. Notre RFC 9794 note que ces deux usages du terme « hybride » vont certainement prêter à confusion mais qu'il n'y avait pas trop le choix : chaque usage était déjà solidement installé dans un milieu particulier. Essayer de promouvoir un autre terme pour la cryptographie après-quantique, comme « double algorithme » ou « multi algorithme » était sans doute voué à l'échec.

Passons maintenant aux définitions. Je ne vais pas les reprendre toutes mais donner quelques exemples. La section 2 du RFC commence par les mécanismes de base et d'abord, mécanisme hybride traditionnel / post-quantique (post-quantum traditional hybrid scheme, ou PQ/T), un mécanisme qui combine la cryptographie existante et celle du futur. On peut aussi simplifier en disant juste mécanisme hybride. Il y a aussi :

• Multi-algorithme, qui est plus large qu'hybride puisqu'il inclut les mécanismes ayant deux algorithmes traditionnels ou deux algorithmes après-quantique.
• Composé (composite), qui désigne les mécanismes hybrides où le mécanisme est exposé aux couches supérieures sous forme d'une interface unique (ce qui est évidemment plus simple et plus sûr pour le ou la programmeur·se).

Ensuite, on grimpe d'un niveau (section 3 du RFC), avec les éléments, qui sont les données en entrée ou en sortie d'un processus cryptographique. Quand on dit « l'algorithme X prend en entrée un texte en clair et une clé secrète et produit un texte chiffré », le texte en clair, la clé et le texte chiffré sont des éléments. Dans le mécanisme hybride décrit dans draft-ietf-tls-hybrid-design, il y a deux clés publiques, qui sont deux éléments. Un élément peut à son tour être composé de plusieurs éléments.

On peut maintenant utiliser tout cela pour faire des protocoles (section 4). Un protocole hybride PQ/T est, comme vous vous en doutez, un protocole qui utilise au moins deux algorithmes, un classique et un après-quantique. C'est ce qui est proposé dans draft-ietf-tls-hybrid-design. Ce dernier est même composé (dans le mécanisme de désignation de la clé, le KEM). Alors que le mécanisme du RFC 9370 est hybride mais pas composé (on fait un échange de clés classique et un KEM après-quantique).

Les noms des services de sécurité qu'on souhaite utiliser vont de soi (section 5) : confidentialité hybride PQ/T (confidentialité assurée par un mécanisme hybride traditionnel/après-quantique) et authentification hybride PQ/T.

Idem pour les certificats (section 6). Un « certificat hybride PQ/T » contient au moins deux clés publiques, une pour un algorithme traditionnel et une pour un algorithme après-quantique (alors que le certificat traditionnel et le certificat après-quantique ne contiennent qu'un seul type de clé publique, comme c'est le cas du certificat décrit dans draft-ietf-lamps-dilithium-certificates).

Et merci à Magali Bardet pour sa relecture mais, bien sûr, les erreurs sont de moi et moi seul.

Traditionnellement, les registres de noms de domaine publiaient toutes les informations des sous-domaines avec la même durée de vie maximale (TTL : Time To Live). Certain·es client·es demandent à pouvoir choisir un TTL plus court (ou, parfois, plus long) et ce RFC décrit comment faire cela avec le protocole EPP.

Cet EPP, normalisé dans les RFC 5730 et suivants, est aujourd'hui le plus utilisé par les gros registres pour recevoir les commandes de leurs BE. (Cf. cet article de l'Afnic.) Tel que normalisé dans le RFC 5731, EPP ne permet pas, lors de la création d'un nom de domaine, de spécifier le TTL des enregistrements NS (NameServer) qui seront publiés. Prenons l'exemple de l'enregistrement d'un .fr. Le ou la titulaire va sur l'interface Web de son BE, réserve le nom cyberstructure.fr, le BE transmet la demande de création en utilisant EPP et le registre publie ensuite dans le DNS les informations de délégation, ici récupérées avec dig :

% dig @d.nic.fr cyberstructure.fr NS    
…
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
…
;; AUTHORITY SECTION:
cyberstructure.fr.	3600 IN	NS puck.nether.net.
cyberstructure.fr.	3600 IN	NS fns2.42.pl.
cyberstructure.fr.	3600 IN	NS ns2.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns4.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns2.afraid.org.
cyberstructure.fr.	3600 IN	NS fns1.42.pl.
cyberstructure.fr.	3600 IN	NS ns1.bortzmeyer.org.
…
  

À aucun moment, la·e titulaire ou le BE n'a spécifié de TTL (les 3 600 secondes), il a été choisi par le registre seul. Certain·es titulaires peuvent pourtant avoir des préférences différentes. (Je rappelle que la notion de TTL est définie rigoureusement dans le RFC de terminologie DNS, le RFC 9499, voir sa section 5.)

Si vous voulez creuser ce concept de délégation, l'article de l'Afnic sur DELEG l'explique dans sa première partie.

L'exemple ci-dessus montrait les enregistrements NS (NameServer) mais ce problème concerne aussi les DS (RFC 9364), la colle et les éventuels DNAME (par exemple pour mettre en œuvre le RFC 6927).

Ce RFC normalise une extension à EPP pour permettre au client (le BE) d'indiquer le TTL souhaité pour la délégation. (Ce qui ne signifie pas que le registre satisfera ce souhait, lisez plus loin.) Plus précisément, il étend les classes (mappings) EPP pour les noms de domaine (RFC 5731) et pour les serveurs de noms (RFC 5732), les seules classes dont les données se retrouveront dans le DNS (rappelez-vous qu'EPP n'est pas limité aux noms de domaine, c'est un protocole d'avitaillement générique).

La section 1.2 du RFC contient les informations essentielles. D'abord, l'espace de noms urn:ietf:params:xml:ns:epp:ttl-1.0 (enregistré à l'IANA), qui identifie cette extension (le RFC utilise l'alias ttl mais rappelez-vous qu'en XML, c'est l'espace de noms qui compte, l'alias est choisi par l'auteur du document XML). Ensuite, l'élément <ttl:ttl> (donc, en complet, {urn:ietf:params:xml:ns:epp:ttl-1.0}ttl), qui peut être ajouté aux demandes EPP ou aux réponses. Parmi ses attributs :

• for (le seul qui soit obligatoire) indique le type de données DNS auxquelles l'élément s'applique (uniquement des types qui jouent un rôle dans la délégation, NS, DS, DNAME, A et AAAA, ainsi que la valeur spéciale custom, qu'il faut compléter avec un attribut custom qui suit l'expression rationnelle de la section 3.1 du RFC 6895, et évidemment utilise un type enregistré),
• min (uniquement dans les réponses) qui indique la valeur minimale que le serveur (donc le registre) accepte (le registre est toujours libre de sa politique et peut refuser une valeur trop basse ou trop haute, répondant avec le code d'erreur EPP 2004, Parameter value range error),
• max, la contrepartie de min, avec les mêmes propriétés,
• default, qu'on ne trouve également que dans les réponses, et qui permet de connaitre la valeur qu'utiliserait le serveur si le client ne demande rien de spécifique.

L'élément <ttl:ttl> a pour contenu une valeur en secondes. Si cette valeur est vide, le serveur prendra la valeur par défaut (mais autant ne pas mettre d'élément <ttl:ttl> dans ce cas).

L'extension de ce RFC décrit des possibilités mais le registre, qui gère le serveur EPP, reste libre de ne pas tout accepter. Par exemple, il peut refuser l'utilisation de l'attribut custom, ou bien la restreindre à certains types (et, si le client demande quand même, répondre avec le code d'erreur EPP 2306 Parameter value policy error). Les types qui ont une syntaxe privilégiée (pas besoin de l'attribut XML custom) sont ceux qu'on peut actuellement trouver au-dessus de la coupure de zone (section 7 du RFC 9499).

Vous avez noté que, dans les types qui ont une syntaxe privilégiée dans ce RFC, il y a les types pour les adresses IP. Ils sont utilisés pour la colle DNS (section 7 du RFC 9499), si le serveur EPP met en œuvre la classe EPP pour les serveurs de noms (RFC 5732).

Un deuxième élément XML est spécifié par ce RFC, <ttl:info>, qui sert à demander ou à indiquer des informations sur la politique du serveur (voir des exemples plus loin).

La section 2 décrit dans quelles commandes EPP on peut ajouter les nouveaux éléments. Je ne vais pas toutes les détailler, juste montrer quelques exemples du XML envoyé et des réponses. Ainsi, ici, le client va utiliser la commande <epp:info> pour se renseigner sur la politique du serveur :

…
   C:     <info>
   C:       <domain:info
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:       </domain:info>
   C:     </info>
   C:     <extension>
   C:       <ttl:info
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
   C:         policy="false"/>
   C:     </extension>
   …

  

Et la réponse du serveur :

…
   S:   <response>
   S:     <result code="1000">
   S:       <msg>Command completed successfully</msg>
   S:     </result>
   S:     <resData>
…
   S:         <domain:name>example.com</domain:name>
   S:         <domain:status s="ok"/>
…
   S:     </resData>
   S:     <extension>
   S:       <ttl:infData
   S:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   S:         <ttl:ttl for="NS">172800</ttl:ttl>
   S:         <ttl:ttl for="DS">300</ttl:ttl>
   S:       </ttl:infData>
…
   S:   </response>
…

  

Le serveur indique que le TTL des enregistrements NS sera de deux jours. Sinon, vous avez repéré le policy="false" ? S'il avait été à true, le serveur aurait renvoyé l'information sur sa politique pour tous les types d'enregistrements DNS (section 2.1.1.2).

Créons maintenant un nom de domaine en spécifiant un TTL :

   C:   <command>
   C:     <create>
   C:       <domain:create
   C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:         <domain:ns>
   C:           <domain:hostObj>ns1.example.com</domain:hostObj>
   C:           <domain:hostObj>ns1.example.net</domain:hostObj>
   C:         </domain:ns>
   C:       </domain:create>
   C:     </create>
   C:     <extension>
   C:       <ttl:create
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   C:         <ttl:ttl for="NS">172800</ttl:ttl>
   C:         <ttl:ttl for="DS">300</ttl:ttl>
   C:       </ttl:create>
   C:     </extension>
   C:   </command>
   C: </epp>

    

Cela marcherait aussi dans un <domain:update>, pour changer les TTL.

Je l'ai déjà dit plusieurs fois, la demande du client ne va pas forcément être honorée par le serveur. La section 3 de notre RFC détaille l'interaction entre cette demande et la politique du serveur (donc du registre). Ainsi, le serveur peut limiter les types d'enregistrement DNS auxquels ces commandes s'appliquent, par exemple en n'acceptant de changer le TTL que pour les DS (d'où l'intérêt des demandes avec policy=…, pour savoir à l'avance).

D'autre part, le TTL des enregistrements publiés peut changer en dehors d'EPP, par une action du registre. Auquel cas, le registre (section 4) peut gentiment prévenir ses clients par le système de messagerie du RFC 8590.

La possibilité pour le client d'indiquer un TTL souhaité a aussi des conséquences opérationnelle (section 5). Ainsi, des TTL courts vont accroitre la charge sur les serveurs faisant autorité puisque les résolveurs auront besoin de demander plus souvent, les expirations se rapprochant. Souvent, les utilisateurs veulent des TTL courts, pour la réactivité, et n'ont pas conscience des conséquences, notamment en terme d'accroissement du trafic, d'autant plus que l'utilisation des serveurs DNS faisant autorité est gratuite pour eux. C'est pour cela que le registre peut fixer des valeurs minimales (et maximales, pour traiter d'autres problèmes) aux TTL souhaités par le client.

Une erreur parfois commise est de penser qu'un changement du TTL (via une commande EPP <epp:update>) va se voir instantanément. Mais, en fait, les informations, avec l'ancien TTL, sont encore dans la mémoire de plusieurs résolveurs. Il est donc recommandé de planifier les changements à l'avance, en tenant compte de cette mémorisation (section 5.2 du RFC). D'ailleurs, la politique du registre aussi peut changer, et les TTL par défaut, ainsi que les valeurs maximales et minimales, sont susceptibles d'être modifiées (un registre sérieux va informer ses utilisateurices de ces changements mais parfois, c'est oublié).

Un gros morceau de notre RFC est consacré à la sécurité (section 6) car les TTL ont une influence sur ce sujet. Premièrement, le fast flux (changement rapide des données de délégation DNS, cf. RFC 9499, section 7). Des malveillants utilisent cette technique pour rendre l'investigation numérique plus difficile et pour échapper à certaines règles de filtrage (voir le rapport SAC-025 du SAAC). Un TTL court peut faciliter ce changement rapide. Le rapport du SAAC suggère un TTL minimum de 30 minutes et/ou de limiter le nombre de changements qu'on peut faire par jour.

Si un malveillant réussit à obtenir les secrets qui lui permettent de soumettre des demandes de modification (au passage, pensez à activer l'authentification à plusieurs facteurs), il mettra sans doute des TTL très élevés pour que son détournement dure plus longtemps. D'où l'intérêt d'une valeur maximale pour les TTL.

Notre extension à EPP pour les TTL figure désormais dans le registre IANA des extensions et sa syntaxe complète, si vous êtes curieux·se, figure dans la section 8 (au format des schémas XML). Question mises en œuvre, vous en trouverez au moins deux, dans le SDK de Verisign et dans le logiciel Pepper (plus exactement dans la bibliothèque qu'il utilise, Net::EPP).

C'est un passionnant livre d'histoire de la communication et des médias que le résultat de la recherche menée par l'auteur sur la rubrique « La clinique des rumeurs », publiée par le Boston Herald pendant la Deuxième Guerre mondiale. Ce premier essai de fact-checking, comme on ne disait pas encore à l'époque, posait déjà toutes les questions liées à la vérification des informations, et à l'attitude à avoir face à la propagande de l'adversaire.

Le contexte est rude : les États-Unis sont en guerre. On fait des recherches actives sur les meilleurs moyens de propagande (cf. le livre « Le cercle démocratique »). Le pays est divisé (les relais de la propagande nazie comme Lindbergh s'exprimaient encore librement il y a peu), le racisme est fort et limite l'enthousiasme de certains à combattre. La guerre est un terrain fertile pour la paranoïa. On voit des espions partout et certains estiment que l'Axe pourrait sérieusement affaiblir ses ennemis en lançant des rumeurs. Un groupe de gens a l'idée de créer une rubrique dans un journal peu connu, le Boston Herald, et la baptise Rumor clinic, opération qui aura un certain succès et suscitera des imitateurs. Chaque article suit le plan {exposition d'une rumeur, démenti officiel}. Par exemple, une rumeur dit que des milliers de cadavres de marins étatsuniens ont été retrouvé sur une plage de Long Island, victimes des sous-marins allemands. Une autre que le sang donné par les citoyens noirs pour les hôpitaux militaires faisait que, une fois donné à des soldats blancs blessés, les receveurs auraient des enfants noirs. L'auteur du livre a épluché les numéros du journal et retrace l'histoire de cette « clinique des rumeurs » et des innombrables débats qui ont accompagné cette expérience, avant que la « clinique » ne soit fermée, avant même la fin de la guerre, victime de ses propres défauts et de rivalités bureaucratiques entre services étatiques, certains soutenant le projet et d'autres le combattant.

Pascal Froissart n'est pas tendre avec la clinique des rumeurs (comparez avec l'article bien plus favorable de Wikipédia). Rumeurs non sourcées (peut-être même inventées par les journalistes ?), indifférence face au risque que citer une rumeur pourrait lui donner de l'importance, vérification des faits limitée à citer des autorités, souvent militaires (pas la source la plus fiable pendant une guerre !), zéro enquête journalistique, appels à la vigilance citoyenne, malgré le risque que cela tourne à la chasse aux sorcières (surtout quand on sait ce qui s'est produit après la guerre…), vision binaire des faits (il n'y a que le mensonge et la vérité et rien entre les deux), absence de recherche sérieuse sur le phénomène social de la rumeur (bien qu'un des plus ardents promoteurs du projet soit un chercheur en psychologie). Ces défauts sont d'ailleurs toujours d'actualité dans certains discours anti « fake news », qui considèrent que seule la parole officielle est valable et que la vérité est forcément binaire.

On croise dans ce livre de nombreux personnages fascinants, dont le rôle réel était souvent masqué par le brouillard de la propagande. Ainsi, je ne connaissais pas la journaliste et militante antiraciste Frances Sweeney dont l'auteur estime qu'elle n'a pas eu de rôle réel dans la clinique des rumeurs.

Je divulgâche : on ne sait pas réellement si ces rumeurs étaient organisées par l'Axe. La clinique des rumeurs donnait souvent dans le complotisme, affirmant que tout propagateur de rumeur était un agent ennemi, et cela s'étendait aux ouvrières dénonçant les profits des industries de l'armement. Mais cela n'a jamais été prouvé. De façon amusante, l'OSS a recruté un ancien de la clinique des rumeurs pour aller propager des rumeurs chez l'ennemi (avec un succès mitigé).

Une lecture passionnante et très utile, dans un monde où les guerres et les menaces de guerre servent souvent, comme d'habitude, à faire taire les voix dissidentes, et où le mensonge est largement propagé, aussi bien par le ridicule complotiste de comptoir que par le président des États-Unis.