Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.


RFC 8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping

Date de publication du RFC : Janvier 2017
Auteur(s) du RFC : J. Gould (Verisign)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 18 janvier 2017


Deux protocoles utilisés dans l'industrie des noms de domaine, EPP et RDAP, ont la notion d'état d'un nom de domaine, indiquant, par exemple, que ce nom est verrouillé et ne doit pas être modifié. Mais les états de EPP et de RDAP sont différents, et pas toujours évidents à rapprocher. Ce nouveau RFC précise la correspondance entre les états EPP et les états RDAP, établissant la liste comparée.

EPP (protocole d'avitaillement d'objets dans un registre, par exemple un registre de noms de domaine) est normalisé dans divers RFC (STD 69), ceux qui décrivent les états sont les RFC 5731 (section 2.3), RFC 5732 (section 2.3), RFC 5733 (section 2.2) et RFC 3915 (section 3.1). Les états RDAP (protocole d'information sur les objets d'un registre, qui vise à remplacer whois) sont normalisés dans le RFC 7483 (section 10.2) qui crée un registre IANA des états possibles. Pourquoi des états différents dans ces deux protocoles ? Disons qu'ils ont été conçus pour des buts différents, et que la nécessité de faire correspondre les états de l'un avec ceux de l'autre n'est devenue évidente qu'après. Le but de ce nouveau RFC est justement d'établir une correspondance univoque entre les états d'EPP et de RDAP.

La section 2 de notre RFC commence par une liste des états EPP, avec leur équivalent RDAP (quand il existe). Par exemple, il est assez évident que le pendingDelete d'EPP (RFC 5731) correspond au pending delete de RDAP. De même, le ok d'EPP est clairement l'équivalent du active de RDAP. Mais les addPeriod (RFC 3915, durée après l'enregistrement d'un nom de domaine pendant laquelle on peut annuler l'enregistrement gratuitement) ou clientHold (RFC 5731, le client a demandé que ce nom de domaine ne soit pas publié dans le DNS) d'EPP n'ont pas d'équivalent RDAP. L'inverse existe aussi, le delete prohibited de RDAP n'a pas un équivalent simple en EPP, qui a deux états pour cela, selon que l'interdiction a été posée par le client EPP ou par le serveur.

La section 2 du RFC se continue donc avec ce qui est désormais la liste officielle des correspondances, en tenant compte des nouveaux états ajoutés, par exemple dans le registre RDAP. C'est ainsi qu'un add period et un client hold ont été ajoutés (section 3 du RFC), ainsi qu'un client delete prohibited et un server delete prohibited, pour préciser le delete prohibited.

Pour les TLD gérés par l'ICANN, il va sans doute être obligatoire d'utiliser ces nouveaux états.


Téléchargez le RFC 8056


L'article seul

Utiliser un résolveur DNS public ?

Première rédaction de cet article le 15 janvier 2017


Après la censure administrative en France via des DNS menteurs, puis une panne spectaculaire des résolveurs DNS d'Orange, au moins trois pannes analogues de ceux de Free, et enfin un détournement accidentel de Google et Wikipédia vers le Ministère de l'Intérieur, pas mal d'utilisat·eur·rice·s de l'Internet se demandent si on peut vraiment faire confiance au résolveur DNS de son FAI. Et beaucoup se mettent alors à utiliser un résolveur DNS public, le plus célèbre étant Google Public DNS. Mais est-ce une bonne idée ?

D'abord, recadrons un peu la terminologie. Le protocole DNS a deux sortes de serveurs, qui n'ont pas grand'chose à voir, les serveurs faisant autorité et les résolveurs. Confondre les deux (par exemple en parlant du vague « serveur DNS ») ne va pas aider l'utilisat·eur·rice à comprendre, et donc à faire des choix corrects. Les serveurs faisant autorité sont ceux qui connaissent les informations sur le contenu des domaines. Par exemple, ceux de l'AFNIC connaissent le contenu de .fr et ceux de CloudFlare, hébergeur utilisé par Next INpact, connaissent le contenu de nextinpact.com, par exemple l'adresse du site Web (104.25.248.21 et 104.25.249.21 aujourd'hui). Les résolveurs (on dit aussi serveurs récursifs, ou bien serveurs caches), eux, ne connaissent rien, à part l'adresse des serveurs de la racine, où ils commencent leurs interrogations. Les serveurs faisant autorité sont gérés par des hébergeurs DNS spécialisés (comme Dyn), ou bien directement par le titulaire du nom de domaine. Les résolveurs sont typiquement gérés par le service informatique du réseau où vous vous connectez, ou bien par le FAI, pour les accès grand public. Ces résolveurs sont une partie cruciale du service d'accès à l'Internet : sans DNS, il n'y a quasiment rien qui marche. S'ils sont en panne, plus d'Internet. S'ils mentent, on est détourné vers un mauvais site.

On voit depuis des années apparaître des résolveurs DNS publics, qui ne dépendent ni du FAI, ni du réseau local d'accès. Ce sont Google Public DNS, Cisco OpenDNS, FDN, OpenNIC, Verisign, Yandex, etc. Attention à ne pas confondre ces résolveurs publics avec ce qu'on nomme les résolveurs ouverts. Tous ont en commun qu'ils acceptent de répondre à des requêtes DNS, quelle que soit leur source. Mais les résolveurs ouverts le sont par accident, par erreur de configuration, et ne sont pas gérés. Les résolveurs publics, eux, le sont déliberement, ils sont (normalement...) gérés par des gens sérieux. La différence est importante car un résolveur ouvert est un outil utile dans de nombreuses attaques comme les attaques par amplification ou comme certains empoisonnements. C'est pour cette raison que le RFC 5358 demande que les résolveurs DNS ne soient pas ouverts.

Après ce long préambule, retour aux pannes de résolveurs DNS. Aujourd'hui, dès qu'un problème Internet survient, et quelle que soit la cause réelle du problème, la réponse fuse sur tous les rézosocios : « utilise Google DNS » (ou bien, version libriste, « utilise FDN »). Un exemple, pris au hasard lors de la dernière panne Free est ce tweet. (Et voici une documentation plus élaborée.)

Ce genre de conseils ne tient pas compte de plusieurs inconvénients sérieux des résolveurs publics. Je vais commencer par les inconvénients communs à tous les résolveurs publics. Le principal est que le lien entre vous et le résolveur public est long et non sécurisé. Même si vous avez une confiance aveugle dans le résolveur public et ceux qui le gèrent, sur le trajet, des tas de choses peuvent aller mal. D'abord, le trafic peut être écouté trivialement (les seuls résolveurs publics qui proposent une solution à ce problème sont Cisco OpenDNS et OpenNIC, avec DNSCrypt). Comme le rappelle le RFC 7626, le trafic DNS est très bavard (trop), circule en clair, passe par des réseaux supplémentaires (en plus du trafic « normal »), et peut donc poser des problèmes de vie privée. Avec un résolveur DNS habituel, le problème est limité car le résolveur est proche de vous, limitant le nombre de gens qui peuvent écouter. Avec un résolveur public, le nombre d'écoutants potentiels augmente.

Mais il y a pire : la plupart des résolveurs publics n'offre aucune authentification (là encore, la seule exception est Cisco OpenDNS et OpenNIC, mais où cette authentification est facultative, et je ne sais pas combien d'utilisateurs s'en servent réellement). Même les mesures les plus triviales comme le NSID du RFC 5001 ne sont pas mises en œuvre (NSID ne fait pas une réelle authentification, mais il permet de détecter certains problèmes). Si vous utilisez des résolveurs publics pour contourner la censure, c'est un sérieux problème. Des censeurs ont déjà effectué des détournements de résolveurs DNS public (comme en Turquie, mais aussi dans d'autres pays). Donc, même si le résolveur public est géré par des gens biens, et que vous connaissez, cela ne suffit pas, car vous n'avez aucun moyen de savoir si vous parlez bien à ce résolveur, et pas à un usurpateur (le DNS utilise UDP, qui n'offre aucune protection contre l'usurpation d'adresse).

Il est amusant (et révélateur du manque de connaissances sur le fonctionnement de l'Internet) que les débats sur les résolveurs ouverts se focalisent souvent sur la confiance que l'on peut accorder (ou pas) au serveur, et jamais sur celle qu'on peut accorder (ou pas) au réseau qui y mène !

Il y a aussi des inconvénients qui sont spécifiques à certains des résolveurs publics souvent recommandés :

  • Je soupçonne que certains ne sont pas si bien gérés que cela (normalement, ils doivent faire de la limitation de trafic, être supervisés 24 heures sur 24, etc) et peuvent être utilisés pour des attaques par réflexion, avec amplification,
  • Google, Cisco et Verisign sont situés aux États-Unis, pays qui n'a aucune protection des données personnelles, même théorique (argument bien développé chez Shaft),
  • Yandex est en Russie, si vous voulez donner vos informations au FSB plutôt qu'à la NSA,
  • OpenNIC est une racine alternative, ce qui veut dire qu'ils ajoutent des TLD « bidons », qui ne marcheront que chez eux,
  • Certains services sont peu fiables, souvent en panne, très lents, ou disparaissant sans laisser de nouvelles.

Alors, si utiliser les résolveurs publics est une mauvaise idée, quelle est la bonne ? Le mieux serait évidemment de pouvoir utiliser les résolveurs DNS de son FAI. Un résolveur DNS correct fait partie (ou devrait faire partie) de l'offre Internet de base. Les utilisateurs devraient réclamer un tel service, fiable et rapide. Les pannes récentes, ou bien les horreurs des résolveurs DNS des points d'accès Wi-Fi des hôtels et des aéroports, et enfin le problème de la censure étatique (qu'un service de qualité chez le FAI ne résoudra pas) font qu'il n'y a plus guère le choix, il faut utiliser d'autres résolveurs que ceux du FAI. La solution la plus propre est d'avoir son propre résolveur DNS, pas forcément sur chaque machine de son réseau local, mais plutôt dans une machine unique, typiquement le routeur d'accès. Avant qu'on ne me dise « mais ce n'est pas Michu-compatible, M. Michu ne vas quand même pas installer OpenBSD sur un Raspberry Pi pour avoir un résolveur sur son réseau », je dis tout de suite qu'évidemment, cela ne doit pas être fait directement par M. Michu mais une fois pour toutes dans un paquet logiciel et/ou matériel qu'il n'y a plus qu'à brancher. (Un truc du genre de la Brique Internet.)

Parfois, il est difficile ou peu pratique d'avoir son propre résolveur. En outre, un résolveur à soi sur le réseau local protège bien contre la censure, ou contre les pannes, mais peu contre la surveillance, puisqu'il va lui-même émettre des requêtes en clair aux serveurs faisant autorité. Il est donc utile d'avoir des résolveurs publics accessibles en DNS-sur-TLS (RFC 7858), ce qui protège la confidentialité et permet l'authentification du résolveur. Ces résolveurs publics (comme par exemple celui de LDN ou bien celui de Yeti) peuvent être utilisés directement, ou bien servir de relais pour le résolveur local. Attention, la plupart sont encore très expérimentaux. Vous trouverez une liste sur le portail DNS Privacy. (Pour la solution non normalisée DNScrypt, on trouve, outre le site Web officiel, la doc de malekalmorte ou bien celle-ci.)

Pour se prémunir contre la censure (mais pas contre les pannes, ni contre la surveillance), une autre technologie utile est DNSSEC. Le résolveur local doit donc valider avec DNSSEC. Notez que, malheureusement, peu de domaines sont signés.

La meilleure solution est donc un résolveur DNS validant avec DNSSEC et tournant sur une machine du réseau local (la « box » est l'endroit idéal). Cela assure un résolveur non-menteur et sécurisé. Si on veut en plus de la vie privée, il faut lui faire suivre les requêtes non-résolues à un résolveur public de confiance (donc pas Google ou Verisign) et accessible par un canal chiffré (DNS sur TLS).

Si votre box est fermée et ne permet pas ce genre de manips, remplacez-la par un engin ouvert, libre et tout ça, comme le Turris Omnia qui a par défaut un résolveur DNSSEC.


L'article seul

RFC 8021: Generation of IPv6 Atomic Fragments Considered Harmful

Date de publication du RFC : Janvier 2017
Auteur(s) du RFC : F. Gont (SI6 Networks / UTN-FRH), W. Liu (Huawei Technologies), T. Anderson (Redpill Linpro)
Pour information
Première rédaction de cet article le 7 janvier 2017


C'est quoi, un « fragment atomique » ? Décrits dans le RFC 6946, ces charmants objets sont des datagrammes IPv6 qui sont des fragments... sans en être. Ils ont un en-tête de fragmentation sans être fragmentés du tout. Ce RFC estime qu'ils ne servent à rien, et sont dangereux, et devraient donc ne plus être générés.

Le mécanisme de fragmentation d'IPv6 (assez différent de celui d'IPv4) est décrit dans le RFC 2460, sections 4.5 et 5. Que se passe-t-il si un routeur génère un message ICMP Packet Too Big (RFC 4443, section 3.2) en indiquant une MTU inférieure à 1 280 octets, qui est normalement la MTU minimale d'IPv6 ? (Le plus beau, c'est que ce routeur n'est pas forcément en tort, cf. RFC 6145, qui décrivait leur utilisation pour être sûr d'avoir un identificateur de datagramme.) Eh bien, dans ce cas, l'émetteur du datagramme trop gros doit mettre un en-tête « Fragmentation » dans les datagrammes suivants, même s'il ne réduit pas sa MTU en dessous de 1 280 octets. Ce sont ces datagrammes portant un en-tête « Fragmentation » mais pas réellement fragmentés (leur bit M est à 0), qui sont les fragments atomiques du RFC 6946.

Malheureusement, ces fragments atomiques permettent des attaques contre les machines IPv6 (section 2 du RFC). Il existe des attaques liées à la fragmentation (RFC 6274 et RFC 7739). Certaines nécessitent que les datagrammes soient réellement fragmentés mais ce n'est pas le cas de toutes : il y en a qui marchent aussi bien avec des fragments atomiques. Un exemple d'une telle attaque exploite une énorme erreur de certaines middleboxes, jeter les datagrammes IPv6 ayant un en-tête d'extension, quel qu'il soit (y compris, donc, l'en-tête Fragmentation). Ce comportement est stupide mais hélas répandu (cf. RFC 7872). Un attaquant peut exploiter cette violation de la neutralité du réseau pour faire une attaque par déni de service : il émet des faux messages ICMP Packet Too Big avec une MTU inférieur à 1 280 octets, la source se met à générer des fragments atomiques, et ceux-ci sont jetés par ces imbéciles de middleboxes.

Le RFC décrit aussi une variante de cette attaque, où deux pairs BGP jettent les fragments reçus (méthode qui évite certaines attaques contre le plan de contrôle du routeur) mais reçoivent les ICMP Packet Too Big et fabriquent alors des fragments atomiques. Il serait alors facile de couper la session entre ces deux pairs. (Personnellement, le cas me parait assez tiré par les cheveux...)

Ces attaques sont plus faciles à faire qu'on ne pourrait le croire car :

  • Un paquet ICMP peut être légitimement émis par un routeur intermédiaire et l'attaquant n'a donc pas besoin d'usurper l'adresse IP de la destination (donc, BCP 38 ne sert à rien).
  • Certes, l'attaquant doit usurper les adresses IP contenues dans le message ICMP lui-même mais c'est trivial : même si on peut en théorie envisager des contrôles du style BCP 38 de ce contenu, en pratique, personne ne le fait aujourd'hui.
  • De toute façon, pas mal de mises en œuvres d'IP ne font aucune validation du contenu du message ICMP (malgré les recommandations du RFC 5927).
  • Un seul message ICMP suffit, y compris pour plusieurs connexions TCP, car la MTU réduite est typiquement mémorisée dans le cache de l'émetteur.
  • Comme la seule utilisation légitime connue des fragments atomiques était celle du RFC 6145 (qui a depuis été remplacé par le RFC 7915), on pourrait se dire qu'il suffit de limiter leur génération aux cas où on écrit à un traducteur utilisant le RFC 6145. Mais cela ne marche pas, car il n'y a pas de moyen fiable de détecter ces traducteurs.

Outre ces problèmes de sécurité, le RFC note (section 3) que les fragments atomiques ne sont de toute façon pas quelque chose sur lequel on puisse compter. Il faut que la machine émettrice les génère (elle devrait, mais la section 6 du RFC 6145 note que beaucoup ne le font pas), et, malheureusement, aussi bien les messages ICMP Packet Too Big que les fragments sont souvent jetés par des machines intermédiaires.

D'ailleurs, il n'est même pas certain que la méthode du RFC 6145 (faire générer des fragments atomiques afin d'obtenir un identificateur par datagramme) marche vraiment, l'API ne donnant pas toujours accès à cet identificateur de fragment. (Au passage, pour avoir une idée de la complexité de la mise en œuvre des fragments IP, voir cet excellent article sur le noyau Linux.)

En conclusion (section 4), notre RFC demande qu'on abandonne les fragments atomiques :

  • Les traducteurs du RFC 7915 (la seule utilisation légitime connue) devraient arrêter d'en faire générer.
  • Les machines IPv6 devraient désormais ignorer les messages ICMP Packet Too Big lorsqu'ils indiquent une MTU inférieure à 1 280 octets.

Téléchargez le RFC 8021


L'article seul

RFC 7826: Real-Time Streaming Protocol Version 2.0

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : H. Schulzrinne (Columbia University), A. Rao (Cisco), R. Lanphier, M. Westerlund (Ericsson AB), M. Stiemerling (NEC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF mmusic
Première rédaction de cet article le 28 décembre 2016


Voici la version 2 du protocole bien connu RTSP, protocole servant à accéder à des flux vidéo. Comme c'est ce que j'utilise pour regarder la télévision sur l'écran de mon PC, je suis ravi que l'IETF se préoccupe de l'améliorer.

Comme beaucoup de protocoles dans le monde du multimédia (SIP, par exemple), RTSP est en fait uniquement un protocole de contrôle, permettant de déclencher ou d'arrêter des flux audio ou vidéo. Ces flux peuvent être temps-réel ou bien avoir simplement été stockés sur le disque d'un serveur. Donc, RTSP est une zapette logicielle. RTSP fait le contrôle et plusieurs protocoles peuvent être utilisés pour le transport des données, UDP, TCP, RTP, etc. À noter la taille impressionnante de ce RFC, avec plus de 300 pages. Ce n'est pas que le protocole soit si compliqué que cela, mais il y a beaucoup d'options et de choix.

La section 2 du RFC résume le protocole : RTSP est client/serveur, le client RTSP se connecte au serveur, un certain nombre de choix techniques sont faits et ensuite l'envoi des données commence. Physiquement, les messages sont du texte (la syntaxe de RTSP ressemble beaucoup à celle d'HTTP) bien que du binaire soit parfois possible. La ressource convoitée est identifiée par un URI de plan rtsp (ou rtsps pour TLS) et cet URI contient le nom de la machine qui sera utilisée comme serveur. Par exemple, si je dis à mon logiciel RTSP d'utiliser rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=658&flavour=ld, la connexion RTSP sur TCP (ou TCP avec TLS) se fera avec mafreebox.freebox.fr. La requête RTSP inclus un certain nombre d'en-têtes comme dans HTTP, et parfois un corps (toujours comme en HTTP). Voici un exemple avec le client VLC. Je le lance avec vlc 'rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=897' et on voit (tcpdump ne sait pas apparemment décoder le RTSP mais Wireshark y arrive très bien) :

Internet Protocol Version 4, Src: 192.168.2.1 (192.168.2.1), Dst: 212.27.38.253  (212.27.38.253)
Transmission Control Protocol, Src Port: 45854 (45854), Dst Port: rtsp (554), Seq: 563, Ack: 873, Len: 204
Real Time Streaming Protocol
    Request: PLAY rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=897 RTSP/1.0\r\n
    CSeq: 5\r\n
    User-Agent: LibVLC/2.0.3 (LIVE555 Streaming Media v2012.05.17)\r\n
    Session: pokf6CQWbA8CUyC
    Range: npt=0.000-\r\n
    \r\n

Dans l'exemple ci-dessus, le protocole était RTSP version 1.0 (rappelez-vous que ce RFC décrit la version 2), la requête était PLAY (dont le nom dit bien ce qu'elle fait et vous ne serez pas surpris d'apprendre qu'il existe une commande PAUSE) et l'un des en-têtes, User-Agent: montre que j'utilise bien vlc.

Quand au trafic lui-même, on voit (ici avec tcpdump) d'abord du RTSP sur TCP puis un gros flux UDP :

21:34:36.179830 IP (tos 0x10, ttl 64, id 20888, offset 0, flags [DF], proto UDP (17), length 1356)
    212.27.38.253.46099 > 192.168.2.1.34324: [udp sum ok] UDP, length 1328
21:34:36.180040 IP (tos 0x10, ttl 64, id 20889, offset 0, flags [DF], proto UDP (17), length 1356)
    212.27.38.253.46099 > 192.168.2.1.34324: [udp sum ok] UDP, length 1328
21:34:36.180738 IP (tos 0x10, ttl 64, id 20890, offset 0, flags [DF], proto UDP (17), length 1356)
    212.27.38.253.46099 > 192.168.2.1.34324: [udp sum ok] UDP, length 1328

Les contenus auxquels on accède avec RTSP peuvent être de type très variés. Il faut donc une description formalisée des caractéristiques de ce contenu. RTSP peut utiliser plusieurs formats pour cela, le plus répandu étant sans doute SDP (RFC 4566). C'est en tout cas celui utilisé entre mon VLC et ma Freebox. La description peut inclure le nombre de flux (souvent un flux vidéo et plusieurs audios), le protocole de délivrance (RTPRFC 3550 - dans l'exemple ci-dessous), le format (MPEG-2 ici), etc :

    Session Description Protocol
        Session Description Protocol Version (v): 0
        Owner/Creator, Session Id (o): leCDN 1395332443 1395332443 IN IP4 kapoueh.proxad.net
...
        Media Description, name and address (m): video 0 RTP/AVP 33
            Media Type: video
            Media Port: 0
            Media Protocol: RTP/AVP
            Media Format: MPEG-II transport streams
        Media Attribute (a): control:rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=658&flavour=ld
            Media Attribute Fieldname: control
            Media Attribute Value: rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=658&flavour=ld

Quels sont les changements par rapport à RTSP version 1, la version du RFC 2326 ? Les deux versions, quoique identiques dans leurs principes, ne sont pas compatibles (par exemple, la commande PLAY n'a plus le même comportement, des en-têtes ont changé de syntaxe sans changer de nom, etc). C'est toujours un choix difficile que de casser la compatibilité d'un protocole mais, là, c'était nécessaire vu le nombre de modifications. En outre, RTSP 1 ne permettait pas de déployer facilement des extensions (en-têtes à la syntaxe trop rigide) et le modèle d'extension a changé. L'annexe I de notre RFC résume ce qu'il faut savoir sur ces différences : suppression des requêtes RECORD et ANNOUNCE, suppression de l'option qui permettait de faire passer RTSP (le contrôle, pas les données) sur UDP, gestion complète d'IPv6 (qui manquait en version 1), refactorisation du RFC (les en-têtes qui sont proches de ceux de HTTP sont désormais décrits par un texte spécifique, sans renvoyer au RFC HTTP), etc.

Il y a apparemment au moins une mise en œuvre de RTSP qui a la version 2, et plusieurs des nouveautés de la version 2 ont été mises en œuvre de manière séparée.


Téléchargez le RFC 7826


L'article seul

RFC 7992: HTML Format for RFCs

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : J. Hildebrand (Cisco Systems), P. Hoffman (ICANN)
Pour information
Première rédaction de cet article le 16 décembre 2016


Depuis la sortie du RFC 7990 et ses copains, le format canonique (le format de référence) des RFC n'est plus le texte seul mais un langage XML, normalisé dans le RFC 7991. Les formats « de publication » seront produits automatiquement à partir de ce XML. C'est ainsi que notre RFC 7992 décrit la sortie HTML, qui permettra de publier des beaux RFC sur le Web.

HTML, trop riche et trop mouvant, est en effet mal adapté à l'écriture et à la maintenance de documents. Il n'était donc pas envisageable de le choisir comme format canonique. En revanche, il est incontournable comme format de publication. C'est en effet le langage du Web, et il y a donc logiquement une forte demande pour pouvoir lire les RFC en HTML. Avant, lorsque le format canonique était le texte brut, des versions non officielles étaient publiées en HTML (voir un exemple) mais, le texte brut n'ayant pas de formatage précis, ces versions n'avaient pas vraiment l'air de vraies pages Web...

(Notez que ce blog que vous êtes en train de lire est produit par un mécanisme analogue à celui que les RFC suivront désormais : tapé en XML, avec le HTML produit automatiquement.)

La section 1 de notre RFC résume les principes de l'HTML utilisé. D'abord, ce sera un sous-ensemble de HTML (HTML a bien trop de fonctions). Ensuite, la présentation sera largement délégué à une feuille de style CSS, dont les caractéristiques sont mentionnées dans le RFC 7993.

La section 2, elle, est le « cahier des charges » du HTML des RFC. Elle précise les exigences du RFC 6949. Elle concerne les auteurs du ou des logiciels de production des RFC (pour ces logiciels, voir le RFC 7998). Les auteurs de RFC, eux, n'ont pas à s'en soucier, ils écrivent du XML, et le HTML sera produit par les outils.

Le but principal est que l'HTML produit soit parfaitement lisible sur la grande majorité des navigateurs utilisés. Pas question bien sûr d'ajouter une de des ridicules mentions « optimisé pour Internet Explorer » qui étaient si communes sur les sites Web d'amateurs, dans les années 2000. Notre RFC mentionne explicitement l'exigence que les textes soient lisibles avec au moins un navigateur « texte », comme Lynx, certaines personnes accédant au Web ainsi (par obligation ou par goût). C'est l'une des raisons de la décision de ne pas accepter la totalité de HTML.

Le fichier HTML devra être autonome (ne pas dépendre de fichiers extérieurs), de manière à pouvoir être transmis facilement par des mécanismes tels que rsync ou le courrier électronique.

Le JavaScript est accepté mais à condition qu'il ne modifie en aucun cas le texte du RFC. (Il peut, par exemple, ajouter des éléments de navigation, ou afficher des métadonnées.)

On l'a dit, CSS sera utilisé pour la présentation, mais le cahier des charges exige qu'on puisse facilement remplacer la feuille de style par une de son choix, pour s'adapter aux goûts locaux.

Le Web étant fondé sur la notion de lien hypertexte, il y aura évidemment des liens, aussi bien ceux mis explicitement par l'auteur (« ce point est développé en section N »), que ceux ajoutés automatiquement (de la table des matières vers les différentes sections, par exemple).

Un point crucial est évidemment l'accessibilité. Comme le savent tous ceux et toutes celles qui vont régulièrement à Paris Web, c'est un point essentiel mais souvent oublié. Notre RFC note donc que les publications en HTML des futurs RFC devront être accessibles aux malvoyants, aux daltoniens, et aux utilisateurs de petits écrans, par exemple les smartphones. (Note personnelle : ce dernier point ne devrait pas être dans une section sur l'accessibilité. Le Web est prévu - contrairement aux formats du monde du papier, comme PDF - pour être visible sur tous les périphériques.)

Au fait, quelle version de HTML sera utilisée (section 3 de notre RFC) ? Ce sera HTML5 (et pas, et je le déplore, XHTML ; l'inconvénient, souvent cité contre XHTML, de la difficulté à l'écrire n'a pas de sens ici, puisque le HTML sera produit automatiquement).

La section 4 précise la syntaxe utilisée (rappelez-vous qu'on n'accepte pas la totalité de HTML5) : encodage en UTF-8, sauts de ligne en style Unix (un U+000A et rien d'autre), pas de caractères de contrôle comme la tabulation (U+0009). Les éventuels commentaires du source XML ne seront pas mis dans le HTML (l'idée est qu'ils sont pour les auteurs, pas pour les lecteurs).

Il y a des objets divers qu'on retrouve souvent dans le source XML. Ils sont rassemblés dans la section 5. Par exemple, on trouve les identificateurs qui seront mis comme valeur des attributs id dans le HTML produit. Ce sont parfois des identificateurs mis explicitement par l'auteur, et parfois des identificateurs produits par le logiciel, par exemple pour que les entrées de la table des matières pointent vers la section correspondante.

Autre objet récurrent, la marque de paragraphe (pilcrow pied-de-mouche, caractère Unicode U+00B6, celui-ci : ¶), qui sera mise automatiquement derrière chaque paragraphe, mais pas affiché par défaut (il faudra promener le pointeur dessus pour le voir).

Maintenant, attaquons les différentes parties du RFC rendu en HTML. D'abord (section 6), les premiers objets HTML qu'on rencontrera, notamment les métadonnées du RFC. Il y aura évidemment un DOCTYPE identifiant le document comme du HTML5. L'élément racine sera <html>, avec une étiquette de langue qui sera bien sûr en, l'anglais. L'élément <head> qui suivra contiendra une déclaration de jeu de caractère, un titre, et diverses métadonnées :

    

   <meta charset="utf-8">
   <title>The Mother of all RFCs</title>
   <meta name="author" content="Joe Hildebrand">
   <meta name="author" content="Heather Flanagan">
   <meta name="description" content="This document defines...">
   <meta name="generator" content="xmljade v0.2.4">
   <meta name="keywords" content="html,css,rfc">

(Rappelez-vous que le HTML produit n'est hélas pas du XHTML donc il est normal que les <meta> ne soient pas explicitement fermés.) Il y aura aussi un lien vers la licence des RFC, en utilisant le cadre général des liens (RFC 5988) :


   <link rel="license" href="https://www.rfc-editor.org/copyright/">

   

Cette première partie du RFC produit contiendra aussi une feuille de style, ainsi qu'un lien vers une éventuelle feuille locale, au cas où un lecteur souhaiterait lire le RFC selon un style différent :


   <style>
     body {}
     ...
   </style>
   <link rel="stylesheet" type="text/css" href="rfc-local.css">

    

Le début de la partie visible du RFC sera composée d'une <dl> pour les métadonnées affichées, et d'une table des matières. Les métadonnées seront donc du genre :


   <dl id="identifiers">
     <dt>Workgroup:</dt>
       <dd class="workgroup">rfc-interest</dd>
     <dt>Series:</dt>
       <dd class="series">Internet-Draft</dd>
     <dt>Status:</dt>
       <dd class="status">Informational</dd>
     <dt>Published:</dt>
       <dd><time datetime="2014-10-25"
                 class="published">2014-10-25</time></dd>
     ...

    

La partie principale du RFC sera, elle, rendue selon les principes décrits en section 9 pour chacun des éléments XML qui composent le source.

La dernière partie du RFC incluera un index (si le source XML avait un attribut indexInclude dans l'élément <rfc>), les adresses des auteurs (formatées en hCard), et les métadonnées considérées comme les moins importantes (les autres ayant été mises au début).

La section 9 de notre RFC est particulièrement longue car elle décrit le rendu en HTML de tous les éléments du vocabulaire XML du RFC 7991. Je ne vais pas tout décrire ici, juste donner quelques exemples. Ainsi, <artwork> sera rendu dans un élément HTML <pre>, si le schéma était en art ASCII, sera inclus tel quel dans le HTML si le schéma était en SVG (RFC 7996), et sera mis sous forme d'un <img> (avec contenu de plan data:) dans les autres cas. <sourcecode>, lui, est toujours restitué sous forme d'un <pre> HTML.

La traduction de certains éléments en HTML est plus directe. Par exemple, <em> est simplement rendu par le même élément HTML.

Et, pour finir, un petit mot sur la sécurité (section 11) : comme les RFC en HTML ne sont pas forcément téléchargés depuis le Web mais peuvent être lus depuis un fichier local (après, par exemple, synchronisation via rsync), on ne bénéficie pas forcément des protections du navigateur. Donc, prudence.


Téléchargez le RFC 7992


L'article seul

RFC 7998: "xml2rfc" Version 3 Preparation Tool Description

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : P. Hoffman (ICANN), J. Hildebrand (Cisco)
Pour information
Première rédaction de cet article le 16 décembre 2016


Depuis la sortie du RFC 7990, le format canonique des RFC est le format XML. C'est un texte écrit en XML, selon le vocabulaire du RFC 7991 qui sera la version de référence, archivée et faisant autorité, pour tous les RFC. Comme les auteurs enverront souvent un XML imparfait, un outil de préparation sera nécessaire, pour compléter ce XML imparfait et permettre au RFC Editor de travailler sur une base sérieuse. Ce nouveau RFC décrit ce futur outil de préparation.

Ainsi, les outils qui travailleront sur le format canonique des RFC (par exemple les outils qui produiront le PDF, le HTML, etc) pourront compter sur un document complet et n'auront pas à gérer les écarts des auteurs : seul l'outil de préparation devra s'en soucier.

Cet outil de préparation servira aux RFC une fois qu'ils seront soumis au RFC production center (cf. RFC 6635) mais aussi aux Internet-Drafts pendant leur élaboration.

Dans le second cas (section 3 de notre RFC), le futur outil de préparation prendra un Internet-Draft en entrée et produira un document complet (par exemple avec addition des boilerplates).

Et ce sera à peu près la même chose lorsque le RFC sera presque fini. On passera la version finale dans l'outil de préparation, qui résoudra les références externes et ajoutera les éléments obligatoires manquants.

Bon, et en quoi vont consister exactement ces modifications ? Elle sont décrites dans la section 5, qui forme le gros de ce RFC. Contrairement à l'outil actuel idnits qui se contente de vérifier les Internet-Drafts, le nouvel outil va également corriger le texte, ajoutant des éléments, et changeant les valeurs erronées.

C'est ainsi que l'outil de préparation va traiter les éléments XInclude, les remplaçant par la valeur incluse. Il va traiter les DTD pour les supprimer ensuite (donc, remplacer les entités par leur valeur, et inclure les fichiers inclus par ce mécanisme). Ces deux actions peuvent aujourd'hui être faites par l'outil xmllint, avec xmllint --xinclude --noent --dropdtd NOMDUFICHIER.xml.

Outre ces mécanismes d'inclusion de XML, l'outil de préparation va aussi traiter les inclusions spécifiques au vocabulaire du RFC 7991. Ainsi, <artwork> a un attribut src indiquant la source du graphique, et l'outil de préparation va donc inclure ce graphique. (Idem avec <sourcecode> pour inclure le code source.)

Les instructions XML (PI, Processing Instructions) seront supprimées (ça, je ne sais pas le faire avec xmllint).

L'outil va valider le résultat produit, en utilisant la grammaire Relax NG du RFC 7991. Ça peut aujourd'hui se faire avec xmllint mais aussi avec rnv :

% rnv rfc-v3.rnc rfc-v3-sample.xml
rfc-v3-sample.xml
    

ou bien avec jing :

% java -jar ./jing-20091111/bin/jing.jar  -c rfc-v3.rnc rfc-v3-sample.xml
    

Parmi les nombreuses transformations possibles, citons l'ajout (s'il n'était pas déjà présent) de l'élément <seriesInfo> qui indique s'il s'agit d'un Internet-Draft ou d'un RFC, l'ajout d'un élément <date> s'il manque (sa valeur étant la date du traitement), changement de l'ancien attribut title en name, le retrait des commentaires XML...

Il est fréquent dans les Internet-Drafts de voir des paragraphes qui ne devront pas être inclus dans le futur RFC. C'est le cas s'ils contiennent des exemples réels qui risquent de ne pas être éternels (les RFC peuvent durer longtemps et ne sont jamais modifiés). C'est également le cas s'il s'agit de l'état actuel des mises en œuvre d'un RFC, comme décrit dans le RFC 7942. Dans le système actuel, ces paragraphes sont marqués par un texte en langue naturelle. Dans le nouveau vocabulaire du RFC 7991, ce sera fait avec un attribut removeInRFC. L'outil de préparation pourra enlever automatiquement ce paragraphe quand il préparera un RFC.

L'outil de prépartion devra également arranger le XML. Cela peut se faire aujourd'hui avec xmllint (ses options --format ou bien --pretty). Par contre, il n'est pas prévu de mettre le XML sous sa forme canonique.

Il y aura d'autres opérations faites par l'outil de préparation, voir le RFC pour les détails.

L'outil n'est pas encore développé, un appel d'offres a été lancé et les gagnants ont été les sociétés SeanTek et Elf Tools.


Téléchargez le RFC 7998


L'article seul

RFC 7990: RFC Format Framework

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : H. Flanagan (RFC Editor)
Pour information
Première rédaction de cet article le 16 décembre 2016


Voici enfin la série de RFC décrivant le nouveau format des RFC. Ce projet a commencé il y a plusieurs années, mais les discussions ont été longues. Ce nouveau RFC et les huit autres qui l'accompagnent, marquent un changement important dans ces « textes sacrés » de l'Internet : l'ancien format « texte brut » n'est plus le format de référence. Désormais, tout RFC sera fait en XML, format d'où seront produits automatiquement des versions texte brut, HTML, PDF, etc.

Les RFC sont des documents cruciaux pour l'Internet. C'est sous forme de RFC que sont publiées les normes techniques de la famille de protocoles TCP/IP. Et il y a bien d'autres RFC qui ne sont pas forcément des normes (cf. RFC 1796). Librement disponibles en ligne (contrairement aux normes techniques des organisations traditionnelles du mésozoïque), dans un format ouvert, la disponibilité des RFC est l'une des raisons du succès de l'Internet.

Parlons de format, justement. Les RFC, jusqu'à maintenant, étaient sous forme de texte brut, et en ASCII seul. (Certes, des versions PDF et HTML non-officielles étaient diffusées mais on voyait bien qu'elles avaient été produites à partir du texte brut... Certes, il était possible depuis dix ans d'écrire les RFC en XML, cf. RFC 2629, mais ce n'était pas le format de référence.) Pourquoi donc se limiter à ce format ? Il y avait plusieurs bonnes (et d'autres moins bonnes) raisons mais il ne faut pas de cacher qu'une des raisons les plus importantes était qu'il est difficile de faire changer un processus de production bien établi, même s'il comprend des archaïsmes, comme l'utilisation de troff pour traiter des documents. L'actuelle éditrice des RFC, Heather Flanagan, a donc eu bien du mérite à faire aboutir ce projet de changement. Il a fallu beaucoup de discussions, dans une communauté souvent divisée. (Que les informaticiens pensent aux grands débats du genre « vi ou emacs ? »)

Le projet de réforme des RFC avait sérieusement commencé en 2013 avec le RFC 6949, le véritable cahier des charges du nouveau format. La décision formelle de migrer vers le nouveau format, et donc de décider que le format de référence serait désormais le XML et non plus le texte brut a été prise en mai 2013. Avant et pendant cette décision, d'innombrables messages ont été échangés sur la liste de diffusion rfc-interest.

Il est important de noter que cette discussion portait sur le processus de publication des RFC terminés. L'élaboration des Internet-Drafts, la décision de les publier ou pas (qui dépend de chaque voie, cf. RFC 4844) ne sont pas concernées.

La section 2 de notre RFC résume le problème que veut résoudre le nouveau format. Le monde a bien changé depuis que seuls une poignée de Californiens anglophones venait aux réunions IETF. Les participants viennent aujourd'hui de 45 pays, situés dans le monde entier, les lecteurs des RFC sont plus divers que jamais, utilisent des engins très variés, et il est toujours aussi crucial que les RFC soient largement disponibles et accessibles, et sur une très longue période (mon favori est le RFC 768, publié en 1980 et toujours d'actualité). Le format de référence en texte ASCII brut ne permettait clairement pas cela.

Mais choisir un successeur n'était pas facile : notre RFC insiste sur le fait qu'il y a aujourd'hui plusieurs groupes qui utilisent les RFC (pas seulement des techniciens, juristes et chefs accèdent aujourd'hui à des RFC), et sur le fait qu'il fallait un compromis entre les besoins actuels et l'importance d'une disponibilité à long terme (par exemple, adopter le format à la mode du moment pourrait se payer cher plus tard lorsque ce format n'intéressera plus personne).

Un peu de terminologie (section 3) est nécessaire pour bien comprendre le choix effectué :

  • Format canonique : le format de référence, archivé, utilisé en cas de conflit (XML, donc). Il est important d'en avoir un, au cas où une bogue dans les logiciels change une partie d'un RFC.
  • Formats de publication : les divers formats sous lesquels est publié le RFC (détaillés en section 7). Peu de gens liront le RFC en XML (quoique cela soit possible, une propriété qui est importante pour la conservation à long terme). Ils liront de l'HTML, du PDF, voire du texte seul pour les traditionnalistes. Tous ces formats seront produits (de préférence automatiquement) à partir du format canonique. Chacun a ses avantages et inconvénients (section 5). Par exemple, HTML avec JavaScript fournit des capacités de navigation bien meilleures que le texte brut.
  • Format révisable : le format que le RFC Editor utilisera pour son travail interne. Ce sera XML.
  • Format de soumission : le format sous lequel le texte sera transmis initialement par les auteurs au RFC Editor. Aujourd'hui, le texte brut est obligatoire, le XML autorisé en prime. Demain, ce sera du XML, mais avec des exigences moins strictes que pour le format canonique.

Et aussi un terme important : texte réagencable (ou réajustable, reflowable text). C'est du texte qui s'ajuste automatiquement à la largeur du dispositif de lecture. C'est banal dans le monde HTML, où c'est fait automatiquement depuis toujours. Mais c'était un des principaux inconvénients de l'ancien format des RFC : le texte avait une largeur fixe.

Quel sera donc exactement le format canonique ? La section 6 répond à cette question :

  • Le langage sera du XML avec le vocabulaire spécifié dans le RFC 7991 (nommé « v3 »). Il est normalement meilleur que les précédents vocabulaires utilisés depuis le RFC 2629.
  • Les auteurs pourront envoyer leur draft en suivant le format dit « v2 » (celui du RFC 7749), voire en texte brut, mais il sera ensuite converti dans le format v3 ci-dessus.
  • Le SVG sera autorisé dans le source XML.
  • Comme en v2, DTD est abandonné, la description officielle du schéma XML est en Relax NG.
  • Les textes obligatoires (RFC 5741) seront automatiquement insérés.
  • Le source XML du format canonique sera autonome. Cela veut dire qu'il n'aura pas de références à des sources extérieures. Ainsi, si un auteur référence un code source externe avec <sourcecode src="[un URI externe]"... (RFC 7991, section 2.48), le code en question sera inclus dans la version canonique. Idem si l'auteur a utilisé XInclude.
  • Il n'y aura pas de commentaires ou de processing instructions dans le source XML. Si l'auteur en a mis, ils seront retirés.

Notez donc que les images (en SVG) seront désormais possibles (voir le RFC 7996).

Le guide du style des RFC (RFC 7322) avait été révisé pour tenir compte de ce nouveau format. Notamment, il se concentre désormais sur le contenu du texte, ne demandant plus aux auteurs des efforts de présentation. (La section 5 résume les changements importants pour les auteurs.)

Enfin, la section 7 décrit les formats de publication. À partir du source XML, seront automatiquement produits HTML, PDF, texte brut et peut-être plus tard d'autres. Le HTML est évidemment la cible évidente. Son utilisation pour les RFC est décrite dans le RFC 7992. Le résultat sera certainement bien meilleur que les versions HTML non-officielles actuelles, qui sont produites à partir du texte brut, qui ne contient pas assez de structure pour faire du bon HTML. La mise en page sera évidemment assurée par CSS (RFC 7993), il y aura une feuille de style standard, que chacun sera bien sûr libre de remplacer. Le SVG sera inclus dans l'HTML (il faudra donc un navigateur qui gère bien SVG). Il y aura même du JavaScript mais avec de sévères restrictions. Notamment, le code JavaScript ne devra pas changer le texte, ou supprimer du texte.

PDF, quant à lui, est spécifié dans le RFC 7995. Il devra suivre le profil PDF/A-3, spécialement prévu pour de l'archivage à long terme, et pour pouvoir être relu par des logiciels PDF n'ayant pas tous les derniers gadgets.

Naturellement, le texte brut n'est pas abandonné. Comme indiqué dans le RFC 7994, il y aura une version en texte brut produite automatiquement à partir du XML, même si elle ne sera plus la version canonique. Parmi les nouveautés par rapport à l'ancien format, UTF-8 sera désormais autorisé, même si c'est de façon limitée (voir les limitations dans le RFC 7997). Il pourra y avoir une variante non découpée en pages.

Dans le futur, il est possible que le format EPUB soit ajouté à cette liste.

Au passage, comment a été décidé cet important changement dans le format des RFC ? La section 4 résume cette histoire. Comme indiqué plus haut, cela a pris très longtemps et nécessité beaucoup de discussions, qui ont notamment eu lieu sur la liste de diffusion rfc-interest, et au cours des réunions physiques de l'IETF. Le cahier des charges a été formalisé en 2013 dans le RFC 6949. Une fois le cahier des charges décidé, une équipe spécialisée a été désignée par le RFC Editor pour mettre au point les détails, notamment en adaptant le langage XML utilisé, partant de la dernière version (RFC 7749), pour arriver au futur langage, RFC 7991. Des éditeurs professionnels ont également été consultés, ainsi d'autres SDO et même des juristes (oui, car aux États-Unis, rien n'est désormais à l'abri d'actions en justice, même pas les RFC, le choix du format de sortie PDF/A-3 venait en partie de la nécessité de répondre aux subpoenas). Le tout était bien sûr fait sous la supervision du RFC Series Oversight Committee. Certaines décisions furent consensuelles, les autres tranchées par le RFC Editor (cf. RFC 6635). Le tout a été approuvé par l'IAB en août 2016.

Après ce tour du passé, le futur. Comment se fera la transition vers le nouveau système (section 10) ? C'est qu'il va falloir créer de nouveaux outils (cf. RFC 7998). L'appel d'offres pour leur développement a été fait en septembre 2016. La description des outils est une très intéressante lecture (l'appel d'offres formel est sur la page des Request For Proposal). L'appel d'offres a été gagné par les sociétés SeanTek et Elf Tools.

Pendant une période intermédiaire, le texte seul sera toujours utilisé comme format canonique, mais les nouveaux RFC passeront également par le nouveau workflow, pour vérifier que tout se passe bien et que le résultat est correct. Double travail, donc, mais nécessaire pour s'assurer que tout est en place.

Notez que, même une fois la transition finie, les auteurs ne seront pas forcés de soumettre leur document sous forme d'un fichier XML (ils seront simplement très fortement encouragés à le faire). S'ils envoient le texte seul comme avant, le RFC Editor devra produire le XML lui-même, et c'est ce XML qui sera la version canonique. Rappelez-vous que beaucoup de RFC sont des documents normatifs et que chaque mot, voire chaque virgule peut compter ! Voici pourquoi il faudra s'assurer que tout est parfait, même si, au début, cela entrainera certainement des retards dans la publication.

Dans le cas où l'auteur envoie du XML suivant le RFC 7991, il y aura moins de travail pour le RFC Editor, juste convertir ce XML au XML canonique (résoudre les références extérieures, par exemple) et passer ce XML canonique dans les nouveaux outils.

Notez que le RFC Editor maintient une FAQ très utile sur toutes les questions que pose le nouveau format. Et la RFC Editor avait fait un très drôle Pecha Kucha à Séoul en novembre 2016, sur le cahier des charges du nouveau format.


Téléchargez le RFC 7990


L'article seul

RFC 7991: The "xml2rfc" Version 3 Vocabulary

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : P. Hoffman (ICANN)
Pour information
Première rédaction de cet article le 16 décembre 2016


Contrairement à beaucoup de SDO, l'IETF n'avait pas de format standard pour l'écriture de ses documents. Désormais, avec le nouveau cadre décrit dans le RFC 7990, c'est fait. XML, avec le vocabulaire décrit dans ce nouveau RFC, est le format canonique des RFC.

Vous voulez écrire un RFC ? Il est fortement recommandé d'utiliser dès le début le format standard XML, fondé sur un vocabulaire spécifique aux RFC, et mis en œuvre dans la future version de l'outil xml2rfc. Voici donc le vocabulaire « XML2RFC version 3 », succédant à deux versions qui n'étaient pas officiellement standard (les changements depuis la v2, spécifiée dans le RFC 7749, ne sont pas énormes). Notez que le vocabulaire XML et les outils continuent à évoluer, donc ce RFC n'est pas éternel. Et que la version 2 restera sans doute en service pendant encore des années : cela prend du temps de changer les habitudes !

Voici le squelette d'un Internet-Draft écrit avec ce XML :

      
    
<?xml version="1.0" encoding="utf-8"?>
<rfc docName="draft-ietf-dnsop-qname-minimisation-09" submissionType="IETF"
     ipr="trust200902">
<front>
<title abbrev="Qname minimisation">DNS query name minimisation to improve privacy</title>
...
<middle>
<section anchor="intro" title="Introduction and background">
<t>The problem statement is described in <xref
target="RFC7626"/>. [...]
...
</back>
</rfc>

    

Sur ce squelette simple, on voit l'élément racine (<rfc>), l'utilisation des attributs (comme submissionType qui indique la voie prise par le document, ici, l'IETF, cf. RFC 7841), la séparation en trois parties, <front>, qui regroupe les métadonnées, <middle>, qui est le texte principal, et <back>, où se trouvent la bibliographie, les annexes, etc.

Parmi les attributs de cet élément racine <rfc>, notez ipr, qui indique les conditions légales d'utilisation de ce RFC. Dans cet example, la valeur est la plus couramment utilisée : trust200902 (cf. l'annexe A.1) indique les règles de l'IETF Trust datant de 2009 (qui disent en gros que le texte du RFC peut être librement copié, reproduit, distribué et mis en œuvre dans des programmes). L'annexe A de notre RFC détaille ce qu'on appelle le boilerplate, ces textes juridiques obligatoires qui sont ajoutés automatiquement par le logiciel xml2rfc. Ainsi, si on met ipr="trust200902" dans l'élément <rfc>, xml2rfc va automatiquement ajouter « Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. \ This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents [...] »...

Le gros morceau du RFC est la section 2, qui donne la liste des éléments XML acceptés. Je ne vais pas reproduire ici cette liste, juste parler de quelques éléments qui me semblent rigolos.

<section> contient une partie du RFC. Cet élément est hiérarchique : on crée des sous-sections en les mettant sous les sections existantes, et ainsi de suite, récursivement. (Contrairement à ce qui se passe avec HTML, où on indique explicitement le niveau de la section, <h1>, <h2>, etc.) On a aussi <abstract>, qui indique le résumé au début du RFC.

<t> contient un paragraphe et est donc l'équivalent du <p> de HTML.

<artwork> permet de spécifier du texte qui sera représenté comme tel, sans aucune justification, mise à la ligne, etc. (Les tabulations sont interdites, ce qui règle le vieux débat « tabs vs. spaces ».) <artwork> permet de mettre de l'art ASCII dans un RFC, mais la méthode préférée pour les images est désormais SVG, voir le RFC 7996. Le SVG peut être mis directement dans le source XML ou bien inclus par différentes méthodes, dont l'attribut src. Cet attribut src permet de spécifier un fichier externe, l'art ASCII ne servant alors que de solution de secours, pour le format en texte seul. Un attribut type permet d'indiquer le type du dessin (par exemple svg pour les images en SVG). La liste des types possibles sera en ligne. Voici un exemple d'art ASCII :


<artwork type="ascii-art">
 +--------------+				     +----------------+
 |  Alice       |------------------------------------|      Bob	      |
 | 2001:db8::1  |                                    |   2001:db8::2  |
 +--------------+				     +----------------+
</artwork>

    

Le code source, lui, se fait avec l'élément <sourcecode>, un attribut type permettant d'indiquer le langage utilisé (une liste des valeurs possibles sera en ligne). Voici un exemple :

      
<sourcecode type="python">
	  print("Hello, world")
</sourcecode>
      
    

Comme le langage utilisé peut utiliser des caractères qui sont spéciaux pour XML (comme < ou &), il est souvent préférable de mettre le code source dans une section CDATA.

<eref> permet de faire un lien hypertexte vers l'extérieur :


      <t>More text and a <eref
      target="http://www.rfc-editor.org/">lien vers le site du RFC Editor</eref>.</t>
    
    

<ul> permet de représenter les traditionnelles listes à puces :


<t>There are three sorts of DNS requests being issued:</t>
<ul>
<li>Primary request: [...]</li>
<li>Secondary requests: [...]</li>
<li>Tertiary requests: [...]</li>
</ul>
    
    

<references> permet d'indiquer une bibliographie. Il y en a typiquement deux dans un RFC (cf. la section 4.8.6 du RFC 7322), la bibliographie normative (ce qu'il faut absolument avoir lu et compris car le RFC en dépend) et l'informative (ce qu'on peut sauter si on est pressé). Pour aider, le RFC Editor distribue des fichiers XML contenant les références aux RFC publiés, comme http://www.rfc-editor.org/refs/bibxml/reference.RFC.7626.xml.

Le nom d'un auteur de RFC se met avec l'attribut <author>. Comme il peut être en caractères non-ASCII, des attributs permettent d'indiquer une variante en ASCII seul. Par exemple :

      
<author fullname="Patrik Fältström" asciiFullname="Patrik Faltstrom">
	 <organization>Netnod</organization>
</author>

    

Ce format de RFC s'appuie sur XML et il faut donc suivre les règles de XML, notamment sur les caractères spéciaux. Ainsi, le chevron ouvrant doit être remplacé par une séquence d'échappement (&lt; au lieu de <). Si cette contrainte est trop forte, on peut aussi enclore les parties à « échapper » dans une section CDATA.

Le format des RFC permet d'autres caractères que ceux du jeu ASCII, mais avec certaines restrictions (voir RFC 7997).

Le format actuel permet l'inclusion d'autres documents, via des attributs comme l'attribut src pour le code source :

      
<sourcecode type="python" src="hello.py"/>

    

On peut aussi utiliser les mécanismes génériques d'inclusion de XML, comme XInclude (cf. annexe B.1) ou les entités, et c'est souvent utilisé pour la bibliographie :


   <!DOCTYPE rfc [
     <!ENTITY rfc7830 PUBLIC
     "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7830.xml">
   ]>

[...]
     <references>
       &rfc7830;
     </references>
	     
    

À noter qu'il existe un type MIME pour les sources XML de RFC, application/rfc+xml (section 8 de notre RFC).

Si vous voulez voir le schéma XML complet, il est en annexe C (j'en ai exporté une version utilisable telle quelle, sans les sauts de page des RFC, en rfc-v3.rnc). Comme il est écrit en Relax NG, il permet l'utilisation de tous les outils Relax NG, comme le mode emacs nxml-mode et comme rnv. Ainsi, une fois le fichier rfc-v3.rnc chargé dans emacs (menus XML puis Set schema puis File), on dispose de fonctions d'édition bien pratiques (par exemple, on tape un < puis une tabulation et emacs propose de compléter uniquement avec les éléments autorisés à cet endroit). Cela évite bien des erreurs.

À noter que ce RFC ne décrit que les éléments et attributs XML, pas de processing instructions (PI), qui ne sont plus acceptées.

Avec un logiciel comme rnv, on peut tester la syntaxe (uniquement la syntaxe : certaines contraintes dans le RFC ne sont pas exprimables dans le schéma, il a fallu les formuler en langue naturelle dans le texte du RFC) :

% rnv rfc-v3.rnc rfc-v3-sample.xml 
rfc-v3-sample.xml
    

Parfait, ici, tout est bon. S'il y avait eu une erreur :

% rnv rfc-v3.rnc rfc-v3-sample-wrong.xml      
rfc-v3-sample-wrong.xml
rfc-v3-sample-wrong.xml:9:6: error: element ^t not allowed
required:
	element ^section
rfc-v3-sample-wrong.xml:11:2: error: unfinished content of element ^middle
required:
	element ^section
error: some documents are invalid
    

Si le RFC contient des références externes (que rnv ne sait pas traiter), on peut utiliser xmllint pour les remplacer :

%  xmllint --dropdtd --noent draft-dupont-my-protocol.xml | rnv rfc-v3.rnc 
    

On peut aussi utiliser Jing (annexe C.1). Mode d'emploi très court, on télécharge :

% wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/jing-trang/jing-20091111.zip
% unzip jing-20091111.zip
% java -jar ./jing-20091111/bin/jing.jar  -c rfc-v3.rnc draft-dupont-my-protocol.xml
%
     

Les changements depuis le texte précédent, le RFC 7749, qui décrivait la version 2 (notre RFC est la version 3), sont décrits dans l'annexe D et résumés en section 1.3. L'idée était notamment d'avoir un vocabulaire plus facile à utiliser, sans pour autant trop changer par rapport au format v2, qui était bien connu des auteurs.

Le changement le plus spectaculaire concerne les listes, qui sont désormais faites, comme en HTML, avec des <dl>, <ul> et <ol>. Dans une liste, le contenu est marqué par <li> et plus <t>. Autre inspiration HTML, l'apparition des tables, avec <table> (et éléments associés comme <tr> et <td>). D'autre part, de nouveaux éléments apparaissent pour marquer du texte, par exemple s'il est important (<em>, qui n'avait pas d'équivalent en v2, dont le seul format de sortie était le texte brut). Il y a aussi un <blockquote> pour les citations. Bien que l'IETF se vante souvent de pratiquer le culte du « running code », il n'y avait pas d'élément XML particulier pour indiquer du code source dans un RFC (on se contentait d'<artwork>). C'est désormais fait avec <sourcecode>. Quelques autres éléments XML nouveaux (je ne les cite pas tous, le RFC fait 159 pages !) : <displayreference> pour associer un chouette texte aux références, <link> pour les liens externes (contrairement à <eref>, qui existait déjà, <link> est spécifique à certains types de documents, par exemple les Internet-Drafts) ou encore <br> pour forcer des sauts de ligne (mauvaise idée que de mettre des éléments de présentation, si vous voulez mon avis).

Il y a aussi de nouveaux attributs XML aux éléments existants. Pour remplacer les PI (processing instructions comme <?rfc toc="yes"?>), on a tocInclude et tocDepth dans l'élément <rfc>, afin de contrôler la table des matières. De même, pour gérer l'internationalisation, il y a désormais un attribut ascii pour les éléments qui acceptent du contenu non-ASCII, afin de fournir une alternative pour les anglophones. Il y a aussi des attributs plus orientés présentation comme keepWithNext ou keepWithPrevious, attributs de <t>, qui expriment un souhait de garder ce paragraphe avec le suivant ou le précédent, pour mieux contrôler la pagination.

En revanche, certains éléments et attributs sont retirés de la circulation. Ils seront encore acceptés par les outils, mais temporairement. <list> subit ce trist sort (remplacé par les éléments HTMLisant comme <ul> et <ol>). <facsimile> disparait également, victime des évolutions technologiques. Parmi les attributs, title disparait (il était utilisé dans des éléments comme <section>) au profit de name (changement assez gratuit, je trouve).

Les autres changements sont bien sûr l'acceptation de caractères non-ASCII, et plein de modifications de détail.

Question mise en œuvre, il faudra patienter. S'il y a déjà eu des mises en œuvre expérimentales et partielles, les vrais logiciels officiels ne sont pas encore, en octobre 2016, développés.


Téléchargez le RFC 7991


L'article seul

RFC 7997: The Use of Non-ASCII Characters in RFCs

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : H. Flanagan (RFC Editor)
Pour information
Première rédaction de cet article le 16 décembre 2016


Les RFC sont forcément écrits en anglais, qui restera la langue officielle (cf. RFC 7322). L'anglais peut s'écrire avec uniquement les caractères ASCII (avec quelques exceptions : resume et résumé ne sont pas le même mot). Mais on pourra désormais inclure des caractères non-ASCII, par exemple pour le nom des auteurs (chic, je pourrais écrire correctement mon prénom dans les RFC). Cette possibilité permettra aussi aux exemples de protocoles Internet utilisant Unicode (la grande majorité) d'être plus lisibles.

Cette nouvelle possibilité fait partie de celles qu'offre le nouveau format des RFC, décrit dans le RFC 7990. Il n'y a quand même pas d'autorisation générale d'inclure n'importe quel caractère Unicode dans les RFC, à n'importe quel endroit. Le RFC Editor pourra toujours refuser tel ou tel caractère, par exemple parce qu'il n'existe pas de police permettant de l'afficher. Et le « non-ASCII » n'est autorisé que dans certains cas, décrits plus loin. La grande majorité du texte sera donc du pur ASCII (RFC 20).

L'encodage de ces caractères sera bien sûr UTF-8.

Il ne suffit pas de proclamer « on a droit à Unicode ». Il faut aussi adapter les outils. Par exemple, notre RFC impose (section 2) que les outils de recherche dans les RFC gèrent correctement la recherche Unicode. (C'est pour traiter le cas des outils imparfaits que le RFC demande aussi que les noms d'auteurs en Unicode soient accompagnés d'une version en ASCII.) Et que le RFC soit affichable correctement sur un bon nombre de plate-formes (d'où la possibilité de rejeter les caractères les plus rares).

Ce problème du repli (vers une version en ACSII pur) est souvent cité dans le RFC. Ainsi, lorsqu'on veut mentionner un caractère Unicode (mettons le thorn islandais) RFC permet désormais de l'afficher proprement, mais il demande qu'on l'accompagne du numéro du point de code, et, si possible, de son nom Unicode. Cela donnerait, par exemple « For instance, U+00FE, "LATIN SMALL LETTER THORN", þ, is interesting because... ». Notez que cette façon de désigner des caractères Unicode que tout le monde n'arrivera pas forcément à afficher n'est pas vraiment standardisée. Dans les RFC actuels, on trouve des variantes (voir cette discussion). Le RFC contient plusieurs exemples sur la façon d'écrire la phrase « Temperature changes in the Temperature Control Protocol are indicated by the U+2206 character (∆, "INCREMENT") », tous acceptés (le nom Unicode n'est pas obligatoire, il peut être placé avant ou après le caractère lui-même, etc.) Autre cas, ce texte du RFC 7564, « For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block look similar to the ASCII characters "STPETER" » deviendrait « For example, the characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 (ᏚᎢᎵᎬᎢᎬᏒ) from the Cherokee block look similar to the ASCII characters "STPETER" ». Des tables comme celles des identificateurs et mots de passe Unicode légaux (RFC 7613) seraient ainsi bien plus lisibles.

Pour les noms, par exemple ceux des auteurs. On aurait du « non-ASCII » et un texte de repli, comme (en utilisant le vocabulaire XML du RFC 7991) :

    
<author fullname="רוני אבן" asciiFullname="R. Even"/>
<author fullname="吴钦" asciiFullname="Q. Wu"/>
<author fullname="J. Smith" asciiFullname="J. Smith"/> <!-- Oui, dans
ce cas, il faut le dire deux fois -->

  

Cela permettra enfin d'écrire correctement les noms des auteurs de RFC.

La bibliographie d'un RFC est également un bon endroit où mettre des caractères Unicode, par exemple lorsqu'on cite des textes non-anglo-saxons. Ainsi, la bibliographie du RFC 5933 pourrait inclure :

[GOST3410] "Information technology. Cryptographic data security.
           Signature and verification processes of [electronic]
           digital signature.", GOST R 34.10-2001, Gosudarstvennyi
           Standard of Russian Federation, Government Committee of
           Russia for Standards, 2001. (In Russian)

           "Информационная технология. Криптографическая защита
           информации. Процессы формирования и проверки
           электронной цифровой подписи", GOST R 34.10-2001,
           Государственный стандарт Российской Федерации, 2001.

Le second texte étant l'original russe.

Les règles exactes figurent dans la section 3. D'abord, on peut mettre du « non-ASCII » comme on veut quand il fait partie d'un exemple. Ainsi, la communication XMPP pourrait être décrite de manière plus naturelle. Au lieu de cet exemple de communication en tchèque (RFC 6121) :

  
   <message
       from='juliet@example.com/balcony'
       id='z94nb37h'
       to='romeo@example.net'
       type='chat'
       xml:lang='en'>
     <body>Wherefore art thou, Romeo?</body>
     <body xml:lang='cs'>
        Pro&#x010D;e&#x017D; jsi ty, Romeo?
      </body>
   </message>

On pourra écrire la forme lisible :

  
   <message
       from='juliet@example.com/balcony'
       id='z94nb37h'
       to='romeo@example.net'
       type='chat'
       xml:lang='en'>
     <body>Wherefore art thou, Romeo?</body>
     <body xml:lang='cs'>
        PročeŽ jsi ty, Romeo?
      </body>
   </message>

Ensuite, on peut utiliser le « non-ASCII » pour les cas cités plus haut (noms d'auteurs, textes non-anglophones dans la bibliographie, etc). Pour les exemples utilisant un langage de programmation, notre RFC spécifie qu'il faut suivre les règles du langage en question. Ainsi, Python 3 autorisant l'Unicode même dans les noms de variables, on peut écrire :

    
a = "chocolat" 
b = "café"       # Accentué
ç = "lait"
print(a+b+ç)

  

Enfin, un petit mot sur la normalisation Unicode, pour rappeler que le format des RFC ne garantit rien à ce sujet (on aurait pu décider que NFC serait systématiquement utilisée...) et que les auteurs de RFC ne doivent donc pas compter dessus.


Téléchargez le RFC 7997


L'article seul

RFC 7996: SVG Drawings for RFCs: SVG 1.2 RFC

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : N. Brownlee (University of Auckland)
Pour information
Première rédaction de cet article le 16 décembre 2016


Dans la longue liste de RFC décrivant le nouveau format des RFC (commencez par le RFC 7990), ce document décrit l'utilisation de SVG pour faire (enfin) des graphiques dans les RFC.

Traditionnellement, en effet, seul le texte était possible dans les RFC. (On pouvait toutefois faire des graphiques en art ASCII, dont on imagine bien que ce n'était ni très pratique à écrire - malgré l'excellent mode Emacs picture-mode, ni très facile à lire.) Il y avait de bonnes raisons à cet état de fait, notamment le manque d'un format d'images ouvert et largement répandu. Je parle bien sûr d'images vectorielles car, a priori, dans un RFC, il y aura beaucoup plus de schémas que de photos.

Le processus de décision a été long et compliqué. En 2013, le RFC 6949 notait déjà la décision de permettre des images, en indiquant « Graphics may include ASCII art and a more complex form to be defined, such as SVG line art ». C'est désormais possible. Au fait, c'est quoi, SVG ? Il s'agit d'une norme d'un format d'images vectoriel, gérée par le W3C, et fondée sur XML. Voici un exemple d'un simple dessin en SVG :


<svg xmlns="http://www.w3.org/2000/svg" version="1.2">
  <rect x="25" y="25" width="200" height="200" fill="white" stroke-width="4" stroke="black" />
  <circle cx="125" cy="125" r="75" fill="black" />
  <polyline points="50,150 50,200 200,200 200,100" stroke="black" stroke-width="4" fill="none" />
  <line x1="50" y1="50" x2="200" y2="200" stroke="white" stroke-width="4" />
</svg>

Et voici son rendu :

Les RFC n'utiliseront qu'un sous-ensemble de SVG, spécifié ici. Il existe d'autres sous-ensembles de SVG comme SVG Tiny, prévu pour des équipements contraints, genre smartphones. Ce SVG Tiny a servi de base au SVG des RFC, sous-ensemble limité car on n'attend pas de dessins artistiques et compliqués dans les RFC.

SVG RFC est donc SVG Tiny moins les éléments permettant le multimédia et l'animation (pas de vidéos dans les RFC), l'interaction (pas d'interface utilisateur active dans un RFC), l'utilisation de langages de programmation (pas de JavaScript actif dans un RFC). Plusieurs autres restrictions ont été apportées : pas de couleur (RFC 6949, section 3.2), pas d'IRI, seulement des URI, et pas de choix arbitraire de police.

Comment on écrit du SVG ? S'il est évidemment possible de le faire entièrement à la main avec un éditeur ordinaire, gageons que peu de gens le tenteront. Notre RFC cite des éditeurs graphiques, produisant du SVG, comme les logiciels libres Inkscape et Dia. (Et, si on aime programmer en Python, il y a svgwrite, que je présente plus en détail à la fin.) Attention, Inkscape et Dia produisent du SVG généraliste, pas du SVG RFC, qui est plus restreint. (Je ne connais personnellement pas d'outil pour produire du SVG RFC, ou pour « réduire » un fichier SVG généraliste en enlevant tout ce qui n'appartient pas à SVG RFC. Un tel outil était prévu mais je ne sais pas où il en est. C'était une des fonctions attendues du futur svgcheck.)

Et l'accessibilité (section 4) ? Il est crucial que les RFC soient accessibles à tou·te·s, non seulement que que soit le matériel utilisé, mais également quels que soient les handicaps dont souffre leur propriétaire. C'est bien joli de vouloir ajouter des tas de choses dans les RFC mais encore faut-il ne pas creuser ainsi davantage le fossé entre les utilisateurs. Ainsi, accepter de la couleur (le RFC 6949 limite les futurs RFC au noir et blanc) fait courir le risque que les daltoniens ne puissent pas comprendre un RFC. De même, les graphiques, qui ont l'air comme ça d'être une bonne idée, peuvent aggraver la situation des malvoyants. Le texte seul peut toujours être lu à voix haute par un synthétiseur de parole mais pas le graphique. Comme le note le RFC avec humour, « lire le source SVG à voix haute ne va pas le faire ».

Le texte « Tips for Creating Accessible SVG » donne des bons conseils pour faire du SVG accessible. Et il y a bien sûr la norme ARIA, dont il existe une introduction et de bons exemples. (Désolé, je n'ai pas suivi ces excellents principes dans les exemples ci-dessous, mais j'accepte les patches.)

Si vous voulez voir des exemples concrets, regardez https://www.cs.auckland.ac.nz/~nevil/SVG_RFC_1.2/. Ainsi, l'exemple de schéma d'un en-tête TCP donnera : Et le schéma de la communication SIP du RFC 4321 fera 

L'annexe A de notre RFC donne un schéma complet (formulé en Relax NG) du SVG des RFC. Il est extrait ici dans le fichier svg-rfc.rnc, que vous pouvez utiliser pour tester la conformité de vos SVG. Par exemple, avec rnv :

% rnv files/svg-rfc.rnc files/tcp-header.svg  
files/tcp-header.svg
    

En revanche, avec du SVG trop « riche » (ici, utilisant les couleurs), on aurait :

% rnv files/svg-rfc.rnc /tmp/test1.svg 
...
/tmp/test1.svg:2:267: error: attribute ^fill with invalid value "red"
required:
	value ^token "none"
	value ^token "black"
	value ^token "white"
	value ^token "#000000"
	value ^token "#FFFFFF"
	value ^token "#ffffff"
	value ^token "inherit"
    

Une alternative, pour tester la validité des SVG conformes à ce profil, sera svgcheck quand il sera développé.

Avec Inkscape, il faut veiller à sauver le fichier en Plain SVG (autrement, on a des ennuis avec les éléments spécifiques d'Inkscape, ex-Sodipodi). Mais il reste malgré cela deux ou trois trucs à corriger manuellement, avant que le document produit par Inkscape soit accepté. Pour Dia, il faut utiliser l'action Export (par défaut, Dia n'enregistre pas en SVG), mais Dia produit alors un document avec une DTD. Si on la retire (manuellement, ou bien avec xmllint --dropdtd), tout se passe bien, le document SVG est alors conforme au profil demandé pour les RFC.

Autre solution que j'aime bien pour faire du SVG, dès qu'on a des éléménts répétitifs et qu'on veut donc automatiser (en Python), svgwrite. Ce schéma en art ASCII :

 +--------------+				     +----------------+
 |  Alice       |------------------------------------|      Bob	      |
 | 2001:db8::1  |                                    |   2001:db8::2  |
 +--------------+				     +----------------+
    

aurait pu être créé avec svgwrite avec network-schema-svgwrite.py, qui donne

Bien sûr, pour un schéma aussi simple, le gain n'est pas évident, mais il le devient pour les schémas comportant beaucoup d'éléments récurrents. Mais notez que svgwrite ne connait pas le profil « SVG pour RFC » et, par défaut, peut donc produire des SVG invalides (par exemple avec de la couleur). Le programmeur doit donc faire attention.


Téléchargez le RFC 7996


L'article seul

RFC 7995: PDF Format for RFCs

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : T. Hansen (AT&T Laboratories), L. Masinter, M. Hardy (Adobe)
Pour information
Première rédaction de cet article le 16 décembre 2016


Parmi les nombreux formats de publication des RFC prévus suite à l'adoption du nouveau format (RFC 7990), ce RFC décrit l'utilisation de PDF. On pourra donc, en suivant ces règles, avoir une jolie version papier des RFC.

Actuellement, les RFC peuvent bien sûr être imprimés mais c'est un peu tristoune (cf. annexe A). Avec le nouveau cadre de gestion des RFC, le format canonique du RFC sera du XML (RFC 7991), à partir duquel seront produits automatiquement (par des outils qui ne sont pas encore développés) divers formats. HTML sera sans doute le principal pour une publication en ligne (RFC 7992), mais il y a des partisans de PDF, surtout pour l'impression sur le bon vieux papier. Ce RFC 7995 décrit donc l'utilisation de PDF comme format de sortie pour les RFC. À noter que ce format, créé et piloté par une entreprise privée n'est pas à proprement parler un « format Internet » et est sans doute moins connu des participants à l'IETF que ne l'est HTML.

La norme PDF est déposée à l'ISO (ISO 32000-1) mais l'archaïque ISO ne distribue toujours pas librement ces documents. Si on veut apprendre PDF, il faut donc le télécharger sur le site d'Adobe.

Première question (section 2 de notre RFC), quelle version de PDF choisir ? PDF a évolué dans le temps, chaque version ajoutant de nouvelles fonctions. C'est aujourd'hui un format très complexe, difficile à mettre en œuvre complètement. C'est pour cela qu'il existe des profils de PDF, restreignant ce format pour des usages spécifiques. Ainsi, PDF/X est conçu pour l'échange de fichiers avec l'imprimeur. Pour les RFC, documents souvent normatifs, et à longue durée de vie, les exigences principales sont l'accessibilité et la stabilité. C'est ce que fournissent les profils PDF/UA (accessibilité) et PDF/A-3 (archivage à long terme).

Pour les RFC, les profils choisis sont la version 1.7 de PDF, suffisamment ancienne pour être gérée par la plupart des logiciels, le profil PDF/A-3 pour limiter le nombre de fonctions à gérer, et PDF/UA pour l'accessibilité.

La section 3 de notre RFC détaille ensuite toutes les exigences particulières des RFC, pour le format de sortie PDF. Je ne les commente pas toutes ici, seulement celles qui me semblent importantes. Par exemple, la délicate question des polices. PDF permet d'inclure une police dans le document, ou bien de se référer simplement à une police par son nom. Dans ce dernier cas, si le logiciel qui lit le PDF ne trouve pas exactement cette police, il se rabat sur une police « proche », avec un résultat qui n'est pas forcément satisfaisant. De toute façon, PDF/A, le profil « archivage » impose d'inclure la police utilisée, pour éviter de dépendre de logiciels futurs. À noter que cela peut impliquer de payer : peu de polices sont gratuites pour l'auteur. L'annexe C.4 discute des polices acceptables. Il y a les gratuites, mais sans support Unicode complet, comme Source Sans Pro, Source Serif Pro ou Source Code Pro. Bien meilleure du point de vue de la couverture Unicode, mais payante, est Skolar. L'idéal sera peut-être la nouvelle police Noto. Les RFC ayant maintenant le droit d'utiliser des caractères non-ASCII, mais avec des restrictions (cf. RFC 7997), il est possible que des caractères soient refusés par le RFC Editor uniquement parce qu'ils ne sont pas présents dans les polices utilisées.

Le choix des caractéristiques des polices (chasse fixe ou variable, empattement ou pas) devra suivre les mêmes règles que pour HTML et CSS, règles qui figurent dans le RFC 7993. À propos de HTML, notons d'ailleurs que notre RFC sur PDF demande que le PDF ressemble visuellement autant que possible au document HTML. Si vous écrivez un logiciel qui produit le PDF pour un RFC et que vous hésitez sur tel ou tel aspect graphique, consultez le RFC 7992 sur la sortie HTML.

Parmi les autres exigences pour la production de PDF, notre RFC demande qu'on évite les césures.

PDF permet de mettre des liens hypertextes. L'intérêt est faible puisque PDF est surtout utilisé pour le papier (si on regarde sur un écran PDF n'a aucun avantage par rapport au format bien plus ouvert qu'est HTML), mais le RFC prévoit quand même cette possibilité. Il y aura donc des liens, à la fois externes (vers des URL, y compris vers d'autres RFC et, dans ce cas, le RFC 7322 requiert que cela soit vers la page d'information officielle du RFC Editor) et internes (une section du RFC référençant une autre). Les liens internes sont parfois produits automatiquement (par exemple depuis la table des matières vers les sections du texte).

Un problème délicat est celui de la façon dont le texte est stocké dans le document PDF. PDF permet en effet plusieurs façons de réaliser ce stockage. Elles donnent le même résultat visuel mais se comportent différemment pour des fonctions comme la recherche de texte. Ainsi, le mot « IETF » peut être stocké comme une image, comme quatre lettres positionnées indépendamment, ou comme un mot unique. Le stockage en image posera évidemment des problèmes aux outils comme pdftotext (mais ce n'est pas forcément grave pour les RFC, on a toujours le source XML) ou aux outils de synthèse vocale, nécessaires aux malvoyants. Pour la recherche de texte, la solution du mot unique est certainement meilleure, même si elle ne permet pas une typographie aussi subtile. Mais il y a aussi le placement des phrases. La phrase « The IETF supports the Internet » peut être stockée comme cinq mots différents stockés indépendamment (y compris dans un ordre différent de celui de la phrase) et positionnés ensuite, ou bien comme un objet unique.

Notre RFC recommande d'au moins garder les mots dans l'ordre du texte (PDF/UA l'impose).

Pour les images, si le source XML contenait à la fois de l'art ASCII et du SVG, notre RFC impose bien sûr qu'on utilise le SVG pour produire le PDF. Le texte alternatif aux images, indispensable pour l'accessibilité, doit être mis dans le PDF (dans la propriété /Alt).

Les métadonnées (noms des auteurs, date, etc) sont très utiles pour l'indexation et la recherche et doivent donc être mises dans le PDF. PDF a plusieurs façons d'embarquer des métadonnées, et la recommandation est d'utiliser XMP.

Parmi les zillions de fonctions de PDF, il peut agir en container d'autres fichiers (oui, comme tar ou AVI). Tous les logiciels PDF ne savent pas extraire ces fichiers embarqués dans le PDF mais c'est une fonction utile, au cas où. Le RFC recommande donc que des fichiers utiles soient ainsi embarqués : le source XML du RFC, les codes sources (dans les éléments <sourcecode> du RFC), les images (dont les sources SVG)...

Dernier point, les éventuelles signatures. Pour l'instant, il n'y a pas de mécanisme standard pour signer les RFC et en garantir l'authenticité mais, lorsque ce sera le cas, PDF permettra d'inclure une signature dans le fichier produit. (Cette fonction existe dans PDF depuis longtemps.)

Le RFC contient aussi trois annexes intéressantes. L'annexe A est un historique de la relation compliquée entre les RFC et PDF. Depuis longtemps, une version PostScript du RFC était acceptée par le RFC Editor et publiée, même si très peu d'auteurs en ont profité. Cela concernait surtout les RFC ayant des images ou des formules mathématiques comme les RFC 1119 ou RFC 1142. Le PDF produit par le RFC Editor pour tous les RFC (ou par https://tools.ietf.org/) n'était, lui, qu'une simple « impression » du RFC en texte brut.

L'annexe B rappelle ce que doit faire un bon logiciel de production de contenu imprimé, avec découpage en pages. C'est plus dur que cela n'en a l'air, car il faut gérer les veuves et les orphelines, ne pas couper juste après le titre d'une section, ne pas couper les dessins en art ASCII, placer les tableaux intelligemment, etc.

Enfin, l'annexe C décrit une partie des outils disponibles pour le producteur de documents PDF. Si les logiciels de visualisation sont nombreux, il faut noter que tous n'ont pas la totalité des fonctions qu'utilise le format de sortie des RFC (par exemple les liens hypertexte). Du côté des imprimantes (le papier étant le but final de la plupart des documents PDF), certaines savent même gérer le PDF directement (dans les autres cas, ce sera au logiciel de visualisation de produire le format attendu par l'imprimante, souvent PostScript).

Et pour produire le PDF à partir du XML des RFC ? Une solution possible, puisqu'il existe une feuille de style XSLT (disponible en ligne) est de produire du FO qui sera ensuite transformé en PDF, par exemple avec FOP (je n'ai personnellement eu que des expériences décevantes avec FO). Mais il existe plein de bibliothèques qui produisent du PDF, et qui pourraient être utilisées.

Comme notre RFC impose l'utilisation de profils de PDF comme PDF/A, un outil important est le logiciel de vérification qui s'assure que le résultat est bien conforme aux exigences de ce profil. Pour l'instant, il semble qu'il n'existe pas grand'chose dans ce domaine. Il faudra donc compter sur l'outil de production de PDF pour qu'il fasse un travail correct.


Téléchargez le RFC 7995


L'article seul

RFC 7994: Requirements for Plain-Text RFCs

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : H. Flanagan (RFC Editor)
Pour information
Première rédaction de cet article le 16 décembre 2016


Dans la grande série des nombreux RFC spécifiant le nouveau format de ces documents (avec XML étant désormais la référence), ce court RFC décrit le format de publication « texte brut » des RFC.

En effet, si le format « texte brut » n'est plus la référence des RFC, ce format reste toujours utile. Dans le nouveau mécanisme (RFC 7990), il y a désormais plusieurs formats de publication, obtenus à partir du format canonique (celui qui est en XML). Le texte brut est l'un d'eux. Ce format, historiquement le seul utilisé par les RFC, ne disparait pas, mais perd de son importance. Il n'est plus qu'un des formats de publication parmi d'autres (comme HTML, voir le RFC 7992). Le RFC 6949 expliquait ce choix.

À noter que les RFC produits avant ce changement ne sont pas affectés : leur format de référence reste le texte brut (et en ASCII seul).

Bon, désormais, on aura un format de sortie (parmi d'autres) en « texte seul » ou « texte brut ». Mais c'est quoi, le texte brut ? Notre RFC reprend la définition du consortium Unicode : « du texte encodé pour les ordinateurs composé uniquement de points de code d'une norme donnée, sans instructions de format ou de structure ». Bref, les caractères indiqués ne valent que pour eux-mêmes, ils n'indiquent jamais de formatage ou de style. Selon cette définition, HTML, LaTeX et Markdown (RFC 7763) ne sont donc pas du texte brut. (La définition n'est pas 100 % parfaite. La norme Unicode, par exemple, inclut des caractères qui influencent le format.) Le texte brut est donc ce qui est le plus portable : tous les acteurs qui connaissent la norme de jeu de caractères sous-jacente (aujourd'hui, quasiment toujours Unicode) peuvent lire et écrire du texte brut. C'est d'ailleurs une des raisons pour lesquelles les RFC ont si longtemps gardé ce format comme format canonique.

Mais si le texte brut n'est pas idéal comme format de référence, il reste un format de sortie très utile, notamment pour son interopérabilité, ou en raison de l'existence de nombreux outils qui peuvent le traiter (à commencer par grep...) Désormais, donc, le format canonique est le XML décrit dans le RFC 7991 et le texte brut sera produit automatiquement par les nouveaux outils. Mais ce texte brut a des règles qui sont légèrement différentes du texte brut original (« RFC canal historique ») et notre RFC 7994 les décrit. Il est très court, car le format « texte brut » est un format simple.

D'abord, le jeu de caractères (section 2). Ce sera bien sûr Unicode, mais avec les restrictions indiquées dans le RFC 7997. En pratique, là où les caractères non-ASCII ne sont pas autorisés, il faudra utiliser l'ASCII équivalent, donné dans les attributs XML prévus à cet effet (ascii, RFC 7991 en section 2.23.1, asciiFullname en 2.7.1, etc). L'encodage sera obligatoirement UTF-8 (RFC 3629). Curieusement, il est prévu de mettre une BOM au début du document.

Que faire avec les graphiques, désormais autorisés par le RFC 7990, et écrits en SVG (RFC 7996) ? Ces graphiques sont, dans le source XML, à l'intérieur d'un élément <artwork>. Comment les rendre dans du texte brut (section 3 de notre RFC) ? D'abord, si le graphique n'est pas en SVG mais dans le traditionnel art ASCII (indiqué par type=ascii-art), on utilise cet art ASCII. Autrement, notre RFC ne propose pas de solution générale. Il est recommandé aux auteurs de diagrammes et schémas de prévoir une alternative en art ASCII, même quand ils font du SVG.

Enfin, la section 4 du RFC couvre le problème de la « mise en page ». Un caractère de fin de page (U+000C) sera inclus automatiquement toutes les 58 lignes (les outils auront probablement une option pour ne pas inclure de telles marques). L'outil devra gérer le délicat problème des veuves et des orphelines. Les lignes feront 72 caractères, suivies de deux caractères marquant la fin (U+000D U+000A).

Les textes de début du RFC (RFC 5741) seront automatiquement mis comme avant, mais les en-têtes et pieds de page disparaissent. Autre disparition, il n'y aura plus, dans le format de sortie en texte brut, de numéros de pages dans la table des matières (dommage, je trouve, mais c'est au nom de la cohérence avec les autres formats de sortie).


Téléchargez le RFC 7994


L'article seul

RFC 7993: Cascading Style Sheets (CSS) Requirements for RFCs

Date de publication du RFC : Décembre 2016
Auteur(s) du RFC : H. Flanagan (RFC Editor)
Pour information
Première rédaction de cet article le 16 décembre 2016


Le nouveau format des RFC, décrit dans le RFC 7990, prévoit un format canonique, XML, à partir duquel seront automatiquement produits des versions texte brut, PDF, etc. Il y aura évidemment la possibilité de produire une version HTML (RFC 7992) et celle-ci sera bien sûr « stylée » avec CSS. Ce RFC décrit donc le cahier des charges de la feuille de style CSS à développer, avec tous les mots-clés du moment (comme responsive design).

Cette future feuille de style sera le style par défaut (le lecteur pourra toujours la redéfinir). Son but (section 2 du RFC) est de respecter le contenu du RFC (ceux-ci sont parfois des normes : pas question de toucher au texte !) tout en permettant une accessibilité maximale, pour tous les lecteurs, quelle que soit la machine qu'ils utilisent pour accéder au Web.

Plus précisément, la section 3 exige de :

  • Coller aux marquages sémantiques du RFC 7992,
  • Permettre l'accessibilité même aux gens en situation de handicap, comme décrit dans les « Best Practices for Authoring HTML »,
  • Permettre l'utilisation de petits écrans (ce qu'on appelle à tort les mobiles, alors que certains mobiles ne posent aucun problème particulier, car ils ont de grands écrans). Normalement, depuis le tout début du Web, c'est fait automatiquement, car le Web a toujours été prévu pour spécifier un contenu, pas une apparence. Mais certains pratiques ont mené à des pages Web très encombrées, difficiles à réduire automatiquement, ce qui a mené au mouvement du responsive design,
  • Permettre l'utilisation d'écritures diverses, pas juste l'alphabet latin, les RFC permettant désormais des caractères non-ASCII (cf. RFC 7997).

La section 4 donne ensuite les principes de présentation à suivre. Je ne vais pas les reprendre ici dans leur intégralité mais on y trouve :

  • Le code source et les exemples de déroulement d'un protocole réseau seront en chasse fixe, ainsi que l'art ASCII,
  • Le texte devra se réagencer selon la taille de l'écran (ce qui devrait quand même aller de soi quand il s'agit de Web !),
  • Les paragraphes auront un identificateur qui devra être affiché lorsque le pointeur (par exemple la souris) passe au-dessus d'eux,
  • La police par défaut pour l'écran sera sans empattement, inclura Unicode, et sera disponible pour tous les navigateurs importants, avec une licence la rendant disponible.

Il y aura également une feuille de style pour l'impression (comme pour le blog que vous êtes en train de lire, d'ailleurs.) La police par défaut sera cette fois avec empattement.

Enfin, la section 7 et l'annexe A de notre RFC font la liste des classes CSS employées. Par exemple, .pilcrow sera utilisé pour les marques de paragraphe, qui ne seront affichées que lorsque le pointeur passera dessus. .url servira à marquer les URL de manière visuellement distinctive. La classe .cref ne servira que dans les Internet-Drafts, pour afficher les commentaires, mais pas dans les RFC (où les commentaires des auteurs sont supprimés).

La merveilleuse feuille de style qui met en œuvre ces exigences n'est pas encore finie. Un appel d'offres a eu lieu (après relecture). Et on peut voir la feuille temporaire en ligne (pour le développement et les commentaires, c'est sur Github).


Téléchargez le RFC 7993


L'article seul

BCP 38, ne pas laisser des adresses IP usurpées sortir de son réseau

Première rédaction de cet article le 7 décembre 2016


Qu'est-ce que ça peut bien être, « BCP 38 » ? Ce terme désigne un ensemble de documents de bonnes pratiques pour les acteurs de l'Internet, plus spécialement les opérateurs réseaux : il ne faut pas laisser sortir de son réseau des paquets ayant une adresse source usurpée. Le respect de ce principe permettrait de lutter contre certaines attaques par déni de service sur l'Internet. Ce principe est formalisé dans deux RFC, les RFC 2827 et RFC 3704.

« BCP » veut dire « Best Current Practice ». Le but de cet étiquetage est de pointer vers le ou les RFC qui décrivent la pratique en question. En effet, un RFC, une fois publié, n'est jamais modifié, alors que le monde, lui, change. C'est ainsi que le RFC 7525, parlant de TLS est décrit par l'étiquette BCP 195 : les bonnes pratiques, en matière de cryptographie, changent vite. Une étiquette BCP peut pointer plusieurs RFC. Un bon exemple est le BCP 47, sur les étiquettes de langue, qui pointe vers les RFC 5646 et RFC 4647.

C'est également le cas de BCP 38, qui désigne le RFC 2827, avec les additions du RFC 3704.

Le problème que vise à résoudre ce BCP est celui de l'usurpation d'adresse IP par un attaquant qui voudrait faire du déni de service sans révéler son adresse, ou bien en faisant une attaque par réflexion. Par défaut, dans l'Internet, il est trivial d'émettre des datagrammes avec une adresse source mensongère. BCP 38 dit que les opérateurs réseaux devraient interdire cette pratique, en configurant leurs routeurs à cette fin. Par exemple, si un FAI a deux préfixes IP, 192.0.2.0/24 et 2001:db8::/32, il n'y a aucune raison valable de laisser sortir du réseau du FAI des paquets ayant comme adresse IP source, mettons, 203.0.113.65.

Notons qu'un déploiement systématique de BCP 38 résoudrait un certain nombre de problèmes de sécurité sur l'Internet, mais pas tous. Ainsi, si l'attaquant dispose d'un botnet, et fait une attaque directe (pas par réflexion), il n'a pas vraiment besoin de mentir sur ses adresses IP source, ce ne sont pas les siennes, de toute façon (usurper l'adresse source aurait quand même quelques avantages, ça dépend des cas).

Aujourd'hui, le déploiement de BCP 38 dans l'Internet n'est pas inexistant mais il est très inégal. Par exemple, la situation est bien meilleure en Europe qu'en Asie. Un attaquant qui veut faire de l'usurpation d'adresses IP a donc encore pas mal de réseaux à sa disposition.

Pourquoi est-ce que tout le monde n'a pas déployé BCP 38, malgré le très large consensus qui existe parmi les professionnels ? La principale raison est économique. Un opérateur qui déploie BCP 38 (tous les routeurs permettent de le faire, soit en n'autorisant que ses propres préfixes, soit par des astuces comme RPF) aide les autres. Imaginez l'ingénieur allant voir le directeur financier et lui disant « on va dépenser de l'argent, et le ROI ira entièrement à nos concurrents »... Comme en écologie, c'est donc un cas typique où le sacro-saint marché ne peut pas aboutir à une bonne solution.

Notez que tester si un FAI donné met en œuvre ou pas BCP 38 est un peu plus compliqué que cela peut sembler au premier abord. Je connais par exemple une box très utilisée en France qui bloque les paquets IPv4 ayant une adresse IP source usurpée (par effet de bord du NAT) mais qui ne le fait que pour des flots existants ou pour des paquets de début d'un flot. Si on envoie un paquet TCP sans bit SYN, il passe malgré son adresse usurpée...

Quelques lectures pour approfondir :


L'article seul

Fiche de lecture : The Internet of money

Auteur(s) du livre : Andreas Antonopoulos
Éditeur : Merkle Bloom
9781537000459
Publié en 2016
Première rédaction de cet article le 5 décembre 2016


Ce petit livre rassemble le texte de plusieurs conférences d'Andreas Antonopoulos au sujet de Bitcoin. Les textes ont été édités, les erreurs corrigées, mais le ton reste celui des conférences de l'auteur, passionnantes et brillantes. Sa thèse principale est que le Bitcoin n'est pas juste une monnaie, c'est un mécanisme sur lequel on va pouvoir bâtir plein de nouvelles relations économiques, c'est l'Internet of money. Et les vieux dinosaures du monde actuel peuvent toujours critiquer, et prétendre que le Bitcoin n'a pas d'avenir, Antonopoulos démonte tous leurs arguments. (Les conférences elles-mêmes sont visibles en ligne.)

C'est donc vraiment le bouquin à faire lire aux gens qui expliquent doctement que le Bitcoin n'est pas une monnaie réelle, ou bien que ce n'est qu'une expérience d'une poignée de gusses dans leur garage. Antonopoulos est très pédagogue... et très militant.

Il n'a pas de mal à rappeler que les arguments contre le Bitcoin sont à peu près les mêmes que ceux employés par les messieurs sérieux et les experts médiatiques contre l'Internet (ou, puis-je ajouter, contre Unix et contre le logiciel libre) : c'est juste une expérience, ce n'est pas sérieux, c'est un truc de hippies libertariens, cela ne durera pas. Pourquoi croirait-on aujourd'hui ces mêmes experts ? D'où le titre du livre, qui fait allusion au fait que l'auteur prédit au Bitcoin le même succès que l'Internet : déranger les systèmes en place, permettre de nouvelles possibilités, reposer les questions. « Dire que le Bitcoin est une monnaie numérique, c'est aussi réducteur que dire que l'Internet est un téléphone amélioré. »

Un concept intéressant dans une des conférences est celui d'inversion de l'infrastructure. Au début, la nouvelle technologie utilise une infrastructure conçue pour la technologie précédente, et a donc bien du mal. Les premières voitures roulaient sur des routes prévues pour les chevaux. Ceux-ci ont quatre pattes et un bon équilibre, les trous ne les dérangeaient donc pas trop, alors qu'ils étaient redoutables pour les voitures. Petit à petit, les choses ont changé, l'infrastructure s'est inversée, et ce sont aujourd'hui les chevaux qui marchent sur une route goudronnée conçue pour les voitures. De même, l'Internet à ses débuts devait emprunter une infrastructure conçue pour le téléphone (et on avait besoin de modems, pour faire passer IP pour de la voix) alors qu'aujourd'hui, l'infrastructure s'est inversée, c'est la voix qui n'est plus qu'une des nombreuses applications qui utilisent l'infrastructure de l'Internet.

De la même façon, estime Antonopoulos, les services bancaires traditionnels continueront à exister, mais seront simplement des applications au-dessus de Bitcoin.

L'auteur est bien conscient que les adversaires du Bitcoin ne vont pas se contenter de le ridiculiser ou de le critiquer. Ils vont activement tenter de l'interdire. Il est très optimiste sur les chances du Bitcoin de résister à cette censure (dans le pire des cas, les transactions seront encodées en smileys dans les discussions des articles Wikipédia et ne pourront donc pas être stoppées...) Après tout, Bitcoin a déjà été testé au feu, d'innombrables attaques ont déjà visé cette monnaie, et le Bitcoin a toujours survécu. (Voir à ce sujet l'hilarant site « Bitcoin Obituaries » et l'amusante vidéo « Not this time ».)

Antonopoulos insiste sur le caractère « sans permission » du Bitcoin. Il n'y a pas de Président du Bitcoin, chacun avec une idée peut la mettre en œuvre sur la chaîne de blocs tout de suite, sans demander de permission. En tant que « programmable money », Bitcoin n'a pas seulement un usage (payer) mais tous les usages qu'on peut imaginer. (Le Bitcoin est neutre, au sens de « neutralité du réseau ».)

Antonopoulos fait remarquer que toutes les innovations ont été la cible d'innombrables critiques à leur début. (Il oublie de dire que certaines critiques étaient justifiées. Par exemple, il cite des déclarations anti-voiture des débuts de l'automobile, pointant les dangers mortels de cette technologie, dangers qui existent toujours.) Ces critiques semblent bien ridicules avec le recul, comme celles contre le Bitcoin sonneront moyenâgeuses dans le futur. Antonopoulos remarque avec justesse que ces critiques portaient souvent sur des points de détail, qui allaient évoluer avec le temps. Ainsi, les premières critiques des automobiles portaient sur la difficulté à les faire démarrer, problème réel mais qui a été vite résolu avec l'invention du démarreur. (Personnellement, je me souviens bien des premières démonstrations de l'Internet que je faisais au début des années 1990, où la plupart des remarques des gens portaient sur le caractère « peu convivial » des logiciels utilisés. Peu de gens étaient capables de voir l'intérêt de cette technologie, au-delà de problèmes ergonomiques temporaires.)

Dans une autre conférence, Antonopoulos revient sur la monnaie : de quand date t-elle ? Et, d'ailleurs, qu'est-ce qu'on appelle « monnaie » ? (Beaucoup de messieurs experts refusent de considérer le Bitcoin comme une monnaie car ils donnent de la monnaie une définition arbitraire et anti-historique du genre « la monnaie est le moyen de paiement décidé par un État, et régulé ».)

L'auteur insiste aussi sur l'importance pour les acteurs du monde Bitcoin de ne pas copier bêtement le vocabulaire du passé. Ainsi, il s'énerve (à juste titre) contre les articles mentionnant le Bitcoin et qui sont illustrés par... des pièces de monnaie. Il reconnait que c'est d'ailleurs en partie la faute du terme « bitcoin » qui est trompeur. De même, le terme de « portefeuille », souvent utilisé pour les logiciels de gestion de ses bitcoins, est erroné : on ne peut pas copier un portefeuille traditionnel, alors qu'il n'y a aucun problème à le faire avec un portefeuille Bitcoin (il ne stocke pas d'argent, mais des clés).

Autre exemple de l'erreur qu'il y a à copier aveuglément les anciennes techniques, les places de marché Bitcoin. Ces places n'ont rien de Bitcoin, ce sont des établissements financiers traditionnels et, notamment, leur modèle de sécurité n'est pas du tout celui de Bitcoin.

Compte-tenu de la marée médiatique anti-Bitcoin (et anti-cryptomonnaies en général), on a bien besoin d'un livre comme celui-ci, qui redresse la barre. Par contre, il ne faut pas y chercher une analyse balancée. On ne voit aucune critique sur les aspects problématiques du Bitcoin. Il faudra un autre livre pour cela. Un volontaire pour écrire une critique sérieuse du Bitcoin ? (Qui ne se limite pas à des points de détail spectaculaires comme l'identité de Nakamoto, ou à du simple conservatisme du genre « les banques n'en veulent pas » ?) En attendant, lisez le livre, et écoutez les conférences d'Andreas Antonopoulos, vous ne le regretterez pas.


L'article seul

RFC 8027: DNSSEC Roadblock Avoidance

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : W. Hardaker (USC/ISI), O. Gudmundsson (CloudFlare), S. Krishnaswamy (Parsons)
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 4 décembre 2016


Normalement, en 2016, tous les résolveurs DNS sérieux devraient valider avec DNSSEC. Mais ce n'est pas le cas. Il y a plusieurs raisons à cela, mais ce nouveau RFC se focalise sur un problème précis : le cas d'un résolveur connecté via un réseau pourri, non-neutre, et qui se permet d'interférer avec le transport des paquets IP, menant le résolveur à de sérieuses difficultés. Comment détecter ces réseaux pourris ? Et que faire pour valider quand même ?

Si le résolveur est une grosse machine dans un centre de données, connectée directement à des opérateurs neutres, il n'y a pas trop de problème. C'est le cas des résolveurs des FAI, par exemple. Mais la situation est bien moins favorable à M. Michu. Si celui-ci veut, à juste titre, avoir son propre résolveur DNS sur sa machine, il dépend des réseaux où on laisse M. Michu se connecter, et ceux-ci sont rarement neutres. (Le RFC couvre le cas où ce résolveur local fait suivre - forwarde - les requêtes à un autre résolveur, et celui où il parle directement aux serveurs faisant autorité.)

La section 1.2 du RFC décrit les cas où la validation DNSSEC va être difficile ou impossible :

  • Résolveur qui ne connait pas DNSSEC (évidemment),
  • Intermédiaires (relais DNS dans la box, par exemmple), qui viole le protocole DNS au point de gêner le fonctionnement de DNSSEC (ce cas est décrit en détail dans le RFC 5625),
  • Équipements réseau actifs qui modifient ou bloquent les messages DNS, par exemple en supprimant les signatures DNSSEC (beaucoup de « firewalls » sont dans ce cas),
  • Réseau qui ne gère pas correctement les fragments, ce qui est plus fréquent avec DNSSEC.

Bien des outils ont été développés pour contourner ces problèmes, comme dnssec-trigger.

Pour faire des tests des résolveurs et de tous les équipements intermédiaires qui peuvent poser des problèmes de validation DNSSEC dans certains cas, le RFC parle d'une zone de test nommée test.example.com. Elle n'existe pas en vrai mais, aujourd'hui, la zone test.dnssec-tools.org fait la même chose (elle est par exemple utilisée pour les travaux pratiques lors de la formation DNSSEC chez HSC). Cette zone est délibérement peuplée avec des noms mal signés. Ainsi, le nom badsign-aaaa.test.dnssec-tools.org a un enregistrement AAAA dont la signature a été modifiée, la rendant invalide. Testons (pour tous les tests, comme le but était de voir le comportement DNSSEC, j'ai utilisé un fichier de configuration ~/.digrc contenant +dnssec +multiline, merci à Landry Minoza de l'avoir remarqué) :


% dig AAAA badsign-aaaa.test.dnssec-tools.org
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> AAAA badsign-aaaa.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60910
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-aaaa.test.dnssec-tools.org. IN AAAA

;; Query time: 3759 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 04 17:12:28 CET 2016
;; MSG SIZE  rcvd: 63


% dig +cd AAAA badsign-aaaa.test.dnssec-tools.org
; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> +cd AAAA badsign-aaaa.test.dnssec-tools.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29404
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;badsign-aaaa.test.dnssec-tools.org. IN AAAA

;; ANSWER SECTION:
badsign-aaaa.test.dnssec-tools.org. 86400 IN AAAA 2001:470:1f00:ffff::1
badsign-aaaa.test.dnssec-tools.org. 86400 IN RRSIG AAAA 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				nZ8bPLBleW/sW6x135+Iz4IhO6Lr04V8C9fC1bMVfCVY
				3rKqbOoBk1i+wnnGDCTWQ5iCicWTKLIpbDmCSW9C33pj
				P2j7C/ensspbdwpD/7Ia8zN+XUSN+ThLU6lgYGKFuoVL
				QmIG/vr1lOn6xdjXY2E4mStAjaGuertvKKDYy/I= )

;; AUTHORITY SECTION:
test.dnssec-tools.org.	280 IN NS dns1.test.dnssec-tools.org.
test.dnssec-tools.org.	280 IN NS dns2.test.dnssec-tools.org.
test.dnssec-tools.org.	280 IN RRSIG NS 5 3 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				AK95JOAuvfZ1ZwEsrKiR8DP1zluoBvBkXHRXa78rrK5U
				UuZdLnZwnYlnNplrZZOrQNuUaPyb4zI0TGfw/+aa/ZTU
				qyx8uQODSHuBTPQTlcmCFAfTIyd1Q+tSTEs2TuGUhjKe
				H9Hk+w6yOjI/o52c2OcTMTJ4Jmt2GlIssrrDlxY= )

;; ADDITIONAL SECTION:
dns1.test.dnssec-tools.org. 280	IN A 168.150.236.43
dns2.test.dnssec-tools.org. 280	IN A 75.101.48.145
dns1.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				zoa0V/Hwa4QM0spG6RlhGM6hK3rQVALpDve1rtF6NvUS
				Sb6/HBzQOP6YXTFQMzPEFUza8/tchYp5eQaPBf2AqsBl
				i4TqSjkIEklHohUmdhK7xcfFjHILUMcT/5AXkEStJg7I
				6AqZE1ibcOh7Mfmt/2f0vj2opIkz6uK740W7qjg= )
dns2.test.dnssec-tools.org. 86400 IN RRSIG A 5 4 86400 (
				20170101064820 20161202054820 19442 test.dnssec-tools.org.
				hGq7iAtbHrtjCYJGMPQ3fxijhu4Izk8Ly+xZOa0Ag24R
				lqpFgdd2amDstFVLTRs3x15UqQIO+hmFdlbSOterDkbg
				/o2/FhtZOJr7c75Pu3EWi/DDbT9pULk4Uwjlie1QBopv
				LLZ94SlqKO7eQ02NRyy5EL4gD2G5rSffsUqEkj8= )

;; Query time: 206 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 04 17:12:44 CET 2016
;; MSG SIZE  rcvd: 885

    

Le second test, celui fait avec le bit CD (Checking Disabled), montre que le problème vient bien de DNSSEC. Autre test, avec une signature expirée :


% dig A pastdate-a.test.dnssec-tools.org
...
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46319
...


% dig +cd A pastdate-a.test.dnssec-tools.org
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49547
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5
...
;; ANSWER SECTION:
pastdate-a.test.dnssec-tools.org. 86400	IN A 64.90.35.104
pastdate-a.test.dnssec-tools.org. 86400	IN RRSIG A 5 4 86400 (
				20161201224321 20161101234821 19442 test.dnssec-tools.org.
				lIL0zcEZpG/4uG5hImvpivH1C/D3PFI3RNYHlPbZ [...]

    

La liste de tous les noms à tester est en ligne.

Le but de ce RFC est de lister tous les tests que peut et devrait faire un validateur local, pour arriver à valider malgré des résolveurs amont, ou bien un réseau, hostile. Ces stratégies sont mises en œuvre, par exemple, dans dnssec-trigger.

En détectant la non-conformité (compliance, un terme à la mode dans les organisations), le validateur situé sur la machine terminale, ou bien dans le réseau local, peut alors adopter la meilleure stratégie de contournement (ou, dans le pire des cas, prévenir loyalement l'utilisateur qu'on ne pourra pas faire de validation DNSSEC). Les tests doivent être faits au début d'une nouvelle connexion réseau, ou bien lorsque celle-ci change.

La section 3 du RFC est consacrée à ces tests de non-conformité. Je ne vais pas décrire la totalité de ces tests, un sous-ensemble suffira. Ainsi, le premier test, le plus trivial, est que la machine puisse parler en UDP à son résolveur attitré (celui typiquement reçu en DHCP). On lui demande good-a.test.dnssec-tools.org et on doit avoir une réponse sous forme d'une adresse IP (comme son nom l'indique, ce nom est correctement signé). Si un test aussi trivial ne marche pas, ce n'est sans doute pas la peine d'aller plus loin. Un peu plus subtil, on teste le même résolveur en TCP.

Après, on passe à EDNS (RFC 6891), qui est indispensable pour DNSSEC. Une requête pour ce même nom, mais avec une option EDNS, doit passer. Si EDNS ne marche pas, on peut arrêter, DNSSEC ne marchera pas non plus. Mais s'il marche ? On teste alors avec le bit DO (DNSSEC OK) qui indique au serveur qu'il doit envoyer les données DNSSEC, notamment les signatures. La réponse doit inclure ce même bit DO. (C'est plus tard qu'on teste qu'on a bien reçu des signatures. Rappelez-vous que la plupart des middleboxes sont horriblement boguées. Certaines acceptent le bit DO et le renvoient, sans pour autant transmettre les signatures.)

On teste alors des zones qu'on sait signées et on regarde si le résolveur met le bit AD (Authentic Data), au moins pour les algoritmes RSA + SHA-1 et RSA + SHA-256. Si cela ne marche pas, ce n'est pas forcément une erreur fatale, puisque, de toute façon, on voulait faire la validation nous-même. Il faut aussi penser à faire le test inverse : un résolveur validant doit mettre le bit AD pour une réponse signée correctement, et doit répondre avec le code de retour SERVFAIL (Server Failure) si la réponse devrait être signée mais ne l'est pas, ou bien l'est mal. Cela se fait en testant badsign-a.test.dnssec-tools.org.

Dans les enregistrements DNSSEC, il n'y a pas que les signatures (RRSIG), il y a aussi les enregistrements servant à prouver la non-existence, NSEC et NSEC3. Il faut donc également tester qu'ils sont reçus car, en pratique, on voit en effet des middleboxes qui laissent passer les RRSIG mais bloquent stupidement les NSEC et les NSEC3. On demande donc non-existent.test.dnsssec-tools.org, et on doit récupérer non seulement une réponse avec le code NXDOMAIN (No Such Domain) mais également les NSEC ou NSEC3 permettant de valider cette réponse :


% dig AAAA non-existent.test.dnsssec-tools.org
[...]
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40218
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
[...]
;; AUTHORITY SECTION:
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 900 IN NSEC3 1 1 1 D399EAAB (
				H9PARR669T6U8O1GSG9E1LMITK4DEM0T
				NS SOA RRSIG DNSKEY NSEC3PARAM )
iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN RRSIG NSEC3 7 2 86400 (
				20161222153046 20161201143046 3947 org.
				kgCZC/gE4ySP7eZUb1+2ORYRhTrvL5YBIHLCBK5F8pqK
				MXGJXJ/hX+8LLrg4jHJaER2AelUgUGywRn4uY80ajYpg
				eTuSGzRX1aVCKAR8UB80bX/YLUPUPKWOdfgxTekD4nZk
				eoi/9JNmIMZRc0cmMGp8LSVMqX98F2bVJnZro8U= )
iruevfos0vs8jssfj22me5p458p0qj1e.org. 900 IN NSEC3 1 1 1 D399EAAB (
				IRVVBMC65HCBCFQNQS8NQFTAB943LCFU
				NS DS RRSIG )
vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN RRSIG NSEC3 7 2 86400 (
				20161222153046 20161201143046 3947 org.
				Nj/zvU0GB8vQ7bFfpSSWW+inE7RiOFjOpNc1K/TMnQqG
				QsKTLD9gBM8vgh3K1WdPXOCzthf/isDJAy2xLA/oRFFq
				KZ+Coo+33FManVmuyndGJ5bdgQqnpa0xGP7yOgjTfUsh
				Ff9HkX0mkzqYtWYzw0J7WnMPcOjmrlg26WsfwlU= )
vaittv1g2ies9s3920soaumh73klnhs5.org. 900 IN NSEC3 1 1 1 D399EAAB (
				VAJB898DELVT5UJ4I9D1BRD2FRTBSCM1
				NS DS RRSIG )

    

Certains serveurs DNS (ou, plus exactement, certains ensembles serveur+réseau+middlebox) n'acceptent que certains types d'enregistrement DNS (les plus connus, comme A, AAAA, MX, parfois SRV, etc). Il faut donc tester que le serveur accepte bien tous les types d'enregistrement,

Jusqu'à présent, on n'a testé que le résolveur « normal ». Même s'il ne valide pas, tant qu'il transmet fidèlement toutes les données DNS, on pourra au moins l'utiliser comme relais et cache. Par contre, dans certains cas, si on veut valider avec DNSSEC, il faudra complètement le court-circuiter. Ainsi, s'il ne transmet pas les signatures, on n'a pas d'autre choix que d'aller les demander à un autre résolveur, ou bien directement aux serveurs faisant autorité. Il faut donc tester qu'on puisse interroger ces serveurs, avec UDP et avec TCP. (Ce n'est pas toujours possible, certains réseaux violent tellement la neutralité de l'Internet qu'ils bloquent le port 53, celui du DNS.)

Avec DNSSEC, les réponses sont souvent de grande taille, et parfois fragmentées. Il faut donc tester que les fragments passent (ils sont souvent bloqués par des administrateurs réseau incompétents).

Une fois ces tests faits, il reste à synthétiser les résultats (section 4). L'idée est de pouvoir dire si le résolveur « normal » est :

  • Un validateur (on peut alors tout lui déléguer, en tout cas si on a confiance en lui),
  • Un résolveur DNSSEC (même s'il ne valide pas, il passe bien tous les enregistrements DNSSEC),
  • Une horreur à fuir.

En pratique, tous les résolveurs (ou plutôt l'ensemble du résolveur et du réseau situé devant, avec ses middleboxes qui cassent tout) ne rentrent pas parfaitement dans une de ces trois catégories. Ainsi, certains vont bloquer les fragments mais accepter TCP (ce qui permettra de quand même faire passer les données de grande taille), tandis que d'autres n'auront pas TCP mais qu'UDP fonctionnera bien, même en cas de fragmentation.

Une fois ces données collectées, et le résolveur correctement classé, on pourra alors déterminer comment contourner les éventuels problèmes (section 5 du RFC). Par exemple :

  • Si le résolveur officiel est un validateur ou bien un résolveur DNSSEC, on l'utilise comme forwarder pour transmettre les requêtes, profitant ainsi de son cache et réduisant la charge sur les serveurs faisant autorité.
  • Si le résolveur officiel est une horreur, mais que les requêtes DNS vers l'extérieur marchent, alors, ne pas faire appel au résolveur officiel et parler directement aux serveurs faisant autorité.
  • Si le résolveur officiel est une horreur, et que les requêtes DNS vers l'extérieur sont bloquées, tenter de joindre un résolveur extérieur de confiance, en utilisant DNS sur TLS (RFC 7858), ce que fait dnssec-trigger (dans son fichier de configuration, des lignes comme tcp80: 185.49.140.67 ou ssl443: 185.49.140.67 ...).
  • Sinon, si rien ne marche, laisser tomber, prévenir l'utilisateur et pleurer.

La section 6 du RFC sert de voiture-balai, en mentionnant les cas spéciaux qui peuvent être embêtants. Par exemple, DNSSEC dépend de l'horloge, puisqu'il faut vérifier que les signatures n'ont pas expiré. Mais la synchronisation de l'horloge dépend de NTP donc parfois du DNS si on a mis des noms de domaine dans son ntp.conf. Si la machine a une horloge assez stable pour garder l'heure entre un arrêt et un démarrage, ce n'est pas trop grave. Mais si la machine est un engin bon marché avec une horloge qui dévie beaucoup (genre le Raspberry Pi), que faire ?

Autre problème, les affreux portails captifs. Tant qu'on n'a pas cliqué sur « j'accepte cinquante pages de conditions d'utilisation que je n'ai pas lues, je veux recevoir du spam, et je promets de ne pas partager de la culture », on n'a pas un vrai accès Internet et le port 53 est sans doute bloqué. Il faudrait donc refaire les tests après le passage par le portail captif.

Face à ce genre de problèmes, une première solution est de ne pas tenter de faire du DNSSEC tant qu'on n'a pas synchronisé l'horloge, passé le portail captif (c'est ce que fait dnssec-trigger), au détriment de la sécurité. Au moins, on peut prévenir l'utilisateur et lui proposer de réessayer plus tard.


Téléchargez le RFC 8027


L'article seul

RFC 7970: The Incident Object Description Exchange Format Version 2

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : R. Danyliw (CERT)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF mile
Première rédaction de cet article le 1 décembre 2016


Pour rendre plus facilement analysables les innombrables rapports d'incidents de sécurité qui circulent sur Internet tous les jours, ce RFC spécifie un format standard XML, nommé IODEF, pour décrire ces incidents. Ici, il s'agit de la version 2 de ce format IODEF, la version 1 était dans le RFC 5070.

Tous les jours, des organisations comme les CERT et CSIRT, mais aussi les OIV, envoient et reçoivent des rapports détaillés concernant une attaque sur un réseau informatique ou un serveur. Ces rapports sont longs et détaillés mais, la plupart du temps, ce n'est pas une attaque isolée qui est intéressante, c'est l'image qui apparait lorsqu'on synthétise tous les rapports, et qu'on voit alors les tendances, par exemple l'arrivée d'un nouveau ver ou bien une attaque concertée contre un pays donné. D'où l'importance de pouvoir analyser automatiquement ces rapports, ce qui impose un modèle de données et un format standard, ce que fournit ce RFC.

Le modèle de données est proche des modèles objet, par exemple dans la descriptions des classes d'objets manipulés (comme la classe Incident en section 3.2, avec la cardinalité des attributs). Ces classes sont composés avec des données élémentaires (booléens, entiers, dates) décrites dans la section 2. Par exemple, parmi les attributs de la classe Incident, on trouve l'heure de début et de fin de l'incident, l'heure de détection, etc. Le schéma XML complet, écrit en W3C Schema, figure dans la section 8.

On trouve énormément de choses dans ce schéma (le RFC fait plus de 160 pages), pour traiter tous les cas prévus. Par exemple, on peut exprimer une liste de ports comprenant à la fois des ports individuels et des intervalles : 22,53,80,1024-2047. De nombreuses classes existent pour utiliser ces informations élémentaires. Ainsi, la classe Discovery, une nouveauté de la version 2, permet d'indiquer comment l'incident a été découvert (avec un attribut source qui a vingt valeurs possibles, comme avantivirus, os-logjournal, passive-dns - un système comme DNSdb, etc). Et BusinessImpact permet de décrire les conséquences de l'incident sur l'activité (breach-privacy, loss-of-service, theft-financial, etc). Ça peut même se quantifier financièrement avec la classe MonetaryImpact. Si on met les incidents de sécurité dans une base de données (ça s'appelle un SIEM, comme Prelude), on peut donc imaginer de regarder d'abord les incidents qui ont coûté le plus cher...

Voici un exemple d'un rapport d'incident, tiré du RFC (section 7), et qui décrit et qui décrit les systèmes de C&C (quatre serveurs) d'une campagne donnée (dans le RFC 5070, l'exemple était une simple reconnaissance avec nmap...). Cet exemple a l'avantage d'illustrer la classe IndicatorData, une nouveauté de la version 2 :


   <?xml version="1.0" encoding="UTF-8"?>
   <!-- A list of C2 domains associated with a campaign -->
   <IODEF-Document version="2.00" xml:lang="en"
      xmlns="urn:ietf:params:xml:ns:iodef-2.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
      "http://www.iana.org/assignments/xml-registry/schema/
       iodef-2.0.xsd">
     <Incident purpose="watch" restriction="green">
       <IncidentID name="csirt.example.com">897923</IncidentID>
         <RelatedActivity>
           <ThreatActor>
             <ThreatActorID>
             TA-12-AGGRESSIVE-BUTTERFLY
             </ThreatActorID>
             <Description>Aggressive Butterfly</Description>
           </ThreatActor>
           <Campaign>
             <CampaignID>C-2015-59405</CampaignID>
             <Description>Orange Giraffe</Description>
           </Campaign>
         </RelatedActivity>
         <GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
         <Description>Summarizes the Indicators of Compromise
           for the Orange Giraffe campaign of the Aggressive
           Butterfly crime gang.
         </Description>
         <Assessment>
           <BusinessImpact type="breach-proprietary"/>
         </Assessment>
         <Contact type="organization" role="creator">
           <ContactName>CSIRT for example.com</ContactName>
           <Email>
             <EmailTo>contact@csirt.example.com</EmailTo>
           </Email>
         </Contact>
         <IndicatorData>
           <Indicator>
             <IndicatorID name="csirt.example.com" version="1">
             G90823490
             </IndicatorID>
             <Description>C2 domains</Description>
             <StartTime>2014-12-02T11:18:00-05:00</StartTime>
             <Observable>
               <BulkObservable type="fqdn">
               <BulkObservableList>
                 kj290023j09r34.example.com
                 09ijk23jfj0k8.example.net
                 klknjwfjiowjefr923.example.org
                 oimireik79msd.example.org
               </BulkObservableList>
             </BulkObservable>
           </Observable>
         </Indicator>
       </IndicatorData>
     </Incident>
     </IODEF-Document>

Le RFC note sagement que le partage d'informations n'est pas uniquement une question technique, mais qu'elle dépend aussi des procédures bureaucratiques de chaque organisation, des contraintes légales, de la confiance (ou de l'absence de confiance, souvent justifiée) et enfin de la simple bonne ou mauvaise volonté. (Mon opinion personnelle est que, en France, le partage d'informations précises sur les incidents de sécurité est très insuffisant.)

Les changements depuis la version 1 (celle du RFC 5070) sont listés dans la section 1.4. Beaucoup de détails, beaucoup d'ajouts, parmi lesquels je note :

  • Meilleure internationalisation (voir à ce sujet la section 6 du RFC), comme le fait que la classe Contact permette désormais d'indiquer une adresse postale en un jeu de caractères quelconque,
  • Nouvelles classes (comme IndicatorData ou Discovery cités plus haut, ou comme DomainData, pour des informations sur un nom de domaine), et nouveaux attributs dans les classes existantes (par exemple, Incident y gagne observable-id, un identificateur qui peut être utilisé dans des références croisées).

Si l'ajout de nouvelles classes ne rendent pas les anciennes descriptions IODEF incorrectes, en revanche, certains changements cassent la compatibilité et un fichier IODEF version 1 parfait ne sera pas forcément légal pour la version 2 (cf. section 4.4). Par exemple, la sous-classe NodeRole (qui permet de décrire si on est attaqué par une caméra de vidéosurveillance ou bien par un routeur) a changé de classe parente.

Et les mises en œuvre d'IODEF ? Un résumé de l'état de ces mises en œuvre figure dans l'Internet-Draft draft-ietf-mile-implementreport, et qui référence une liste des programmes IODEF (j'ai aussi trouvé celle-ci). Parmi d'autres, on peut noter la bibliothèque de Prelude (et qui a une version pour l'IODEF v2 de notre RFC), un module Perl, un autre en PHP, et un troisième en Python. On trouve aussi des moyens de connecter IODEF à des logiciels existants par exemple au logiciel de suivi de tâche Mantis, avec ce connecteur.

Pour des articles ou présentations sur IODEF, vous pouvez voir la Rump (session rapide) de Thomas Andrejak au SSTIC 2016 (vidéo en ligne).

Notez en France l'existence du projet SECEF (SECurity Exchange Format) qui a pour objectif de promouvoir et de faciliter l’usage des deux formats de fichier IDMEF (RFC 4765) et IODEF. Vous pouvez consulter leur Wiki, et leur tutoriel IODEF. Il y a aussi un article de synthèse sur SECEF, et un compte-rendu d'une de leurs réunions (mais vite fait et avec des erreurs).


Téléchargez le RFC 7970


L'article seul

RFC 8023: Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions

Date de publication du RFC : Novembre 2016
Auteur(s) du RFC : Matthew Thomas, Allison Mankin, Lixia Zhang (UCLA)
Pour information
Première rédaction de cet article le 27 novembre 2016


Ce nouveau RFC est le compte-rendu d'un atelier qui s'était tenu du 8 au 10 mars 2014 à Londres sur le thème des « collisions ». Ce terme exagéré et sensationnaliste désigne le phénomène qui peut se produire quand un acteur de l'Internet a bêtement choisi de se créer un TLD à lui dans le DNS, et que ce TLD est ensuite créé par l'ICANN.

Supposons que l'entreprise Bidon décide de nommer ses ressources internes (site Web réservé aux employés, etc) sous le TLD inexistant .bidon. C'est une mauvaise idée mais elle est fréquente. L'entreprise Bidon compte sur le fait que ses employés utiliseront les résolveurs DNS internes, qui ont été configurés pour reconnaître .bidon. Par exemple, avec Unbound, et un serveur faisant autorité en 2001:db8:666::1:541f, les résolveurs ont été configurés ainsi :

    stub-zone:
     name:   "bidon"
     stub-addr: 2001:db8:666::1:541f
    

Si un employé tente accidentellement d'accéder à une ressource en .bidon, alors qu'il n'utilise pas les résolveurs de la boîte, la requête filera vers la racine du DNS, qui répondra NXDOMAIN (No Such Domain). C'est ainsi que la racine voit souvent des requêtes pour des noms se terminant en .local, .home ou .belkin. Si, quelques années après, l'ICANN délègue effectivement ce TLD à une autre organisation, ces requêtes à la racine donneront désormais un vrai résultat. Au lieu d'un message d'erreur, le malheureux employé sera peut-être redirigé vers un autre site Web que celui attendu. C'est ce phénomène que Verisign avait baptisé « collision » (name collision), terme conçu pour faire peur.

C'est dans ce contexte qu'il y a plus de deux ans s'était tenu le « Workshop on Root Causes and Mitigation of Name Collisions », dont ce RFC est le compte-rendu tardif. Le premier rapport de l'ICANN qui mentionnait ce phénomène était le SAC 045 en 2010. Il pointait le risque que la délégation effective d'un nouveau TLD change la réponse obtenue, pour les clients mal configurés (qui interrogeaient à tort un résolveur extérieur, et donc la racine, au lieu de leurs résolveurs internes).

L'ICANN a même créé une page Web dédiée à cette question, dont la source réelle est le recouvrement de deux espaces de noms, l'interne et l'externe. La bonne pratique idéale serait de ne pas utiliser de noms qui n'existent pas ou, pire, qui existent avec une autre signification dans l'arbre public des noms de domaine (et, là, relire le RFC 2826 peut aider). Pour reprendre l'exemple de l'entreprise Bidon, si elle est titulaire de bidon.fr, elle devrait nommer ses ressources internes avec des noms se terminant en privé.bidon.fr ou interne.bidon.fr. Si on ne veut pas faire les choses proprement, et qu'on utilise quand même le TLD inexistant .bidon, alors il faut veiller très soigneusement à séparer les deux espaces de nommage et à éviter qu'ils ne se rencontrent un jour (ce qui est difficile à l'ère des mobiles, avec des appareils qui rentrent et qui sortent du réseau de l'entreprise). Sinon, on verra ces fameuses collisions.

En pratique, pas mal d'administrateurs système surestiment leurs compétences et croient qu'ils vont réussir à empêcher toute fuite vers le DNS public. C'est ce qui explique une partie des requêtes pour des noms inexistants que reçoit la racine (ces noms inexistants forment la majorité du trafic des serveurs racine du DNS). Un des problèmes de fond de l'Internet est en effet que l'administrateur de base ne se tient pas au courant et n'est pas informé des problèmes du monde extérieur. « Après moi, le déluge »

Autrefois, le problème était surtout théorique. Le nombre de TLD n'avait pas bougé depuis de très nombreuses années, et personne ne pensait que des TLD comme .pizza ou .green verraient le jour. Mais, en 2012, l'ICANN a lancé officiellement son programme d'ajout d'un grand nombre de TLD, et le risque est soudain devenu une question pratique. D'où l'atelier de 2014.

La section 2 du RFC revient en détail sur l'arrière-plan de ce problème de collision. Outre le rapport SAC 045 cité plus haut, il y avait eu une déclaration de l'IAB, puis un autre rapport du SSAC (Security and Stability Advisory Committee, un comité de l'ICANN), le SAC 046, une déclaration du RSSAC et plein d'autres textes sur les conséquences d'un agrandissement important de la zone racine. Par exemple, le rapport SAC 057 faisait remarquer que les AC attribuaient souvent des certificats pour des noms de domaine dans des TLD purement locaux. Cela montrait le déploiement de ces TLD privés et cela inquiétait. Si la société Bidon exploite .bidon et obtient d'une AC un certificat pour www.compta.bidon, après la délégation de ce même TLD dans la racine publique, ce certificat pourrait être utilisé pour usurper l'identité d'un autre serveur.

J'ai parlé plus haut des fuites vers le DNS public. Quelle est leur ampleur exacte ? Ce n'est pas si évident que cela de le savoir. Contrairement à un raccourci journalistique fréquent, l'ICANN ne gère pas la racine. Chaque opérateur d'un serveur DNS racine se débrouille indépendamment, supervise son serveur mais ne rend pas forcément compte à d'autres acteurs ou au public. En pratique, les opérateurs des serveurs racine ont un niveau d'ouverture très variable. (Cf. l'analyse de l'ICANN à ce sujet.) Un des moments où plusieurs opérateurs de serveurs racine collectent en même temps de l'information est le Day in the Life of the Internet et c'est sur la base de ces données qu'a été fait le rapport d'Interisle « Name Collision in the DNS ». Entre autres, ce rapport classait les futurs TLD selon qu'ils présentaient un risque de collision élevé ou faible (.home, .corp et .site se retrouvaient en tête du classement). L'ICANN a alors publié un plan pour gérer ce risque de collisions, notant que .home et .corp étaient de loin les plus « risqués », car ils sont fréquemment utilisés comme TLD locaux. Bien d'autres documents ont été publiés par l'ICANN, qui a une productivité extraordinaire lorsqu'il s'agit de faire de la paperasse. Le dernier mettait en place le système dit de « controlled interruption » qui, en gros, impose à tous les nouveaux TLD de résoudre, pendant les premiers temps de leur délégation, tous les noms de domaine vers l'adresse IP 127.0.53.53. Voici l'exemple de .box en novembre 2016 (ce cas avait fait l'objet d'un article de Heise en allemand, car le routeur Fritz!Box, très populaire en Allemagne, utilisait ce TLD) :



% dig ANY box.

; <<>> DiG 9.10.3-P4-Debian <<>> ANY box.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14573
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 24, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;box.			IN ANY

;; ANSWER SECTION:
box.			3600 IN	A 127.0.53.53
box.			3600 IN	SRV 10 10 0 your-dns-needs-immediate-attention.box.
box.			3600 IN	TXT "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
box.			3600 IN	MX 10 your-dns-needs-immediate-attention.box.
box.			900 IN SOA a.nic.box. support.ariservices.com. (
				1478481375 ; serial
				1800       ; refresh (30 minutes)
				300        ; retry (5 minutes)
				1814400    ; expire (3 weeks)
				1800       ; minimum (30 minutes)
				)
box.			172800 IN NS b.nic.box.
box.			172800 IN NS d.nic.box.
box.			172800 IN NS c.nic.box.
box.			172800 IN NS a.nic.box.
[...]
;; Query time: 89 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 21 17:23:17 CET 2016
;; MSG SIZE  rcvd: 2938



    

Ces enregistrements ont pour but d'attirer l'attention des utilisateurs sur le risque de collision. Le TLD étant récent et pas encore peuplé, il ne devrait pas y avoir de requêtes DNS. S'il y en a quand même, c'est peut-être le résultat d'une collision avec un usage local. L'adresse IP 127.0.53.53 est une adresse locale à la machine. Si M. Michu tente de se connecter à http://quelquechose.box/ aujourd'hui, il sera redirigé vers la machine locale. Il verra une erreur (pas de serveur HTTP qui écoute) ou bien la page Web par défaut de sa machine (avec un message peu informatif comme « It works ») s'il y a un serveur HTTP. Si l'utilisateur regarde les enregistrements SRV, MX ou TXT, ou bien si un administrateur système regarde les requêtes DNS qui passent, ou bien les journaux du serveur de messagerie, peut-être comprendra-t-il qu'il doit agir. (Je trouve personnellement que la probabilité que cela arrive est assez faible.)

L'atelier lui-même, financé par Verisign (l'entreprise qui avait le plus crié « au loup » sur les name collisions), s'est donc tenu du 8 au 10 mars à Londres. Un site Web avait été mis en place pour cet atelier, et il contient les supports et les vidéos.

Je ne vais pas décrire tous les exposés de l'atelier, la liste complète figure dans l'annexe C du RFC, et les supports sont en ligne. Le RFC note qu'il y a eu plusieurs interventions sur la qualité des données du DITL (Day in the Life of the Internet) : il est trivial de les polluer (le DITL est annoncé publiquement, et à l'avance) par des requêtes artificielles. Aucune preuve n'a été trouvée d'une manipulation délibérée. De toute façon, les données montrent surtout qu'il y a beaucoup de n'importe quoi dans le trafic que reçoivent les serveurs racine (par exemple des requêtes avec le bit RD - Recursion Desired - alors que les serveurs de la racine ne sont pas récursifs). Cela peut être le résultat de bogues dans les résolveurs, de tests ou bien d'attaques délibérées.

La question de l'éducation des utilisateurs est revenue plusieurs fois. Faut-il s'inspirer du téléphone ou du système postal, qui ont tous les deux connu des changements qui nécessitaient une adaptation de l'utilisateur, qui s'est faite par le biais d'importantes campagnes de sensibilisation et d'éducation ?

Le comité de programme avait conclu que le sujet était loin d'être épuisé. Manque de données, manque de théories explicatives, manque d'intérêt pour la question, en tout cas, celle-ci restait largement ouverte après l'atelier (et je ne suis personnellement pas sûr que cela soit mieux aujourd'hui, plus de deux ans après l'atelier de Londres).


Téléchargez le RFC 8023


L'article seul

RFC 8003: Host Identity Protocol (HIP) Registration Extension

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : J. Laganier (Luminate Wireless), L. Eggert (NetApp)
Chemin des normes
Première rédaction de cet article le 26 novembre 2016


Le protocole HIP, décrit dans le RFC 7401 est très bien adapté au cas où l'adresse IP (le localisateur) change après l'établissement d'une association. Mais cela laisse ouvert le grand problème de la connexion initiale. Comment trouver une machine HIP ? Par le mécanisme de rendez-vous du RFC 8004 ? C'est certainement une bonne solution mais, alors, comment les machines HIP sont-elles connues du serveur de rendez-vous ? C'est là que notre RFC rentre en jeu pour normaliser un mécanisme d'enregistrement auprès d'un service. C'est un mécanisme générique, qui peut servir à d'autres choses que le rendez-vous, d'ailleurs. (Il était à l'origine spécifié dans le RFC 5203, que notre RFC remplace.)

Le mécanisme est très simple et le RFC court. On réutilise simplement les établissements d'associations de HIP, avec de nouveaux types de paramètres, notamment REG_INFO (pour l'hôte qui accepte d'être registrar, c'est-à-dire d'enregistrer) et REG_REQUEST (pour celui qui demande un enregistrement). Le mécanisme exact est détaillé dans la section 3 et les nouveaux paramètres dans la section 4.

HIP authentifiant les deux parties bien plus solidement que IP seul, le registrar (terme d'ailleurs mal choisi, on risque de confondre avec les bureaux d'enregistrement de noms de domaine) peut alors décider s'il accepte l'enregistrement ou pas (sections 3.3 et 6).

Le rendez-vous, normalisé dans le RFC 8004 est donc une simple application de notre RFC mais d'autres pourront apparaître à l'avenir (comme celle du RFC 5770).

Quels sont les changements depuis le premier RFC, le RFC 5203 ? La principale est qu'HIP, qui avait le statut « Expérimental » est désormais sur le chemin des Normes et que les références de notre RFC ont donc changé (nouveau protocole HIP en RFC 7401). Mais ce nouveau RFC ajoute aussi la possibilité d'authentifier le registrar par certificat (RFC 8002), ainsi qu'un nouveau type d'erreur, le numéro 2, « ressources insuffisantes chez le registrar ».

Question mise en œuvre, je n'ai pas vérifié mais, normalement, HIP for Linux et OpenHIP devraient s'adapter aux nouveaux RFC HIP.


Téléchargez le RFC 8003


L'article seul

RFC 8004: Host Identity Protocol (HIP) Rendezvous Extension

Date de publication du RFC : Octobre 2016
Auteur(s) du RFC : J. Laganier (Luminate Wireless,), L. Eggert (NetApp)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF hip
Première rédaction de cet article le 26 novembre 2016


HIP, par défaut, nécessite que l'initiateur d'une association connaisse le localisateur, l'adresse IP du répondeur. Si celui-ci bouge souvent, et qu'il n'est donc pas pratique de mettre cette adresse dans le DNS, une solution est d'utiliser le mécanisme de rendez-vous, décrit par ce RFC, où l'initiateur contacte un serveur de rendez-vous qui relaie vers le répondeur.

Le schéma est clairement expliqué dans la section 3 du RFC. En fonctionnement habituel de HIP, l'initiateur trouve l'identificateur et le localisateur du répondeur (typiquement, dans le DNS, cf. RFC 8005), puis le contacte directement. Si le localisateur n'est pas connu (ce qui est fréquent si le répondeur est un engin mobile, changeant souvent d'adresse IP), l'initiateur envoie le premier paquet (I1) au serveur de rendez-vous, qui le relaie au répondeur. Les autres paquets (R1, I2 et R2) seront transmis directement entre les deux machines HIP. Le mécanisme est détaillé dans la section 3.3 (il faut notamment procéder avec soin à la réécriture des adresses IP, en raison entre autre du RFC 2827).

Et comment l'initiateur trouve-t-il le serveur de rendez-vous ? En général dans le DNS, via les enregistrements de type HIP. Et comment le répondeur avait-il fait connaitre au serveur de rendez-vous son adresse IP ? Via le protocole d'enregistrement du RFC 8003, comme l'explique la section 4.

Comme toute indirection, le système de rendez-vous ouvre des problèmes de sécurité amusants. Si l'initiateur connaissait déjà l'identificateur du répondeur (donc sa clé publiqué), pas de problème, le passage par le serveur de rendez-vous ne diminue pas la sécurité. Si ce n'est pas le cas, alors, il n'y a rien à faire, l'initiateur n'a aucun moyen de vérifier l'identité du répondeur (section 5 du RFC).

Aucun changement depuis la première spécification, le RFC 5204, juste l'alignement avec la nouvelle version de HIP, celle du RFC 7401, désormais norme complète (et pas juste « expérimentale »).


Téléchargez le RFC 8004


L'article seul

Articles des différentes années : 2017  2016  2015  2014  2013  2012  2011  Précédentes années

Syndication : en HTTP non sécurisé, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu, en HTTPS, Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.