Mon blog

Le préfixe IPv6 normalisé pour les documentations, 2001:db8::/32 était trop petit pour vous ? Vous aviez du mal à exprimer des architectures réseau complexes, avec beaucoup de préfixes ? Ne pleurez plus, un nouveau préfixe a été alloué, c'est désormais un /20, le 3fff::/20.

Ce RFC modifie légèrement le RFC 3849, qui normalisait ce préfixe de documentation. Le but d'un préfixe IP de documentation est d'éviter que les auteur·es de ces documentations ne prennent des adresses IP qui existent par ailleurs, au risque que des administrateurices réseaux maladroit·es ne copient ces adresses IP (songez au nombre d'articles qui parlent d'IPv4 en utilisant des exemples comme les adresses 1.1.1.1 ou 1.2.3.4, qui existent réellement). On doit donc utiliser les noms de domaine du RFC 2606, les adresses IPv4 du RFC 5737, et les numéros d'AS du RFC 5398. Pour IPv6, l'espace de documentation est désormais 3fff::/20 (l'ancien préfixe 2001:db8::/32 reste réservé et valable donc pas besoin de modifier les documentations existantes).

Cette nouvelle taille permet de documenter des réseaux réalistes, par exemple où deux /32 se parlent.

Si ce préfixe est désormais dans le registre des adresses spéciales, il ne semble pas (encore ?) décrit dans la base d'un RIR, contrairement à son prédécesseur.

Si vous êtes responsable d'une zone DNS, et que vous la testez régulièrement avec des outils comme Zonemaster ou DNSviz (ce que font tous les responsables sérieux), vous avez peut-être eu des avertissements comme quoi vos « paramètres NSEC3 » n'étaient pas ceux conseillés. C'est parce que les recommandations en ce sens ont changé avec ce RFC. Lisez-le donc si vous voulez comprendre les recommandations actuelles.

D'abord, un peu de contexte. Ce RFC concerne les zones qui sont signées avec DNSSEC et qui utilisent les enregistrements NSEC3 du RFC 5155. Aujourd'hui, par exemple, c'est le cas de .fr, .com mais aussi de bortzmeyer.org grâce à qui vous êtes arrivés sur cet article. Mais ce n'est pas le cas de la racine des noms de domaine, qui utilise NSEC (RFC 4035). Pour comprendre la dfifférence entre les deux, je vous renvoie à mon article sur le RFC 5155.

Un exemple où Zonemaster proteste, sur icann.org :

Ce RFC 5155 donnait des conseils de sécurité cryptographiques qui, avec le recul et l'expérience se sont avérés sous-optimaux. Ce nouveau RFC 9276 les modifie donc et suggère fortement de ne plus utiliser de sel, ni d'itérations successives, dans le calcul des condensats pour NSEC3.

Lorsqu'une zone est signée avec utilisation de NSEC3, elle comprend un enregistrement de type NSEC3PARAM qui indique quatre choses :

• L'algorithme de condensation utilisé (presque toujours SHA-1, aujourd'hui, c'est le seul normalisé). Il n'est pas discuté ici (voir le RFC 8624 sur le choix des algorithmes).
• Les options, notamment celle nommée opt-out et qui est un avantage souvent oublié de NSEC3 par rapport à NSEC : la possibilité de ne pas avoir un enregistrement NSEC3 par nom mais seulement par nom signé. C'est un peu moins sûr (les noms non signés, typiquement les délégations DNS, ne sont pas protégés) mais ça fait une grosse économie de mémoire pour les zones qui comprennent beaucoup de délégations non signées (et cela évite de passer trop de temps à modifier les chaines NSEC3 dans des zones qui changent souvent). C'est typiquement la cas des gros TLD et cela explique pourquoi .fr ou .com utilisent NSEC3, même s'il n'y a pas de problème avec l'énumération des noms (.fr distribue la liste). (Notez que si l'option est à 0 dans le NSEC3PARAM, cela ne signifie pas qu'il n'y a pas d'opt-out, celui-ci est typiquement indiqué uniquement dans les enregistrements NSEC3.)
• Le nombre d'itérations supplémentaires (RFC 5155, sections 3.1.3 et 4.1.3) faites lorsqu'on condense un nom.
• Le sel utilisé.

Voici par exemple l'enregistrement de icann.org en août 2024 :

% dig +short icann.org NSEC3PARAM
1 0 5 A4196F45E2097176
  

Utilisation de SHA-1 (le 1 est le code de SHA-1), pas d'opt-out (mais prudence, son utilisation n'est pas obligatoirement signalée dans les options, voir plus haut), cinq itérations supplémentaires (donc six au total) et un sel apparemment aléatoire, A4196F45E2097176.

La première recommandation du RFC concerne le nombre d'itérations. Comme le sel, le but est de rendre plus difficile l'utilisation de tables calculées à l'avance par un attaquant. Sans sel et avec une seule itération, un attaquant qui a à l'avance calculé tout un dictionnaire et sait donc que le condensat de foobar est 8843d7f92416211de9ebb963ff4ce28125932878 pourra donc facilement inverser le condensat dans un enregistrement NSEC3. C'est pour cela que le RFC 5155 recommandait un nombre variable d'itérations, indiqué par l'enregistrement NSEC3PARAM. Mais, en pratique, la protection contre l'énumération n'est pas si solide que ça. Bien des noms peuvent être devinés (www étant le plus évident mais il y a aussi les mots d'un dictionnaire de la langue), d'autant plus qu'on choisit en général un nom de domaine pour être simple et facilement mémorisable. Et que ces noms se retrouvent à plein d'endroits comme les journaux Certificate Transparency (RFC 9162). L'opinion d'aujourd'hui est que le jeu (la protection contre l'énumération) n'en vaut pas la chandelle (le coût de signature et de validation). Notez aussi une externalité négative : les résolveurs aussi devront effectuer ces itérations et sont donc concernés. Bon, en prime, les techniques modernes rendent la protection peu efficace de toute façon (cf. « GPU-Based NSEC3 Hash Breaking »). La recommandation du RFC est donc de ne pas avoir d'itérations supplémentaires, donc de mettre ce nombre à zéro.

Et la deuxième recommandation concerne le sel. Il y a dans NSEC3 un sel implicite, c'est le nom de domaine (RFC 5155, section 5). D'ailleurs, mon exemple de condensat de foobar était faux, puisque j'avais omis cette étape. Si on l'inclut, le sel supplémentaire indiqué dans l'enregistrement NSEC3PARAM perd de son intérêt. En outre, en pratique, on change rarement le sel (cela nécessite de modifier toute la chaine NSEC3) ce qui diminue la protection qu'il offre. La recommandation actuelle est donc de ne pas utiliser de sel (ce qui se note avec un tiret, pas avec une chaine vide).

Si on suit les recommandations du RFC, le NSEC3PARAM aura cette allure :

% dig +short fr NSEC3PARAM
1 0 0 -

  

Et un des NSEC3 sera du genre :

% dig nexistesurementpas.fr 
qu7kmgn3e….fr. 594 IN NSEC3 1 1 0 - (
                                QU7MMK1…
                                NS DS RRSIG )


  

Notez aussi que le RFC recommande (section 3), avant de réfléchir aux paramètres de NSEC3, de réfléchir à NSEC3 lui-même. Sur une grosse zone de délégation, changeant souvent, comme .fr, NSEC3 est tout à fait justifié en raison des avantages de l'opt-out. Mais sur la zone DNS typique d'une petite organisation, qui ne compte souvent que des noms prévisibles (l'apex, www et mail), NSEC3 peut avantageusement être remplacé par NSEC, qui consomme moins de ressources. (NSEC3, ou d'ailleurs les couvertures minimales du RFC 4470, peut, dans le pire des cas, faciliter certaines attaques par déni de service.)

Les recommandations précédentes s'appliquaient aux signeurs de zone (côté serveurs faisant autorité, donc). Mais la section 3 a aussi des recommandations pour les résolveurs : compte-tenu du coût que représente pour eux les itérations NSEC3, ils ont le droit d'imposer un maximum, et de le diminuer petit à petit. Ces résolveurs peuvent refuser de répondre (réponse SERVFAIL) ou bien traiter la zone come n'étant pas signée (cf. section 6). Un nouveau code d'erreur étendu (RFC 8914), le numéro 27, Unsupported NSEC3 iterations value, a été réservé pour qu'ils puissent informer leurs clients.

Revenons aux serveurs faisant autorité : le RFC précise aussi qu'un hébergeur DNS devrait informer clairement ses utilisateurs des paramètres NSEC3 qu'il accepte. Il ne faudrait pas qu'on choisisse N itérations et qu'on s'aperçoive au déploiement qu'un des secondaires n'accepte pas d'en faire autant.

Aujourd'hui, la grande majorité des zones utilisant NSEC3 est passée aux recommandations de ce RFC (comme par exemple .fr en 2022). Notons que .org a un sel mais pas d'itérations supplémentaires.

 % dig +short org NSEC3PARAM
1 0 0 332539EE7F95C32A
  

Si vous utilisez OpenDNSSEC pour automatiser les opérations DNSSEC sur vos zones, voici la configuration conforme au RFC que j'utilise :

<Denial>
        <NSEC3>
                <!-- <OptOut/> -->
                <Resalt>P100D</Resalt> 
                <Hash>
                        <Algorithm>1</Algorithm>
                        <Iterations>0</Iterations>
                        <Salt length="0"/>
                </Hash>
        </NSEC3>
</Denial>

  

Vous qui me lisez, vous êtes probablement un mammifère. Sans une météorite complaisante, vous seriez toujours un genre de petite souris qui n'a même pas inventé l'Internet et vous ne pourriez pas lire ce blog. Heureusement pour vous et malheureusement pour les dinosaures, la météorite a frappé, dégageant le terrain pour « le triomphe et le règne des mammifères », que raconte ce livre.

L'auteur avait justement écrit avant sur les dinosaures mais je n'ai pas lu ce précédent livre. Ici, il décrit en détail toute l'histoire de ces bestioles à poils et à mamelles dont nous faisons partie. C'est un livre de vulgarisation mais il faut s'accrocher quand même, l'auteur ne se contente pas d'images d'animaux mignons, il rentre bien dans les détails techniques, mais c'est très vivant, très bien écrit, une lecture recommandée si vous voulez vous tenir au courant du passé.

L'auteur ne parle pas que des bestioles, une part importante du livre est consacrée aux paléontologues, à leur parcours personnel et professionnel souvent surprenant, à leur travail et à leurs découvertes. (Vous y lirez, par exemple, une rencontre avec Zofia Kielan-Jaworowska.)

(J'ai lu la traduction en français, l'original en anglais avait été publié en 2022.)

Comme pour tous les protocoles de séparation de l'identificateur et du localisateur, le protocole LISP, normalisé dans le RFC 9300, doit faire face au problème de la correspondance (mapping) entre les deux informations. Comment trouver un localisateur, en ne connaissant que l'identificateur ? LISP n'a pas de solution unique et plusieurs protocoles de correspondance peuvent être utilisés. La stabilité du logiciel des routeurs imposait une interface stable avec le système de résolution des identificateurs en localisateurs. C'est ce que fournit notre RFC 9301, qui spécifie l'interface, vue du routeur, et qui ne devrait pas changer, même si de nouveaux systèmes de correspondance/résolution apparaissent. Ce RFC remplace le RFC 6833. L'interface change assez peu mais le texte est sérieusement réorganisé, et la spécification a désormais le statut de norme et plus simplement d'expérimentation.

LISP prévoit deux sortes de machines impliquées dans la résolution d'identificateurs (les EID, Endpoint ID) en localisateurs (les RLOC, Routing Locator). Ces deux machines sont les Map-Resolver et les Map-Server. Pour ceux qui connaissent le DNS, on peut dire que le Map-Server est à peu près l'équivalent du serveur faisant autorité et le Map-Resolver joue quasiment le même rôle que celui du résolveur. Toutefois, il ne faut pas pousser la comparaison trop loin, LISP a ses propres règles. Pour résumer en deux phrases, un routeur LISP d'entrée de tunnel (un ITR, Ingress Tunnel Router), ayant reçu un paquet à destination d'une machine dont il connait l'identificateur (l'EID), va interroger un Map-Resolver pour connaître le localisateur (le RLOC, auquel l'ITR enverra le paquet). Pour accomplir sa tâche, le Map-Resolver fera suivre les requêtes au Map-Server, qui la transmettra finalement au routeur de sortie du tunnel (l'ETR, Egress Tunnel Router), qui est la vraie source faisant autorité.

C'est entre le Map-Resolver et le Map-Server que se trouvent les détails du système de correspondance. Ils peuvent être connectés par ALT (RFC 6836), par CONS (RFC jamais publié), par NERD (RFC 6837), par DDT (RFC 8111) ou bien par tout autre système de résolution, existant ou encore à créer (ils ne peuvent pas être connectés avec simplement LISP, puisqu'on aurait alors un problème d'œuf et de poule, LISP ayant besoin de ALT qui aurait besoin de LISP… cf. section 8.1). Rappelez-vous que notre RFC 9301 ne décrit qu'une interface, celle des ITR et ETR avec les Map-Resolver et Map-Server. Il est donc relativement court.

Comme avec toute technique nouvelle, il est prudent d'apprendre le vocabulaire (section 3, puis section 4 pour un survol général du système). Il y a deux types d'acteurs, les Map-Server et les Map-Resolver que nous avons déjà vu, et trois types importants de messages, Map-Register (un ETR l'envoie au Map-Server pour indiquer les RLOC des EID dont il est responsable), Map-Request (un ITR l'envoie à un Map-Resolver pour obtenir les RLOC ; le Map-Resolver fait suivre jusqu'au Map-Server, puis à l'ETR) et enfin Map-Reply, la réponse au précédent. Notons que ces types de messages ont leur description complète (avec leur format) dans le RFC 9300. Notez aussi que Map-Resolver et Map-Server sont des fonctions, et que les deux peuvent être assurés par la même machine, qui serait à la fois Map-Resolver et Map-Server (dans le DNS, un tel mélange est déconseillé).

Schéma général du système de correspondance LISP :

La section 8 de notre RFC plonge dans les détails. Accrochez-vous. Voyons d'abord le premier routeur LISP que rencontrera le paquet. On le nomme ITR pour Ingress Tunnel Router. Les routeurs précédents traitaient l'adresse de destination du paquet comme une adresse IP ordinaire. L'ITR, lui, va la traiter comme un identificateur (EID pour Endpoint IDentification). L'EID n'est pas routable sur l'Internet. Il faut donc encapsuler le paquet en LISP pour l'envoyer dans le tunnel. La nouvelle adresse IP de destination est le localisateur (RLOC pour Routing LOCator). Pour trouver le localisateur, l'ITR va demander à un ou plusieurs Map-Resolver. Il a été configuré (typiquement, à la main) avec leurs adresses IP (qui doivent être des localisateurs, pour éviter un amusant problème d'œuf et de poule; notez que plusieurs Map-Resolver peuvent avoir la même adresse, grâce à l'anycast). L'ITR ne connait que le protocole de résolution, envoi d'une Map-Request et récupération d'une Map-Reply (en termes DNS, l'ITR est un stub resolver). L'ITR ne connait donc pas les protocoles utilisés en interne par le système de correspondance, il ne connait pas ALT (ou ses concurrents). Cette communication avec le Map-Resolver peut être testée et déboguée avec l'outil lig (RFC 6835).

La réponse du Map-Resolver ne sera pas forcément positive. L'ITR recevra peut-être une negative Map-Reply, envoyée en réponse si un Map-Resolver ne trouve pas de localisateur pour l'identificateur qu'on lui a passé. Cela veut dire que le site final n'utilise pas LISP, et qu'il faut alors router le paquet avec les méthodes habituelles d'IP. (Il n'est évidemment pas prévu que tout l'Internet passe à LISP du jour au lendemain, le routeur LISP doit donc aussi pouvoir joindre les sites non-LISP.)

Si la réponse est positive, l'ITR peut alors encapsuler le paquet et le transmettre. Comment le Map-Resolver a-t-il trouvé la réponse qu'il a envoyé ? Contrairement aux routeurs LISP comme l'ITR, le Map-Resolver et le Map-Server connaissent le système de correspondance utilisé (si c'est ALT, ils sont tous les deux routeurs ALT) et c'est celui-ci (non traité dans ce RFC) qu'ils utilisent pour savoir s'il y a une réponse et laquelle.

Et, à l'autre bout du tunnel, que s'était-il passé ? Le routeur de fin de tunnel (l'ETR, pour Egress Tunnel Router), avait été configuré par un administrateur réseaux avec une liste d'EID dont il est responsable. Pour que le reste du monde connaisse ces EID, il les publie auprès d'un Map-Server en envoyant à ce dernier des messages Map-Register. Pour d'évidentes raisons de sécurité, ces messages doivent être authentifiés (champ Authentication Data du message Map-Register, avec clés gérées à la main pour l'instant, avec SHA-256 au minimum), alors que les Map-Request ne l'étaient pas (la base de données consultée par les routeurs LISP est publique, pas besoin d'authentification pour la lire, seulement pour y écrire). Ces Map-Request sont renvoyés périodiquement (le RFC suggère toutes les minutes) pour que le Map-Server sache si l'information est toujours à jour. Ainsi, si un ETR est éteint, l'information obsolète dans les Map-Server disparaîtra en trois minutes maximum (des messages peuvent être perdus, le RFC demande donc de patienter un peu en cas de non-réception). Cela veut aussi dire que LISP ne convient pas forcément tel quel pour les situations où on exige une mobilité très rapide.

Notez que je ne décris pas tous les détails (comme la possibilité pour un ETR de demander un accusé de réception au Map-Server, chose que ce dernier ne fait pas par défaut), voyez le RFC si vous êtes curieux.

Arrivés là, nous avons un Map-Server qui connait les EID que gère l'ETR. Désormais, si ce Map-Server reçoit une demande Map-Request, il peut la faire suivre à l'ETR (si vous connaissez le DNS, vous avez vu que le Map-Register n'est pas tout à fait l'équivalent des mises à jour dynamiques du RFC 2136 : avec ces dernières, le serveur de noms qui a reçu la mise à jour répondra ensuite lui-même aux requêtes). Le Map-Server ne sert donc que de relais, il ne modifie pas la requête Map-Request, il la transmet telle quelle à l'ETR. Le rôle des Map-Resolver et des Map-Server est donc simplement de trouver l'ETR responsable et de lui faire suivre (sans utiliser l'encapsulation LISP) les requêtes, pas de répondre à sa place. Cela se fera peut-être dans le futur lorsque des mécanismes de cache seront ajoutés. Pour le moment, les Map-Resolver n'ont pas de cache, de mémoire (section 4), une grosse différence avec le DNS (section 1).

La section 9 fait le tour des questions de sécurité liées au service de résolution. Comme les requêtes sont faites avec le format de paquets de LISP, elles héritent des services de sécurité de LISP comme le nonce qui permet de limiter les risques d'usurpation ou comme la sécurité LISP du RFC 9303. Par contre, comme pour les protocoles utilisés dans l'Internet actuel, il n'y a pas de vraie protection contre les annonces faites à tort (un Map-Server qui annoncerait un EID qui n'est pas à lui). C'est un problème très proche de celui de la sécurité de BGP et qui utilisera peut-être le même genre de solutions.

Notez qu'en théorie, l'interface spécifiée dans ce RFC pourrait servir à d'autres protocoles que celui du RFC 9300, comme par exemple GRE (RFC 2890) ou VXLAN (RFC 7348). Mais, pour l'instant, ce n'est pas le cas.

Il y a apparemment trois mises en œuvre. Outre l'outil de débogage lig (RFC 6835), il y a celle de Cisco pour ses routeurs, mais je ne connais pas les autres, sans doute dans des Unix.

Et les changements depuis le précédent RFC ? Ils sont résumés dans la section 11 :

• Ajout du type de message Map-Notify-Ack, un accusé de réception,
• Plein de bits supplémentaires dans les en-têtes des messages,
• Dans les actions qu'un routeur peut prendre lorsqu'un paquet arrive, ajout de possibilités de rejet du paquet (section 5.4).

Cet ouvrage collectif rassemble les articles liés aux interventions lors d'un intéressant colloque sur la souveraineté numérique tenu à la fac de droit de Rennes en 2022.

(Curieusement, le livre ne mentionne apparemment pas du tout le colloque.)

Comme tous les ouvrages collectifs, personne ne sera d'accord avec tout. Personnellement, j'ai trouvé qu'il y avait une variété de positions qui permet de bien se rendre compte de la difficulté de cerner le concept de souveraineté numérique et ses conséquences. Je trouve quand même que plusieurs articles sont excessivement pro-État, considérant que l'État agit forcément dans l'intérêt des citoyens, que la loi de l'État est toujours parfaite et que le remède à tous les problèmes de l'Internet est davantage de lois formelles (rappelez-vous que ce colloque est organisé par des juristes). Heureusement, certaines interventions comme celle de Pauline Türk (« L'exercice des fonctions de l'État à l'ère numérique ») sont plus critiques vis-à-vis de cette conception.

Une section particulièrement riche et originale est celle consacrée aux différentes conceptions nationales de la souveraineté numérique. Elle permet d'échapper à une vision étroite de la souveraineté et essayant de se placer à la place des autres. Ainsi, Paul-Alain Zibi Fama (qui n'avait pas pu être présent au colloque) parle de la souveraineté numérique, vue d'Afrique, continent régulièrement oublié dans les débats sur l'Internet. L'idée est très bonne mais gâchée par des erreurs comme de parler de blockchain « chiffrée », alors que justement la chaîne de blocs repose sur la transparence, pas sur la confidentialité. D'autre part, il met l'accent sur le manque de cadre juridique en Afrique, comme si c'était le principal problème (encore un biais de juriste). J'ai par contre apprécié l'analyse détaillé de l'état actuel de dépendance de l'Afrique, et l'accent mis sur l'importance de l'éducation.

J'ai aussi noté l'article de Mathilde Velliet sur « La conception américaine [sic] de la souveraineté numérique » à propos de l'extrême hypocrisie de la position de Washington (aussi bien le gouvernement que les influenceurs) pour qui « souveraineté numérique » est un gros mot, uniquement utilisé pour critiquer les efforts d'indépendance technologique des autres pays, notamment l'Europe, alors que les nombreuses interventions de l'État pour aider les entreprises étatsuniennes, qui ont exactement les mêmes objectifs, ne sont jamais critiquées.

Mais lisez le reste du livre : vous y trouverez plein de choses, sur ce thème souvent abordé de manière simpliste dans les médias et les réseaux sociaux. (Oui, je sais, il est cher. Demandez à votre employeur.)

Des vidéos du colloque sont disponibles en ligne.

Traditionnellement, tous les résolveurs DNS fournissaient un service équivalent. Le client avait un résolveur configuré, soit statiquement, soit via DHCP, et ne se souciait pas vraiment du résolveur ainsi désigné, tous étaient pareils. Aujourd'hui, ce n'est plus vraiment le cas : les résolveurs fournissent des services très différents, par exemple en matière de chiffrement, ou de blocage de certains noms. Il est donc utile que le client puisse se renseigner sur son résolveur, ce que permet cette nouvelle technique, le type de données RESINFO, que le client va récupérer dans le DNS.

Voici une liste (non-limitative !) des caractéristiques d'un résolveur et qui peuvent être présentes ou pas :

• Chiffrement des requêtes, avec DoT, DoH ou DoQ.
• Blocage de certains noms, par exemple la publicité, ou le porno, ou bien les noms qui gênent le gouvernement, ou encore les noms des services qui osent enfreindre la propriété intellectuelle sacrée.
• Protection de la vie privée via la minimisation des requêtes (RFC 9156) et/ou l'absence de stockage de l'historique des requêtes.

Avant la solution de ce RFC, la seule manière pour le client DNS de savoir ce que son résolveur proposait était manuelle, en lisant des documentations (cf. par exemple celle de mon résolveur). Ce n'est pas pratique quand la configuration du résolveur est automatique ou semi-automatique, via DHCP, ou avec les solutions des RFC 9462 et RFC 9463.

Ce nouveau RFC propose donc un mécanisme qui permet au client de découvrir les caractéristiques d'un résolveur et de les analyser, avant de décider quel résolveur choisir. (Un point important est que ce RFC se veut neutre : il ne dit pas quelles sont les bonnes caractéristiques d'un résolveur, le client reçoit une information, il est libre de l'utiliser comme il veut.)

Place à la technique (section 3 du RFC) : un nouveau type de données DNS est défini, RESINFO (code 261). Son contenu est l'information recherchée, sous forme de couples clé=valeur. Le nom de domaine auquel il est rattaché est le nom du résolveur, récupéré par les méthodes des RFC 9462 et RFC 9463, ou manuellement configuré. Ce nom est désigné par le sigle ADN, pour Authentication Domain Name (RFC 9463, section 3.1.1). Si on a utilisé le nom spécial resolver.arpa (RFC 9462, section 4), on peut lui demander son RESINFO.

Le format du RESINFO (section 4 du RFC) est copié sur celui des enregistrements TXT. Chaque chaine de caractères suit le modèle clé=valeur du RFC 6763, section 6.3. Les clés inconnues doivent être ignorées, ce qui permettra dans le futur d'ajouter de nouvelles clés au registre des clés. Un exemple d'enregistrement RESINFO :

resolver IN RESINFO "qnamemin" "exterr=15,17" "infourl=https://resolver.example.com/guide"
  

Il indique (section 5, sur la signification des clés) que ce résolveur fait de la minimisation des requêtes (RFC 9156), et notez que cette clé n'a pas de valeur, c'est juste un booléen dont la présence indique la QNAME minimisation. L'enregistrement continue en donnant les codes EDE (Extended DNS Errors, RFC 8914) que peut renvoyer le résolveur. C'est surtout utile pour indiquer ce qu'il bloque (15 = bloqué par décision de l'administrateurice du résolveur, 17 = bloqué par demande de l'utilisateurice). Et enfin il donne un URL où on peut aller chercher davantage d'information en langue naturelle.

La section 7 du RFC donne quelques conseils de sécurité : avoir un lien sécurisé avec le résolveur qu'on interroge (par exemple avec DoT), pour éviter qu'un méchant ne modifie le RESINFO, et valider la réponse avec DNSSEC (sauf pour resolver.arpa, qui est un cas spécial).

La section 8 précise le registre des clés disponibles. Pour ajouter des clés (on note qu'à l'heure actuelle, il n'y en a pas pour indiquer la disponibilité de DoT ou DoH, ou pour la politique de conservation des requêtes), la procédure est « spécification nécessaire » (RFC 8126). Si on veut des clés non normalisées, on doit les préfixer par temp-.

RESINFO est récent et donc pas forcément mis en œuvre dans tous les logiciels DNS que vous utilisez. Un dig récent fonctionne :

% dig dot.bortzmeyer.fr RESINFO
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34836
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
dot.bortzmeyer.fr.	86369	IN	CNAME	radia.bortzmeyer.org.
radia.bortzmeyer.org.	86369	IN	RESINFO	"qnamemin" "infourl=https://doh.bortzmeyer.fr/policy"

;; Query time: 0 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (UDP)
;; WHEN: Sun Aug 18 08:15:55 UTC 2024
;; MSG SIZE  rcvd: 142

Si vous avez un dig plus ancien, il faudra demander TYPE261 et pas RESINFO. Notez que, physiquement, un RESINFO est juste un TXT, ce qui facilite sa mise en œuvre (dans le futur dnspython, la classe RESINFO hérite simplement de TXT).

Trouve-t-on beaucoup de RESINFO dans la nature ? Aucun des grands résolveurs DNS publics ne semble en avoir. Mais, comme vous le voyez plus haut, j'en ai mis un dans mon résolveur. Le logiciel du serveur primaire ne connaissant pas encore ce type, j'ai utilisé la technique des types inconnus du RFC 3597 :

; Pour le résolveur public :
; Type RESINFO (RFC 9606), enregistré à l'IANA mais pas encore connu des logiciels
radia IN TYPE261 \# 50 08716e616d656d696e 28696e666f75726c3d68747470733a2f2f646f682e626f72747a6d657965722e66722f706f6c696379
  

Cette série de chiffres hexadécimaux ayant été produite à partir de la version texte et du programme text-to-unknown-txt-type.py. On note que, comme ce résolveur public n'est pas menteur, je n'indique pas d'EDE (Extended DNS Errors, RFC 8914).

Ce RFC ajoute au format de données binaire CBOR la possibilité de stocker des données temporelles plus détaillées, incluant par exemple l'échelle utilisée (UTC ou TAI), ou bien ayant une précision supérieure.

Petit rappel : CBOR est normalisé dans le RFC 8949, il incluait deux étiquettes pour les données temporelles, permettant d'indiquer date et heure en format lisible par un humain, et sous forme d'un nombre de secondes depuis l'epoch, avec une résolution d'une seconde. Le RFC 8943 y ajoute les dates (sans indication de l'heure). Au passage, le concept d'étiquette en CBOR est normalisé dans la section 3.4 du RFC 8949.

Notre nouveau RFC 9581 ajoute :

• Une étiquette, 1001, pour un temps étendu, sous forme d'un dictionnaire CBOR. La clé 1 doit être présente, pour indiquer le temps de base, des clés négatives servent pour indiquer des fractions de seconde, la clé -1 sert pour l'échelle (UTC ou TAI, notamment).
• Une étiquette, 1002, pour indiquer une durée. C'est également un dictionnaire CBOR.
• Une étiquette, 1003, pour indiquer une période, représentée par une date de début et une date de fin.

Ces nouvelles étiquettes ont été ajoutées au registre des étiquettes CBOR. Les clés possibles pour les dictionnaires indiquant les temps étendus sont dans un nouveau registre à l'IANA. Ajouter une entrée à ce registre nécessite un RFC et un examen par un expert.

Un service sur ce blog, https://www.bortzmeyer.org/apps/date-in-cbor permet d'obtenir plusieurs valeurs utilisant ces formats. Si nous utilisons le gem Ruby cbor-diag, nous voyons :

% curl -s https://www.bortzmeyer.org/apps/date-in-cbor | cbor2diag.rb  
["Current date in CBOR, done with Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] and the flunn library <https://github.com/funny-falcon/flunn>", 
  0("2024-04-17T14:21:07Z"), 
  1(1713363667), 
  100(19830), 
  1004("2024-04-17"), 
  1001({1: 1713363667, -1: 0, -9: 193986759}), 
  1001({1: 1713363704, -1: 1}), 
  "Duration since boot: ", 
  1002({1: 1742903})]

On voit alors successivement :

• Les deux valeurs étiquetées 0 et 1 du RFC 8949 et les deux valeurs étiquetées 100 et 1004 du RFC 8943.
• Puis les nouveautés de notre RFC.
• D'abord, un temps étendu étiqueté 1001. Le dictionnaire a trois éléments, celui de clé 1 est la date et heure, celui de clé -1 indique qu'il s'agit d'un temps UTC, celui de clé -9 indique qu'il s'agit de nanosecondes (-3 : millisecondes, -6 : microsecondes, etc). On a ainsi une meilleure résolution.
• Un autre temps étendu est en TAI (la clé -1 a la valeur 1) et vous voyez qu'il est situé 37 secondes dans le futur (l'actuel décalage entre UTC et TAI).
• Une durée, qui est le temps écoulé (en secondes) depuis le démarrage de la machine.
• On n'indique pas des informations comme la qualité de l'horloge car, franchement, je n'ai pas vraiment compris comment elle était représentée.

Question programmation, le service a été écrit en Python. Ce langage a une fonction time_ns, qui permet d'obtenir les nanosecondes. Pour le TAI, cela a été un peu plus difficile, la machine doit être configurée spécialement.

« Quand le numérique devient patrimoine » est le sous-titre de ce livre consacré à un tour d'horizon complet de la question de la gestion patrimoniale des documents numériques. L'auteure s'appuie notamment sur son importance expérience à la BnF. Aucune nostalgie du papier dans ce livre tourné vers l'avenir.

Le patrimoine, pour une bibliothèque du début du XXe siècle, c'était facile à définir. C'étaient des objets physiques, notamment des livres, qu'il fallait cataloguer, stocker, préserver du feu ou de l'eau, et mettre à la disposition des lecteurices. Mais le numérique a bouleversé le travail des bibliothèques. Il faut récolter et stocker ces « objets » numériques, les préserver des changements technologiques qui risquent de les rendre illisibles, les cataloguer, les mettre à disposition. Leur nombre, à lui seul, pose un sacré défi. Et la définition même d'objet est difficile. Par exemple, archiver cet article que vous êtes en train de lire, c'est quoi ? Archiver le code HTML (c'est assez loin du vécu de la lectrice ou du lecteur de ce blog) ? L'image que montre le navigateur (non structurée et difficile à analyser, par exemple à des fins de cataloguage) ? Et si je modifie cet article, faut-il garder toutes les versions, même quand je n'ai changé qu'une virgule ? Emmanuelle Bermès, l'auteure du fameux Figoblog, expose toutes ces questions et les choix à faire.

Si on a pu s'agacer au début du « retard à l'allumage » de certains institutions, notamment en France, face au numérique, si on a pu ricaner des déclarations enflammées d'intellectuels médiatiques proclamant, par exemple, qu'on ne pouvait pas ressentir d'émotion en lisant sur écran, cela fait quand même longtemps que les bibliothèques nationales, spécialistes de la conservation à très long terme de toute sorte de documents, ont pris à bras-le-corps la question du patrimoine numérique. C'est cette prise de conscience, ces débats, et les actions qui ont suivi, que raconte Emmanuelle Bermès dans ce passionnant livre. Si vous vous souvenez de la diatribe de Jean-Noël Jeanneney dans Le Monde contre le projet de numérisation des livres par Google, vous retrouverez avec intérêt les débats de l'époque. Et, si vous ne les avez pas vécu, vous aurez un excellent résumé des étapes par lesquelles la BnF est passée (par exemple au sujet de Gallica ou du dépôt légal). L'actuelle BnF est assez loin de certains projets qui avaient été conçus à l'époque du Minitel !

Bref, contrairement à ce qu'on lit parfois sous le clavier de gens qui ne se sont pas renseignés, le patrimoine numérique existe, et de nombreuses personnes travaillent à le gérer et à le préserver. C'est bien sûr le cas de l'excellent service Internet Archive (l'auteure mentionne les attaques d'éditeurs comme Hachette contre ce service). Mais c'est aussi le cas du dépôt légal en France et dans de nombreux autres pays. En parlant de dépôt légal, ce blog est archivé de longue date par la BnF, et on voit ici dans le journal du serveur HTTP, une des visites du ramasseur de la BnF :

194.199.7.22:10401 - - [03/Jul/2024:14:36:57 +0000] "GET /opendns-quitte-france.html HTTP/1.0" 200 18036 \
      "https://next.ink/wp-json/wp/v2/posts/142507" \
      "Mozilla/5.0 (compatible; bnf.fr_bot; +https://www.bnf.fr/fr/capture-de-votre-site-web-par-le-robot-de-la-bnf)" \
      www.bortzmeyer.org TLS
  

On notera le suivi des liens (à partir d'un article de Next), et le fait que le ramasseur se présente, et indique où obtenir tous les détails sur l'activité du robot. Bref, toutes les bêtises que je peux écrire ici sont archivées, sinon pour l'éternité, du moins pour longtemps. (Après tout, les historiens actuels sont ravis quand ils trouvent une tablette sumérienne avec une liste de commissions à faire.)

L'auteure se penche également sur les émotions que suscite le patrimoine (avec hommage à Aaron Swartz) et sur les techniques futures. L'IA aidera t-elle à cataloguer tous les documents sauvegardés ? Pas tant qu'un logiciel classera un tableau comme « femme ayant un bébé dans les bras » (exact, mais sans intérêt) au lieu de « Vierge à l'enfant »…

Le logiciel PGP est synonyme de cryptographie pour beaucoup de gens. Un des plus anciens et des plus utilisés pour les fonctions de confidentialité mais aussi d'authentification. Le format de PGP, OpenPGP, est normalisé dans ce RFC, qui remplace le RFC 4880 (il n'y a pas de changement crucial, juste une mise à jour longtemps attendue).

PGP a vu son format de données normalisé pour la première fois en août 1996, dans le RFC 1991. Cette norme a été révisée par la suite, dans le RFC 2440, puis le RFC 4880, puis par des RFC ponctuels (comme les RFC 5581 et RFC 6637, désormais inclus) et notre RFC est la dernière version, qui synthétise tout. Sa gestation a été longue et douloureuse et a suscité des controverses, menant à un projet concurrent, LibrePGP (qui prévoit son propre RFC, actuellement draft-koch-librepgp, que j'avoue n'avoir pas lu).

Cette normalisation permet à diverses mises en œuvre de PGP d'interopérer. La plus connue aujourd'hui est la seule libre, GNU Privacy Guard (qui n'existait pas encore au moment de la publication du premier RFC). Il ne faut donc pas confondre le logiciel PGP, écrit à l'origine par Phil Zimmermann, et qui est non-libre, avec le format OpenPGP que décrit notre RFC (cf. section 1.1) et que des logiciels autres que PGP peuvent lire et écrire.

Le principe du chiffrement avec PGP est simple. Une clé de session (le terme est impropre puisqu'il n'y a pas de session au sens de TLS mais c'est celui utilisé par le RFC) est créée pour chaque destinataire, elle sert à chiffrer le message et cette clé est chiffrée avec la clé publique du destinataire (section 2.1 du RFC).

Pour l'authentification, c'est aussi simple conceptuellement. Le message est condensé et le condensé est chiffré avec la clé privée de l'émetteur (section 2.2 du RFC).

Le format OpenPGP permet également la compression (qui améliore la sécurité en supprimant les redondances) et l'encodage en Base64 (RFC 4648), baptisé ASCII armor, pour passer à travers des logiciels qui n'aiment pas le binaire (la section 6 détaille cet encodage).

La section 3 explique les éléments de base utilisés par le format PGP. L'un des plus importants est le concept d'entier de grande précision (MPI pour Multi-Precision Integers), qui permet de représenter des entiers de très grande taille, indispensables à la cryptographie, sous forme d'un doublet longueur + valeur.

Enfin les sections 4 et 5 expliquent le format lui-même. Un message PGP est constitué de paquets (rien à voir avec les paquets réseau). Chaque paquet a un type, une longueur et un contenu. Par exemple, un paquet de type 1 est une clé de session chiffrée, un paquet de type 2 une signature, un paquet de type 9 du contenu chiffré, etc.

La section 7 du RFC décrit un type de message un peu particulier, qui n'obéit pas à la syntaxe ci-dessus, les messages en clair mais signés. Ces messages ont l'avantage de pouvoir être lus sans avoir de logiciel PGP. Ils nécessitent donc des règles spéciales.

On notera que gpg permet d'afficher les paquets présents dans un message PGP, ce qui est pratique pour l'apprentissage ou le débogage. Voyons un exemple avec un fichier test.txt de 17 octets, signé mais non chiffré (j'ai un peu simplifié la sortie du logiciel) :

% gpg --list-packets test.gpg 
:compressed packet: algo=2
:onepass_sig packet: keyid 3FA836C996A4A254
	version 3, sigclass 0x00, digest 10, pubkey 1, last=1
:literal data packet:
	mode b (62), created 1721800388, name="test.txt",
	raw data: 17 bytes
:signature packet: algo 1, keyid 3FA836C996A4A254
	version 4, created 1721800388, md5len 0, sigclass 0x00
	digest algo 10, begin of digest 2b d9
	hashed subpkt 33 len 21 (issuer fpr v4 C760CAFC6387B0E8886C823B3FA836C996A4A254)
	hashed subpkt 2 len 4 (sig created 2024-07-24)
	subpkt 16 len 8 (issuer key ID 3FA836C996A4A254)
	data: [4096 bits]

Malheureusement, gpg n'affiche pas les valeurs numériques des types, telles que listées par le RFC. Mais les noms qu'il utilise sont les mêmes que dans le RFC, on peut donc facilement trouver la section qui explique ce qu'est un "onepass_sig packet" (section 5.4).

Avec un message chiffré, on obtient :

% gpg --list-packets test.txt.gpg
gpg: encrypted with 4096-bit RSA key, ID 9045E02757F02AA1, created 2014-02-09
      "Stéphane Bortzmeyer (Main key) <stephane@bortzmeyer.org>"
gpg: encrypted with 2048-bit RSA key, ID 516CB37B336525BB, created 2009-12-15
      "ISC Security Officer <security-officer@isc.org>"
gpg: decryption failed: No secret key
:pubkey enc packet: version 3, algo 1, keyid 516CB37B336525BB
	data: [2046 bits]
:pubkey enc packet: version 3, algo 1, keyid 9045E02757F02AA1
	data: [4096 bits]
:encrypted data packet:
	length: 78
	mdc_method: 2

Conformément au principe d'agilité cryptographique (RFC 7696), le format OpenPGP n'est pas lié à un algorithme cryptographique particulier, et permet d'en ajouter de nouveaux. La section 15 détaille comment demander à l'IANA d'ajouter de nouveaux paramètres dans les registres PGP.

L'annexe B, quant à elle, énumère les principaux changements depuis le RFC 4880. Ce dernier RFC a été publié il y a plus de seize ans mais son remplacement par notre nouveau RFC 9580 a été une opération longue et difficile, et les changements se sont accumulés (Daniel Huigens en a fait un bon résumé). Ceci dit, le format OpenPGP ne change pas radicalement, et l'interopérabilité avec les anciens programmes est maintenue. Parmi les principales modifications :

• des nouveaux algorithmes cryptographiques de signature comme Ed25519, ou bien ECDSA avec les courbes Brainpool (RFC 5639),
• des nouveaux algorithmes cryptographiques de chiffrement, comme X25519 ; comme pour ceux de signature, ils étaient parfois mentionnés dans le RFC 4880 sans que leur utilisation dans OpenPGP soit complètement spécifiée, et parfois avaient été intégrés via un RFC spécifique, comme le RFC 6637, sur certains algorithmes à courbe elliptique,
• des nouveaux modes pour le chiffrement intègre, comme GCM (nouveaux pour OpenPGP, mais anciens en cryptographie),
• des nouvelles fonctions de dérivation de clé comme Argon2 (RFC 9106) ou de condensation comme SHA-3,
• au contraire, certains algorithmes sont désormais marqués comme dépassés et ne devant plus être utilisés pour de nouveaux messages ; c'est le cas de DSA, ElGamal, MD5, SHA-1… (rappelez-vous que PGP peut avoir à lire des messages anciens et qu'on ne peut donc pas retirer purement et simplement ces algorithmes, d'autant plus qu'autrefois ils étaient parfois les seuls obligatoires pour une mise en œuvre standard d'OpenPGP),
• nouvelle version (version 6) pour plusieurs types de paquets,
• réduction de l'en-tête de la protection ASCII des messages (OpenPGP est du binaire mais peut être transcrit en ASCII armor, par exemple pour le courrier électronique) ; vous ne verrez plus le « Version: » dans cet en-tête,
• redressement de la terminologie, qui était parfois trop floue.

Enfin, un grand nombre d'errata ont été traités (la liste complète est dans l'annexe D).

Des Martiens sont venus au Sahara pour se faire dessiner sur des parois rocheuses, tout le monde sait cela. Et des squelettes de géants ont été trouvés en Arabie saoudite, confirmant le Coran. De l'autre côté du globe, des astronautes extra-terrestres chassaient le dinosaure avec des haches au Pérou, en prenant le temps de construire des monuments, les peuples indigènes étant jugés incapables d'avoir réalisé de telles constructions. Vous y croyez ? Alors, c'est peut-être une bonne idée de lire ce livre, recueil d'articles sur les plus beaux mensonges et illusions en archéologie.

Il s'agit d'une réédition de l'ouvrage, avec mise à jour (lorsque l'auteur parle du scientifique-génial-qui-trouve-tout-seul-le-remède-mais-les-méchants-ne-veulent-pas-en-entendre-parler, les exemples du sida et du cancer ont été rejoints par la covid …). Il signale aussi le récent et scandaleux « documentaire » Netflix « À l'aube de notre histoire », que Netflix ose présenter comme un vrai documentaire alors qu'il s'agit du délire complotiste et raciste d'un menteur connu (la moitié du documentaire, que j'ai regardé, est faite de scènes où ce menteur se met en scène sur des sites archéologiques, alors qu'il n'a fait aucune recherche et rien découvert). La « thèse » de l'escroc est que tous les monuments antiques du monde ont été construits par une civilisation avancée et disparue. Si le documentaire reste prudent sur cette civilisation, dans ses livres, l'escroc n'hésite pas à dire qu'il s'agissait de Blancs, et insiste que ces monuments n'ont pas pu être construits par les indigènes. (Netflix a fait d'autres « documentaires » mensongers et complotistes comme celui sur le MH370.)

J'avais découvert Le Quellec avec son excellent livre détaillant la façon dont ignorance et racisme s'étaient conjugués pour produire une analyse erronée de la Dame Blanche (livre très recommandé !). Ici, il donne de nombreux autres exemples.

Il y a des escroqueries délibérées, faites pour des raisons monétaires ou politiques. Mais il y a aussi de nombreux cas où on se demande si le découvreur n'était pas sincère, s'auto-illusionnant, à la fois par manque de connaissances scientifiques et par désir d'arriver à tout prix au résultat voulu (confirmer ses préjugés, par exemple). On retrouvera donc dans ce livre les crânes de cristal, les pierres d'Ica, le livre de Mormon ou les interprétations délirantes sur les bâtisseurs de tertres (ces bâtisseurs sont bien réels, mais ils ne sont ni atlantes, ni extra-terrestres). Mais on n'aura pas les momies tridactyles, on ne peut pas tout traiter. Chaque cas est analysé en détail, son histoire, le contexte, le rôle des différentes personnes impliquées, chacune abordant la question avec son passé et ses préjugés.

Bref, un livre à lire pour creuser la variété des tromperies, mensonges, et dérapages. Je suis quand même un peu triste de découvrir qu'il y a peu d'innovation dans le pipeautage, les faux archéologues reprennent très souvent des légendes qui avaient déjà été analysées et démenties au XIXe siècle…

Dans un message DNS, il y a quatre sections qui peuvent prendre un nombre variable d'enregistrements (resource records). Chaque section est précédée d'un chiffre qui indique ce nombre d'enregistrements. L'une de ces sections indique la question posée. Est-ce que cela a un sens de mettre plusieurs questions dans un message ? Non, répond, ce très court RFC, qui clarifie le RFC 1035 sur ce point.

Regardons une requête DNS avec tshark :

% tshark -V -r  dns.pcap
…
Domain Name System (query)
    Transaction ID: 0x0dfd
    Flags: 0x0120 Standard query
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
…
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 1
    Queries
        wylag.de: type A, class IN
            Name: wylag.de
            [Name Length: 8]
            [Label Count: 2]
            Type: A (Host Address) (1)
            Class: IN (0x0001)
    Additional records
        <Root>: type OPT
            Name: <Root>
            Type: OPT (41)
            UDP payload size: 4096
            Higher bits in extended RCODE: 0x00
            EDNS0 version: 0
            Z: 0x8000
                1... .... .... .... = DO bit: Accepts DNSSEC security RRs
                .000 0000 0000 0000 = Reserved: 0x0000
            Data length: 12
            Option: COOKIE
                Option Code: COOKIE (10)
                Option Length: 8
                Option Data: 93c545f2aaf3f12c
                Client Cookie: 93c545f2aaf3f12c
                Server Cookie: <MISSING>

  

Il s'agit d'une requête, pas d'une réponse, donc il est normal que les sections Answer et Authority soient vides (taille à zéro). La section Additional n'est pas vide car elle contient l'enregistrement EDNS. Et la section Question contient un seul enregistrement, la question (« quelle est l'adresse IPv4 de wylag.de ? »).

Tout le problème traitée par ce RFC est : que se passe t-il si la section Question d'une requête contient plus d'un enregistrement ? Je divulgâche tout de suite : c'est interdit, il ne faut pas. (Pour le cas des requêtes/réponses ordinaires, avec l'opcode 0 ; d'autres messages DNS peuvent avoir des règles différentes.) La principale raison pour cette interdiction est que, dans la réponse, certains champs sont globaux à toute la réponse (comme le code de réponse, le rcode) et on ne peut donc pas se permettre d'accepter des questions qui risqueraient de nécessiter des réponses différentes. Désormais, un serveur DNS qui voit passer une requête avec un nombre de questions supérieur à 1 doit répondre avec le code de retour FORMERR (format error).

Le RFC 1035, la norme originelle, traitait ce point mais restait flou.

Il y avait une autre façon de régler le problème, en imposant que, s'il y a plusieurs questions, toutes portent sur le même nom de domaine. Cela aurait réglé le doute sur le code de retour et aurait pu être pratique pour des cas comme la demande simultanée de l'adresse IPv4 et IPv6. Mais cette solution a été écartée au profit de la solution plus simple qui était d'interdire les questions multiples. (Et, de toute façon, on ne peut pas garantir que le code de retour sera le même pour tous les types, même si le nom est le même. Pensez aux serveurs DNS générant dynamiquement les données.)

RDAP est le protocole recommandé pour accéder aux données sociales sur un nom de domaine, comme le nom du titulaire ou son adresse postale. Pour d'évidentes raisons de vie privée, certains registres ne renvoient pas la totalité de l'information dont ils disposent. Que doit-on mettre dans RDAP dans ce cas ? La question n'était pas tranchée et chaque registre faisait différemment. Désormais, il existe une solution normalisée.

Au passage, oui, d'accord, il n'y a pas que RDAP pour obtenir les données sociales (cet article vous en indiquera d'autres). Mais c'est le service le plus moderne et le plus adapté aux programmeur·ses. Contacté en HTTPS, le serveur RDAP va renvoyer du JSON que le client n'aura plus qu'à filtrer et formatter. Voici par exemple une partie de la réponse RDAP obtenue en se renseignant sur nouveaufrontpopulaire.fr :

% curl -s https://rdap.nic.fr/domain/nouveaufrontpopulaire.fr | jq
…
          [
            "fn",
            {},
            "text",
            "Parti Socialiste"
          ],
          [
            "org",
            {},
            "text",
            "Parti Socialiste"
          ],
          [
            "adr",
            {},
            "text",
            [
              "",
              "",
              "99 Rue Moliere",
              "Ivry-sur-Seine",
              "",
              "94200",
              "FR"
            ]
          ],
…
  

Ici, il s'agit d'une personne morale donc les données sont toutes envoyées. Et s'il s'agissait d'une personne physique, pour laquelle la loi Informatique & et Libertés s'applique, depuis 1978 ? La solution évidente est de ne pas envoyer les données qu'on ne veut pas diffuser mais attention, il y a un piège, il ne faut pas casser la syntaxe JSON. Par exemple, RDAP utilise (c'est en cours de changement, cf. RFC 9553) jCard pour formater les adresses (RFC 7095) et les champs dans jCard ne sont pas étiquetés, c'est leur position dans le tableau qui indique leur rôle (c'est un des nombreux inconvénients de jCard). On ne peut donc pas supprimer, par exemple, la rue, en indiquant :

[
            "adr",
            {},
            "text",
            [
              "",
              "",
              "Ivry-sur-Seine",
              "",
              "94200",
              "FR"
            ]
],
          [
            "email",
            {},
            "text",
            "e5d92838d5f0268143ac47d86880b5f7-48916400@contact.gandi.net"
          ],

Car, alors, on ne saurait plus si "Ivry-sur-Seine" est la rue ou bien la ville.

Le principe de notre RFC est donc : si on peut, retirer le membre JSON. Si on ne peut pas (cas du tableau de taille fixe), mettre une valeur vide ou null.

Petit point de terminologie : comment traduire le redacted du titre ? « Censuré » est inadapté (l'intervention ne vient pas d'un tiers mais d'une des deux parties). Je vais dire « élidé », mais « caviardé », « biffé » et « expurgé » sont également de bonnes solutions. Le nom correspondant est « élision ». Évidemment, il ne faut surtout pas dire « anonymisé », il n'y a rien d'anonyme ici, puisque le registre connait toute l'information, il refuse simplement de la diffuser.

La section 1 du RFC expose les grands principes de l'élision. Elle explique notamment qu'en cas d'élision, il faut ajouter un membre (nommé redacted) à la réponse JSON, expliquant les raisons et utilisant le langage JSONPath (RFC 9535) pour désigner de manière formelle la partie élidée.

Compte-tenu des contraintes sur la syntaxe de la réponse JSON (RFC 9083), le RFC normalise quatre façons d'élider (section 3) :

• Suppression d'un champ, si possible (c'est la méthode préférée). Cela marche dans la plupart des cas. Par exemple, si on ne veut pas publier le titulaire d'un domaine, on ne l'inclut pas dans la réponse, point.
• Mettre une valeur vide. Quand les contraintes de syntaxe empêchent de supprimer complètement un champ, on lui met une valeur vide. C'est notamment nécessaire pour les tableaux que jCard utilise abondamment : le retrait d'un champ casserait le tableau, qui est censé avoir un nombre d'élements fixe.
• Une valeur trop détaillée peut être remplacée par une valeur partielle. L'adresse "label":"123 Maple Ave\nSuite 901\nVancouver BC\nCanada" (un exemple du RFC 7095) peut être remplacée par une valeur moins précise comme "label":"Vancouver\nBC\nCanada\n".
• Enfin, la dernière méthode est de remplacer une valeur par une autre, par exemple une adresse de courrier par une adresse qui masque la vraie, comme e5d92838d5f0268143ac47d86880b5f7-48916400@contact.gandi.net dans l'exemple plus haut.

Et le RFC insiste qu'il ne faut pas utiliser de texte bidon (« XXX », « lorem ipsum dolor » ou « Ano Nymous ») car ce texte ne correspond pas forcément aux règles de syntaxe du champ (et, j'ajoute, peut être difficile à identifier pour le lecteur, qui peut ne pas avoir la référence).

Pour la première méthode, la suppression d'un champ, si on supprime le titulaire, on aura un membre nommé redacted (élidé) ajouté ainsi :

    "redacted": [
     {
       "name": {
         "description": "Remove registrant"
       },
       "prePath": "$.entities[?(@.roles[0]=='registrant')]",
       "method": "removal"
     }
     ]
  

Notez le (difficile à lire) code JSONPath $.entities[?(@.roles[0]=='registrant')].

Le deuxième cas, celui d'une valeur vide, donnerait, pour le cas où on supprime juste le nom du titulaire (qui est en position 1 dans le jCard, et son nom en position 3 - sachant qu'on part de 0) :

   [
     "fn",
     {},
     "text",
     ""
   ]
   …
      "redacted": [
     {
       "name": {
         "description": "Registrant Name"
       },
       "postPath": "$.entities[?(@.roles[0]=='registrant')].
         vcardArray[1][?(@[0]=='fn')][3]",
       "pathLang": "jsonpath",
       "method": "emptyValue",
       "reason": {
         "description": "Server policy"
       }
     }
     ]
     

Troisième technique d'élision, réduire une valeur. Le redacted devient :

   
   "redacted": [
     {
       "name": {
         "description": "Home Address Label"
       },
       "postPath": "$.vcardArray[1][?(@[0]=='adr')][1].label",
       "pathLang": "jsonpath",
       "method": "partialValue",
       "reason": {
         "description": "Server policy"
       }
     }
   ]
  

Et pour finir, la quatrième et dernière méthode, le remplacement :

   "redacted": [
     {
       "name": {
         "description": "Registrant Email"
       },
       "postPath": "$.entities[?(@.roles[0]=='registrant')].
                  vcardArray[1][?(@[0]=='email')][3]",
       "pathLang": "jsonpath",
       "method": "replacementValue",
     }
     ]
  

Ce membre appelé redacted est spécifié en détail dans la section 4 du RFC. (Et il est enregistré à l'IANA parmi les extensions RDAP.) Pour signaler qu'il peut apparaitre, le membre rdapConformance de la réponse JSON va l'indiquer :

{
  "rdapConformance": [
    "itNic",
    "redacted",
    "rdap_level_0"
  ],
…

Dès qu'il y a élision, redacted doit être ajouté. Il contient un tableau JSON d'objets, dont les membres peuvent être (seul le premier est obligatoire) :

• name : un terme qui décrit le champ élidé,
• prePath et postPath : des expressions JSONPath (RFC 9535) qui dénotent le membre retiré ou modifié,
• method : la technique d'élision utilisée (suppression, nettoyage, remplacement, etc),
• reason : texte libre décrivant la raison de l'élision.