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.


Fiche de lecture : Culture numérique

Auteur(s) du livre : Dominique Cardon
Éditeur : Les presses de SciencesPo
978-2-7246-2365-9
Publié en 2019
Première rédaction de cet article le 3 avril 2020


Elle est loin, l'époque où l'Internet et le numérique en général, était ignoré des enseignants et des chercheurs en SHS. Désormais, il y a plein de livres étudiant tel ou tel aspect du réseau. Mais tous ne sont pas bien informés. Ici, au contraire, Dominique Cardon connait parfaitement son sujet, et a publié une version papier de son cours sur l'Internet à SciencesPo. Un ouvrage très utile si vous avez à enseigner l'Internet à des non-informaticiens.

Le plan est classique : histoire de l'Internet, gouvernance de l'Internet (bien expliquée, et sans les innombrables erreurs que contiennent la majorité des articles destinés au grand public), rôle des cultures « californiennes » (comme Burning Man), histoire du Web, les réseaux sociaux, la régulation du contenu, la pratique de la politique sur les réseaux, la publicité en ligne… Mais l'auteur parle également de sujets moins mentionnés dans les publications mainstream comme le rôle de la pensée des Communs (et celui du logiciel libre), avec l'exemple, toujours classique mais justifié, de Wikipédia. Les lecteurs de mon blog connaissent certainement déjà tout cela mais rappelez-vous que ce cours est destiné à un tout autre public, qui n'est normalement exposé qu'au discours mi-marketing (cloud, digital, etc), mi-catastrophiste (Internet, c'est que des fake news, et tout ça.)

Globalement, le livre se penche surtout sur les applications et sur les usages, pas tellement sur l'infrastructure sous-jacente. L'auteur a réussi à garder l'esprit d'un cours, accessible à un large public, tout en le réécrivant suffisamment pour que le livre ne soit pas juste une copie d'un support de cours. Cet ouvrage est utilisable pour le curieux ou la curieuse qui veut une introduction correcte à l'Internet, ou par l'enseignante ou l'enseignant qui veut l'utiliser comme base pour son cours.

Ah, et il y a plein de références bibliographiques : utile si vous vous ennuyez pendant le confinement. Vous aurez de quoi lire.


L'article seul

RFC 8767: Serving Stale Data to Improve DNS Resiliency

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : D. Lawrence (Oracle), W. Kumari (Google), P. Sood (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 1 avril 2020


Ce nouveau RFC autorise les résolveurs DNS à servir des « vieilles » informations aux clients (« vieilles » parce que le TTL est dépassé), si et seulement si les serveurs faisant autorité ne sont pas joignables (par exemple parce qu'ils sont victimes d'une attaque par déni de service.) Cela devrait rendre le DNS plus robuste en cas de problèmes. Le principe est donc désormais « mieux vaut du pain rassis que pas de pain du tout ».

Normalement, avant ce RFC, le DNS fonctionne ainsi : le client interroge un résolveur. Ce résolveur :

  • Soit possède l'information dans sa mémoire (dans son cache), et le TTL de cette information, TTL originellement choisi par le serveur faisant autorité, n'est pas encore dépassé ; le résolveur peut alors renvoyer cette information au client.
  • Soit n'a pas l'information (ou bien le TTL est dépassé) et le résolveur doit alors demander aux serveurs faisant autorité, avant de transmettre le résultat au client.

C'est ce que décrit le RFC 1035, notamment sa section 3.2.1. Ici, faite avec dig, une interrogation DNS, les données étant déjà dans le cache (la mémoire), ce qui se voit au TTL qui n'est pas un chiffre rond :


 % dig NS assemblee-nationale.fr
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57234
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
assemblee-nationale.fr.	292 IN NS ns2.fr.claradns.net.
assemblee-nationale.fr.	292 IN NS ns1.fr.claradns.net.
assemblee-nationale.fr.	292 IN NS ns0.fr.claradns.net.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb 20 11:09:57 CET 2020
;; MSG SIZE  rcvd: 120

  

Mais que se passe-t-il si le résolveur a des données, que le TTL est expiré, mais que les serveurs faisant autorité sont en panne (cas d'autant plus fréquent que beaucoup de domaines ont trop peu de serveurs, et qu'il y a souvent des SPOF), injoignables (par exemple suite à un problème de routage) ou bien victimes d'une DoS, comme cela arrive trop souvent ? Dans ce cas, le résolveur ne peut pas vérifier que les données sont à jour (alors que ce sera souvent le cas) et doit renvoyer une réponse SERVFAIL (Server Failure) qui empêchera le client d'avoir les informations qu'il demande. Dommage : après tout, peut-être que le client voulait se connecter au serveur imap.example.net qui, lui, marchait, même si les serveurs DNS faisant autorité pour example.net étaient en panne. C'est l'une des motivations pour cette idées des données rassises. Comme le note Tony Finch, cela rendra plus facile le débogage des problèmes réseau. Au lieu d'un problème DNS mystérieux, qui masque le problème sous-jacent, les opérateurs verront bien mieux ce qui se passe. (Quasiment toutes les opérations sur l'Internet commencent par une requête DNS, et les problèmes réseau sont donc souvent perçus comme des problèmes DNS, même si ce n'est pas le cas.)

De tels problèmes sont relativement fréquents, et le RFC et moi vous recommandons l'excellent article « When the Dike Breaks: Dissecting DNS Defenses During DDoS ».

C'est pour cela que notre RFC prévoit, dans des cas exceptionnels, d'autoriser le résolveur à outrepasser le TTL et à renvoyer des données « rassises ». En temps normal, rien ne change au fonctionnement du DNS mais, si les circonstances l'exigent, le client recevra des réponses, certes peut-être dépassées, mais qui seront mieux que rien. Le compromis habituel entre fraîcheur et robustesse est donc déplacé un peu en faveur de la robustesse.

Bref, depuis la sortie de notre RFC, un résolveur est autorisé à servir des données rassises, si les serveurs faisant autorité ne répondent pas, ou bien s'ils répondent SERVFAIL (Server Failure.) Il doit dans ce cas (section 4 du RFC) mettre un TTL strictement positif, la valeur 30 (secondes) étant recommandée, pour éviter que ses clients ne le harcèlent, et aussi parce qu'un TTL de zéro (ne pas mémoriser du tout) est parfois mal compris par certains clients DNS bogués (cf. section 6).

La section 5 donne un exemple de comment cela peut être mis en œuvre. Elle suggère d'utiliser quatre délais :

  • Le temps maximal pendant lequel faire patienter le client, 1,8 secondes étant la durée recommandée (par défaut, dig patiente 5 secondes, ce qui est très long),
  • Le temps maximal pour avoir une réponse, typiquement entre 10 et 30 secondes (le résolveur va donc continuer à chercher une réponse, même s'il a déjà répondu au client car le précédent temps maximal était dépassé),
  • L'intervalle entre deux essais quand on n'a pas réussi à obtenir une réponse, 30 secondes est le minimum recommandé, pour éviter de rajouter à une éventuelle DDoS en demandant sans cesse aux serveurs faisant autorité,
  • L'âge maximal des données rassises, avant qu'on décide qu'elles sont vraiment trop vieilles. Le RFC suggère de mettre entre 1 et 3 journées.

Si le résolveur n'a pas eu de réponse avant que le temps maximal pendant lequel faire patienter le client soit écoulé, il cherche dans sa mémoire s'il n'a pas des données rassises et, si oui, il les envoie au client. (C'est la nouveauté de ce RFC.)

La section 6 donne quelques autres conseils pratiques. Par exemple, quel âge maximal des données rassises choisir ? Une durée trop courte diminuera l'intérêt de ce RFC, une durée trop longue augmentera la consommation mémoire du résolveur. Une demi-journée permet d'encaisser la grande majorité des attaques par déni de service. Une semaine permet d'être raisonnablement sûr qu'on a eu le temps de trouver les personnes responsables (c'est souvent beaucoup plus dur qu'on ne le croit !) et qu'elles résolvent le problème. D'où la recommandation du RFC, entre 1 et 3 jours.

Pour la consommation de mémoire, il faut aussi noter que, si la limite du résolveur a été atteinte, on peut prioriser les données rassises lorsqu'on fait de la place, et les sacrifier en premier. On peut aussi tenir compte de la « popularité » des noms, en supprimant en premier les noms les moins demandés. Attention, un tel choix pourrait pousser certains à faire des requêtes en boucle pour les noms qu'ils trouvent importants, de manière à les faire considérer comme populaires.

Beaucoup de résolveurs ont deux mémoires séparées, une pour les données demandées par les clients, et une pour les données obtenues lors du processus de résolution lui-même. Ainsi, lorsqu'un client demande le MX de foobar.example, et que les serveurs faisant autorité pour foobar.example seront ns0.op.example et ns1.op.example, le résolveur devra à un moment découvrir l'adresse IP de ns0 et ns1.op.example (une « requête tertiaire », pour reprendre la terminologie du RFC 7626.) Cette adresse IP sera mémorisée, mais pas dans la même mémoire que le MX de foobar.example, car ces données n'ont pas forcément le même niveau de confiance (il peut s'agir de colles, par exemple, et pas de données issues d'un serveur faisant autorité). Le RFC autorise également à utiliser des données rassises pour cette seconde mémoire, donc pour la cuisine interne du processus de résolution. Ainsi, si un TLD est injoignable (comme c'était arrivé au .tr en décembre 2015, suite à une attaque par déni de service), les serveurs de noms sous ce TLD resteront peut-être utilisables, pour des nouvelles requêtes.

Notez que le client du résolveur n'a aucun moyen de dire s'il accepte des données rassises, ou bien s'il veut uniquement du frais. Il avait été discuté à l'IETF une option EDNS permettant au client de signaler son acceptation de vieilles données, mais cette option n'a pas été retenue (section 9), le but étant de fournir une technique qui marche avec les clients actuels, afin de renforcer la robustesse du DNS dès maintenant. Ce point est sans doute celui qui avait suscité les plus chaudes discussions.

La section 10 discute de quelques problèmes de sécurité liés au fait de servir des données rassises. Par exemple, une attaque existante contre le DNS est celle des « domaines fantômes » où un attaquant continue à utiliser un domaine supprimé (par exemple parce qu'il servait à distribuer du logiciel malveillant) en comptant sur les mémoires des résolveurs. (Voir à ce sujet l'artricle « Cloud Strife: Mitigating the Security Risks of Domain-Validated Certificates ».) Le fait de servir des données rassises pourrait rendre l'attaque un peu plus facile, mais pas plus : après tout, la réponse NXDOMAIN (ce domaine n'existe pas) de la zone parente supprime toutes les entrées de ce domaine dans la mémoire. D'autre part, un attaquant pourrait mettre hors d'état de service les serveurs faisant autorité pour une zone afin de forcer l'utilisation de données anciennes. Ceci dit, sans ce RFC, un attaquant ayant ce pouvoir peut faire des dégâts plus graves, en bloquant tout service.

À noter que notre RFC change également les normes précédentes sur un autre point, l'interprétation des TTL lorsque le bit de plus fort poids est à un (section 4). Le RFC 2181 disait (dans sa section 8) « Implementations should treat TTL values received with the most significant bit set as if the entire value received was zero. ». C'était pour éviter les problèmes d'ambiguité entre entiers signés et non signés. Le RFC 8767 change cette règle dit désormais clairement que le TTL est un entier non signé et que ces valeurs avec le bit de plus fort poids à un sont des valeurs positives. Il ajoute qu'elles sont tellement grandes (plus de 68 ans…) qu'elles n'ont pas d'intérêt pratique et doivent donc être tronquées (un TTL de plus d'une semaine n'a pas de sens et les résolveurs sont donc invités à imposer cette limite). Donc, en pratique, cela ne change rien.

Questions mises en œuvre, de nombreux résolveurs offrent un moyen de servir les données anciennes. L'idée est loin d'être nouvelle, elle existait avant le RFC, et était largement acceptée, quoique violant la norme technique. Bref, les données rassises existent déjà un peu partout. Ainsi, les logiciels privateurs Nomimum and Xerocole (utilisés par Akamai) peuvent le faire. Idem pour OpenDNS. Du côté des logiciels libres, BIND, Knot et Unbound ont tous cette possibilité, à des degrés divers.

Pour Unbound, les versions avant la 1.10 ne permettaient pas de suivre rigoureusement notre RFC 8767. Les options étaient (je cite le fichier de configuration d'exemple) :

	# Serve expired responses from cache, with TTL 0 in the response,
	# and then attempt to fetch the data afresh.
	# serve-expired: no
	#
	# Limit serving of expired responses to configured seconds after
	# expiration. 0 disables the limit.
	# serve-expired-ttl: 0
	#
	# Set the TTL of expired records to the serve-expired-ttl value after a
	# failed attempt to retrieve the record from upstream. This makes sure
	# that the expired records will be served as long as there are queries
	# for it.
	# serve-expired-ttl-reset: no
  

Notez donc qu'avec serve-expired, Unbound servait des données rassises avant même de vérifier si les serveurs faisant autorité étaient joignables. À partir de la version 1.10, cette configuration fonctionne et colle au RFC :

# Enable serve-expired
serve-expired: yes

# Time to keep serving expired records.
serve-expired-ttl: 86400 # One day

# Do not reset the TTL above on failed lookups
serve-expired-ttl-reset: no  # default

# TTL to reply with expired entries
serve-expired-reply-ttl: 30  # default

# Time to wait before replying with expired data
serve-expired-client-timeout: 1800
  

Si on met serve-expired-client-timeout à zéro (c'est la valeur par défaut), on garde l'ancien comportement (qui ne respecte ni les anciens RFC, ni le nouveau.)

Pour BIND, la possibilité de se contenter de vieilles données a été introduite dans la version 9.12. Les options pertinentes sont :

  • stale-answer-enable : active le service d'envoi de données dépassées, uniquement si les serveurs faisant autorité sont injoignables, ce qui est la recommandation du RFC,
  • max-stale-ttl : l'âge maximal des données rassises (une semaine par défaut),
  • stale-answer-ttl : le TTL des valeurs retournées, une seconde par défaut (alors que le RFC suggère trente secondes).

Et sur Knot ? Knot est modulaire et la possibilité de servir des données dépassées est dans un module Lua séparé, serve_stale (cf. modules/serve_stale/README.rst dans le source). Il sert des données dépassées pendant au maximum une journée. Il n'est apparemment configurable qu'en éditant le source Lua.


Téléchargez le RFC 8767


L'article seul

RFC 8773: TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : R. Housley (Vigil Security)
Expérimental
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 31 mars 2020


L'authentification dans TLS se fait typiquement, soit à partir d'un certificat, soit par une clé partagée à l'avance. Ce nouveau RFC spécifie une extension de TLS qui permet d'utiliser ces deux méthodes en même temps.

Rappelons d'abord qu'il y a deux sortes de clés partagées à l'avance (PSK, pour Pre-Shared Key) : celles qui ont été négociées dans une session précédentes (resumption PSK) et celles qui ont été négociées par un mécanisme extérieur (envoi par pigeon voyageur sécurisé…), les external PSK. Ce RFC ne concerne que les secondes. Les certificats et les clés partagées à l'avance ont des avantages et des inconvénients. Les certificats ne nécessitent pas d'arrangement préalable entre client et serveur, ce qui est pratique. Mais il faut se procurer un certificat auprès d'une AC. Et les certificats, comme ils reposent sur des algorithmes comme RSA ou ECDSA, sont vulnérables aux progrès de la cryptanalyse, par exemple en utilisant un (futur) ordinateur quantique. Utiliser une clé partagée à l'avance n'est pas forcément commode (par exemple quand on veut la changer) mais cela peut être plus sûr. Or, la norme TLS actuelle (RFC 8446) ne permet d'utiliser qu'une seule des deux méthodes d'authentification. Si on les combinait ? L'ajout d'une clé externe permettrait de rendre l'authentification plus solide.

Le principe est simple : notre RFC spécifie une extension à TLS, tls_cert_with_extern_psk (valeur 33.) Le client TLS l'envoie dans son ClientHello. Elle indique la volonté de combiner certificat et PSK. Elle est accompagnée d'extensions indiquant quelle est la clé partagée à utiliser. Si le serveur TLS est d'accord, il met l'extension tls_cert_with_extern_psk dans son message ServerHello. (Le serveur ne peut pas décider seul de l'utilisation de cette extension, il faut que le client ait demandé d'abord.)

Les clés ont une identité, une série d'octets sur lesquels client et serveur se sont mis d'accord avant (PSK = Pre-Shared Key, clé partagée à l'avance.) C'est cette identité qui est envoyée dans l'extension pre_shared_key, qui accompagne tls_cert_with_extern_psk. La clé elle-même est bien sûr un secret, connu seulement du client et du serveur (et bien protégée : ne la mettez pas sur un fichier lisible par tous.) Voyez la section 7 du RFC pour une discussion plus détaillée de la gestion de la PSK.

Une fois que client et serveur sont d'accord pour utiliser l'extension, et ont bien une clé en commun, l'authentification se fait via le certificat (sections 4.4.2 et 4.4.3 du RFC 8446) et en utilisant ensuite, non pas seulement la clé générée (typiquement par Diffie-Hellman), mais la combinaison de la clé générée et de la PSK. L'entropie de la PSK s'ajoute donc à celle de la clé générée de manière traditionnelle.

Du point de vue de la sécurité, on note donc que cette technique de la PSK est un strict ajout à l'authentification actuelle, donc on peut garantir que son utilisation ne diminuera pas la sécurité.

Il n'y a apparemment pas encore de mise en œuvre de cette extension dans une bibliothèque TLS.

Notez qu'il s'agit apparemment du premier RFC à mentionner explicitement les calculateurs quantiques, et les risques qu'ils posent pour la cryptographie.


Téléchargez le RFC 8773


L'article seul

Fiche de lecture : Tales from the wood

Auteur(s) du livre : Adrian Farrel
Éditeur : FeedaRead.com Publishing
978-1-78610-092-4
Publié en 2015
Première rédaction de cet article le 28 mars 2020


Tales from the wood est un recueil de nouvelles, qui reprennent des thèmes de contes de fées, mais les adaptent, souvent dans un sens plus noir.

Notez que, pendant la durée du confinement, certaines des nouvelles sont gratuitement disponibles en ligne.

L'auteur est Adrian Farrel et, en dehors de l'écriture de nouvelles, il est Independent Stream Editor à l'IETF, chargé, donc, de veiller sur les RFC de la voie indépendante (cf. RFC 8730.) Aux réunions IETF, il est le seul (avec moi) à embêter les participants à placer ses livres :-).

Mais revenons aux nouvelles. L'inspiration vient clairement des contes de fées traditionnels, plutôt du monde occidental (avec quelques exceptions). Le style est merveilleux, un anglais un peu précieux, avec beaucoup de vocabulaire. Le fond est modernisé (les femmes y ont un rôle moins inutile que dans les contes classiques), et, en général, assez noir (encore que les contes de fées traditionnels soient souvent assez durs.) Sans divulgâcher, disons que le conte se termine souvent mal et, pourtant, on veut toujours lire le suivant. Et les trois recueils qui suivent…

Vous pouvez acheter les livres sous forme papier ou bien sur le site Web. Notez que les textes sont sous une licence Creative Commons, CC-BY-SA-NC (partage à l'identique, mais pas d'utilisation commerciale.)


L'article seul

RFC 8749: Moving DNSSEC Lookaside Validation (DLV) to Historic Status

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : W. Mekking, D. Mahoney (ISC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 27 mars 2020


DLV (DNSSEC Lookaside Validation) était un mécanisme permettant de contourner le fait que plusieurs zones DNS importantes, dont la racine, n'étaient pas signées. Jamais très utilisé, et aujourd'hui inutile, DLV est ici officiellement abandonné, et les RFC le décrivant sont reclassés « intérêt historique seulement ».

Normalement, DNSSEC (RFC 4033 et suivants) suit le modèle de confiance du DNS. La résolution DNS part de la racine, puis descend vers les domaines de premier niveau, de deuxième niveau, etc. De même, un résolveur validant avec DNSSEC connait la clé publique de la racine, s'en sert pour valider la clé du premier niveau, qui sert ensuite pour valider la clé du deuxième niveau, etc. C'est ainsi que DNSSEC était prévu, et qu'il fonctionne aujourd'hui. Mais il y a eu une période de transition, pendant laquelle la racine, et la plupart des TLD, n'étaient pas signés. Le résolveur validant aurait donc dû gérer autant de clés publiques qu'il y avait de zones signées. Pour éviter cela, DLV (DNSSEC Lookaside Validation) avait été créé. Le principe de DLV était de mettre les clés des zones signées dans une zone spéciale (par exemple dlv.operator.example) et que les résolveurs cherchent les clés à cet endroit. Ainsi, le résolveur validant n'avait besoin que de la clé de la zone DLV. DLV a bien rempli son rôle, et a sérieusement aidé au déploiement de DNSSEC. Mais, aujourd'hui, les choses sont différentes, la racine (depuis 2010) et tous les TLD importants sont signés (1 389 TLD sur 1 531 sont signés, .fr l'a également été en 2010), et DLV n'a donc plus de raison d'être.

Bien sûr, il reste encore des zones de délégation non signées et donc en théorie des gens qui pourraient avoir besoin de DLV. Mais le consensus était clair à l'IETF sur l'abandon de DLV, car (section 3 de notre RFC) :

  • Le maintien de DLV risque de décourager les zones manquantes de signer (« pas la peine, les gens n'ont qu'à utiliser DLV »),
  • Toute occasion de simplifier le code des résolveurs (plus besoin du cas spécial de DLV) est bonne à prendre, et améliore la sécurité,
  • D'ailleurs, tous les résolveurs n'ont pas DLV et donc, de toute façon, il ne remplace pas un chemin de validation « normal ».

Il n'y avait en pratique d'une seule zone DLV sérieuse, dlv.isc.org, et elle a été arrêtée en 2017, il ne reste donc de toute façon plus d'utilisateurs connus de DLV.

Donc (section 4 de notre RFC), les deux RFC qui décrivaient DLV, le RFC 4431 et le RFC 5074 passent du statut « Pour information » à celui de « Intérêt historique seulement ». (Vous pouvez consulter les détails du processus.) Même chose pour le type d'enregistrement DNS DLV (code 32769), qui apparait désormais dans le registre IANA comme (OBSOLETE).


Téléchargez le RFC 8749


L'article seul

Un site Web multi-serveur multi-organisations sans trop de travail

Première rédaction de cet article le 22 mars 2020


Je viens de configurer un site Web qui est composé de plusieurs serveurs gérés par plusieurs personnes. Cet article est juste un partage d'expérience pour raconter quelques techniques utiles pour ce genre de service.

Le problème de départ était de distribuer certaines des ressources pédagogiques disponibles sur le site du CNED malgré la surcharge de leur serveur, qui était souvent inaccessible. Caroline De Haas avait copié les fichiers, il restait à les héberger. Il fallait aller vite (ces ressources étaient utiles aux parents d'élèves pendant la phase de confinement) et que cela ne soit pas trop cher puisque c'était fait par des volontaires. D'un autre côté, contrairement à ce qu'essaient de vous faire croire les ESN, simplement distribuer des fichiers statiques ne nécessite pas beaucoup de travail, et il n'y a pas besoin d'un serveur costaud. Pour des raisons aussi bien techniques (répartir la charge) que politiques (je trouve plus sympas les projets collectifs), le service devait être réparti sur plusieurs machines. On n'a évidemment pas manqué de volontaires et, rapidement, de nombreuses machines étaient disponibles. Reste à coordonner tout cela.

Le cahier des charges était que le service devait être disponible pour des utilisateurs ordinaires. Donc, du Web classique, pas de BitTorrent (qui aurait sans doute été mieux adapté à ce travail) et encore moins d'IPFS (très joli mais franchement difficile à gérer). Donc, juste un URL à connaitre, http://ressources-pedagogiques.org/. Pour réaliser un tel service, on peut faire passer toutes les requêtes HTTP par un répartiteur de charge (facile à réaliser, par exemple avec nginx) et envoyer ensuite aux différents serveurs. Problèmes, le répartiteur de charge est un SPOF, et cela n'est pas forcément efficace de rajouter systématiquement un intermédaire. Des solutions de plus haute technologie étaient possibles, à base d'anycast BGP, par exemple, mais pas accessibles à un groupe de volontaires sans moyens particuliers.

La solution choisie était donc de compter sur le DNS. On met les adresses de tous les serveurs dans le DNS et c'est le client DNS qui assure une répartition (plus ou moins raisonnable) du trafic. C'est loin d'être optimal mais c'est très simple, très robuste (presque aucun SPOF) et accessible à tous.

Le domaine ressources-pedagogiques.org est installé sur plusieurs serveurs DNS. Chaque fois qu'un serveur est configuré, je le teste et je l'ajoute à la zone. Le nom a actuellement 32 adresses IP. Si vous utilisez dig, vous pouvez les afficher (ou bien se servir du DNS looking glass, en suivant le lien précédent) :

    
% dig +bufsize=4096 AAAA ressources-pedagogiques.org

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> AAAA ressources-pedagogiques.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31490
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
ressources-pedagogiques.org. 6168 IN AAAA 2a03:7220:8080:f00::1
ressources-pedagogiques.org. 6168 IN AAAA 2a01:cb19:815f:cb00:f6b5:20ff:fe1b:bec3
ressources-pedagogiques.org. 6168 IN AAAA 2a01:cb08:89a3:b900:21e:6ff:fe42:2565
ressources-pedagogiques.org. 6168 IN AAAA 2a01:4f9:4a:1fd8::26
ressources-pedagogiques.org. 6168 IN AAAA 2a01:4f8:1c1c:42c9::1
ressources-pedagogiques.org. 6168 IN AAAA 2605:4500:2:245b::42
ressources-pedagogiques.org. 6168 IN AAAA 2001:4b98:dc0:43:216:3eff:fec4:c1a7
ressources-pedagogiques.org. 6168 IN AAAA 2001:41d0:a:f4b4::1
ressources-pedagogiques.org. 6168 IN AAAA 2001:41d0:a:1370::1
ressources-pedagogiques.org. 6168 IN AAAA 2001:bc8:47b0:723::1
ressources-pedagogiques.org. 6168 IN AAAA 2001:bc8:4400:2400::5327
ressources-pedagogiques.org. 6168 IN AAAA 2001:67c:288:32::38
ressources-pedagogiques.org. 6168 IN AAAA 2001:470:1f13:2f:0:ff:fe01:500

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Mar 22 15:33:41 CET 2020
;; MSG SIZE  rcvd: 443

  

(Et refaire la manipulation pour les adresses IPv4.)

Pour se synchroniser, les serveurs s'alimentent sur un site de référence, https://source.ressources-pedagogiques.org/ (ce nom, lui, ne pointe que vers une seule machine), typiquement en rsync (la documentation pour les gérants des serveurs miroir est sur le site.)

Voilà, c'est tout simple et ça marche. Mais il existe quelques pièges. Le premier est celui de la vérification des miroirs. Dans un tel service, géré par des personnes variées, il peut y avoir des miroirs mal configurés, qui tombent en panne, ou bien qui ne se synchronisent plus. Il est donc crucial de les tester, avant la mise en service, puis de temps en temps. J'utilise pour cela un petit script shell, check.sh, qui récupère les noms dans le DNS et appelle curl pour tester :

% ./check.sh    
2001:470:1f13:2f:0:ff:fe01:500 failed
%   
  

Ici, il y avait un problème de routage vers une adresse, et tous les autres serveurs sont corrects. Si vous lisez le script, l'option la plus intéressante de curl est --connect-to, qui permet de tester spécifiquement chaque serveur (il ne suffit pas de tester le service général.) Notez que Marc Chantreux a développé une version améliorée de ce script, rp-check-better.sh.

Une version légèrement différente du script me permet de tester un nouveau serveur lorsqu'on me le signale, rp-check-one.sh :

    
...
Connected to 2605:4500:2:245b::42 (2605:4500:2:245b::42) port 80 (#0)
> GET /ressources/CP/5CPM9TEWB0016_CahierDeBord_Presentation.pdf HTTP/1.1
> Host: ressources-pedagogiques.org
> User-Agent: ressources-pedagogiques.org checker
...
< HTTP/1.1 200 OK
< Content-Length: 262219
< Content-Type: application/pdf
... 

  

Tester que les serveurs marchent est une chose, il est également bon de vérifier qu'ils sont à jour. Le script de mise à jour du serveur de référence source.ressources-pedagogiques.org met la date dans un fichier, qu'on peut récupérer pour voir si tous les serveurs ont la même (ils lancent typiquement rsync depuis cron) :

% ./updates.sh 
2a03:7220:8080:f00::1 : 2020-03-20 13:47:37+00:00
2a01:cb19:815f:cb00:f6b5:20ff:fe1b:bec3 : 2020-03-20 13:47:37+00:00
2a01:cb08:89a3:b900:21e:6ff:fe42:2565 : 2020-03-20 13:47:37+00:00
2a01:4f9:4a:1fd8::26 : 2020-03-20 13:47:37+00:00
2a01:4f8:1c1c:42c9::1 : 2020-03-20 13:47:37+00:00
2605:4500:2:245b::42 : 2020-03-20 13:47:37+00:00
2001:4b98:dc0:43:216:3eff:fec4:c1a7 : 2020-03-20 13:47:37+00:00
2001:41d0:a:f4b4::1 : 2020-03-20 13:47:37+00:00
2001:41d0:a:1370::1 : 2020-03-20 13:47:37+00:00
2001:bc8:47b0:723::1 : 2020-03-20 13:47:37+00:00
2001:bc8:4400:2400::5327 : 2020-03-20 13:47:37+00:00
2001:67c:288:32::38 : 2020-03-20 13:47:37+00:00
2001:470:1f13:2f:0:ff:fe01:500 : ERROR 000
204.62.14.153 : 2020-03-20 13:47:37+00:00
195.154.172.222 : 2020-03-20 13:47:37+00:00
185.230.78.228 : 2020-03-20 13:47:37+00:00
185.34.32.38 : 2020-03-20 13:47:37+00:00
163.172.222.36 : 2020-03-20 13:47:37+00:00
163.172.175.248 : 2020-03-20 13:47:37+00:00
159.69.80.58 : 2020-03-20 13:47:37+00:00
95.217.83.231 : 2020-03-20 13:47:37+00:00
92.243.17.60 : 2020-03-20 13:47:37+00:00
91.224.149.235 : 2020-03-20 13:47:37+00:00
91.224.148.15 : 2020-03-20 13:47:37+00:00
86.250.18.250 : 2020-03-20 13:47:37+00:00
83.205.2.135 : 2020-03-20 13:47:37+00:00
62.210.124.111 : 2020-03-20 13:47:37+00:00
51.255.9.60 : 2020-03-20 13:47:37+00:00
51.15.229.92 : 2020-03-20 13:47:37+00:00
37.187.123.180 : 2020-03-20 13:47:37+00:00
37.187.19.112 : 2020-03-20 13:47:37+00:00
5.135.190.125 : 2020-03-20 13:47:37+00:00
  

Une telle configuration ne permet pas facilement de mettre du HTTPS sur le service : il faudrait distribuer la clé privée à tous les miroirs. À noter également que l'utilisation d'un nom de domaine unique permet à chaque gérant de miroir d'avoir une chance d'obtenir un certificat (et, en effet, j'ai vu dans le journal passer le vérificateur de Let's Encrypt.)

Autre sujet de réflexion : la vie privée. Personne n'a la main sur tous les serveurs du service, il faut donc faire confiance à chaque gérant de miroir pour respecter les principes de protection des données (pas trop de données dans le journal, et ne pas trop les garder.)

Pourrait-on ajouter des miroirs ? Il y a un léger problème technique avec des limites DNS. Il y a l'ancienne limite de 512 octets (qui n'est normalement plus d'actualité depuis longtemps ; notez qu'en IPv6, avec DNSSEC, on a déjà dépassé cette vieille limite.) Il y a la limite plus significative de 1 500 octets (la MTU d'Ethernet.) Mais, surtout, il est plus difficile d'assurer la qualité, notamment de la synchronisation, avec beaucoup de machines. Il faut tester, prendre contact avec les administrateurs des serveurs, relancer, etc.


L'article seul

Fiche de lecture : We have no idea

Auteur(s) du livre : Jorge Cham, Daniel Whiteson
Éditeur : John Murray
976-1-473-66020-5
Publié en 2017
Première rédaction de cet article le 22 mars 2020


Les livres de vulgarisation scientifique se consacrent souvent à ce qu'on sait : ce qu'on a découvert, publié, et avec lequel on peut émerveiller les lecteurs « on va vous expliquer la quantique, on va vous dire tout ce que la neuroscience permet, etc ». Ici, l'angle est différent, ce livre est consacré à ce qu'on ne sait pas, en physique et astrophysique. C'est une banalité de dire qu'il y a beaucoup plus de choses qu'on ne connait pas que de choses qu'on connait. Mais quelles sont les choses dont on sait qu'on ne les connait pas ?

Évidemment, le livre commence par la matière noire et l'énergie noire. On a de bonnes raisons de penser qu'elles existent, mais on ne sait quasiment rien d'elles. (Personnellement, cela me fait penser à l'éther du début du 20e siècle, qui semblait certain, mais qui a fini par être abandonné.) Autre classique du « nous ne savons pas », la place de la gravité dans les différentes interactions possibles : pourquoi est-elle la seule interaction sans théorie quantique ? Et d'où viennent les rayons cosmiques ? Nous ne savons pas (enfin, pas pour tous.) Et pourquoi y a-t-il davantage de matière que d'antimatière ?

Le livre est drôle (j'ai bien aimé les dessins, même si le parti pris de tout prendre à la légère est parfois un peu agaçant), très bien expliqué, et, pour autant que je puisse en juger (mais je ne suis pas physicien), très correct. Un bon moyen de méditer sur la taille de l'univers et ce qu'il contient.


L'article seul

RFC 8762: Simple Two-way Active Measurement Protocol

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : G. Mirsky (ZTE), G. Jun (ZTE), H. Nydell (Accedian Networks), R. Foote (Nokia)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF ippm
Première rédaction de cet article le 20 mars 2020


Ce nouveau RFC décrit un protocole simple pour piloter des mesures comme celle de la latence ou comme le taux de pertes de paquets entre deux points. Il fonctionne pour des mesures aller-simple (unidrectionnelles) et aller-retour (bidirectionnelles.)

Mais, vous allez me dire, il existe déjà un tel protocole, TWAMP, normalisé dans le RFC 5357, et dans quelques RFC suivants comme le RFC 6038. TWAMP est mis en œuvre dans plusieurs systèmes, et fonctionne. Le problème est que TWAMP est riche et complexe, et que sa simplifiation TWAMP Light (annexe 1 du RFC 5357) est apparemment insuffisamment spécifiée, menant à des problèmes d'interopérabilité. Voir par exemple le rapport « Performance Measurement from IP Edge to Customer Equipment using TWAMP Light ».

Les grandes lignes de STAMP (Simple Two-way Active Measurement Protocol) sont décrites dans la section 3 de notre RFC. Comme TWAMP, STAMP sépare les fonctions de contrôle du test, et le test lui-même. Contrairement à TWAMP, la norme STAMP ne décrit que le test (rappelez-vous que STAMP se veut plus simple que TWAMP). Le contrôle est fait de l'extérieur, par des programmes en ligne de commande, par Netconf ou par un autre moyen.

Avec STAMP, il y a deux acteurs, le Session-Sender qui envoie les paquets, et le Session-Reflector, qui répond. Les paquets sont de l'UDP vers le port 862, et contiennent un numéro de séquence qui permet d'associer requête et réponse. (La réponse contient davantage de données que la requête, mais la requête est remplie, pour avoir la même taille, afin d'éviter les attaques avec amplification.) STAMP a deux modes de fonctionnement (section 4 du RFC) :

  • Sans état ; le Session-Reflector ne se souvient pas des numéros de séquence déjà vus, il se contente de répondre à chaque paquet, en recopiant le numéro dans la réponse.
  • Avec état ; le Session-Reflector se souvient des numéros de séquence. Ce mode permet, par exemple, de calculer le taux de perte de paquets (en voyant les trous dans la séquence) dans chaque direction, alors que le mode sans état est limité au bidirectionnel (trajet aller/retour, sans pouvoir distinguer la contribution de l'aller et celle du retour.)

Le paquet STAMP inclus, outre le numéro de séquence déjà cité, une estampille temporelle, par défaut au format utilisé par NTP (cf. RFC 5905, section 6.) Un accord entre les deux parties (souvenez-vous que STAMP ne décrit pas comment l'envoyeur et le réflecteur sont coordonnés) permet d'utiliser d'autres formats comme celui de PTP (RFC 8186.)

L'authentification n'est pas indispensable et, si on ne l'utilise pas, le paquet peut être modifié par un attaquant actif qui cherche à fausser les mesures. STAMP a également une possibilité d'authentification, où le paquet contient en outre un HMAC (RFC 2104, et section 4.4 de notre RFC.)

Dans sa réponse, le Session-Reflector envoie un paquet qui indique son propre numéro de séquence, sa propre estampille temporelle, et les numéros de séquence et estampille temporelle du paquet reçu. (En outre, dans le mode avec état, le Session-Reflector enregistre les informations du paquet entrant.) Au retour, le Session-Sender peut donc calculer le RTT, la gigue et le taux de pertes. (Dans le mode avec état, le Session-Reflector peut lui aussi calculer ces informations, qui auront l'avantage de ne concerner qu'une seule direction des paquets.)

Notez que STAMP n'a aucune confidentialité. Si on veut empêcher un méchant de lire les informations, il faut emballer le tout, par exemple dans IPsec ou DTLS. Ce point est un de ceux qui avaient suscité les plus vives discussions à l'IETF, certains regrettant qu'il n'y ait pas de sécurité standard.

Notez également qu STAMP et TWAMP-Light peuvent partiellement interopérer, puisque le format de paquets et la sémantique sont les mêmes (en non authentifié, uniquement.)

Je n'ai pas trouvé de mise en œuvre de STAMP, ni en logiciel libre, ni en privateur. Je ne connais pas non plus de liste de serveurs STAMP publics.


Téléchargez le RFC 8762


L'article seul

RFC 2418: IETF Working Group Guidelines and Procedures

Date de publication du RFC : Septembre 1998
Auteur(s) du RFC : Scott Bradner (Harvard University)
Première rédaction de cet article le 19 mars 2020


Comment ça, ce RFC est vieux ? Oui, il l'est mais il est toujours d'actualité plus de vingt ans après, et fait toujours autorité. Il décrit le fonctionnement des groupes de travail de l'IETF.

Petit rappel : l'IETF est l'organisme qui normalise les protocoles de l'Internet, « de la couche réseau à la couche applications ». Le mécanisme de production des normes est spécifié dans le RFC 2026, et les structures utilisées sont dans le RFC 2028. Pour exécuter ce mécanisme, l'IETF est divisée en groupes de travail (Working Group) et ce RFC décrit comment ils sont censés fonctionner. Si vous êtes curieux ou curieuse, regardez la liste des groupes de travail actuels (ils sont 119 au moment où j'écris ces lignes, il y en avait déjà plus de 100 au moment de la rédaction du RFC.) Les groupes sont regroupés en zones (areas) et il y en sept à l'heure actuelle. Par exemple, le groupe de travail QUIC, qui normalise le protocole de même nom, fait partie de la zone Transport (Transport Area.) Si vous voulez savoir comment sont désignés les directeurs de chaque zone (AD, pour Area Director), lisez le RFC 7437. Ensemble, ces directeurs forment l'IESG, la direction technique de l'IETF.

L'IETF n'a pas de membres à proprement parler. Tout le monde peut participer (contrairement à la grande majorité des organisations de normalisation), ce qui se fait via les listes de diffusion et dans des réunions physiques, quand elles ne sont pas annulées pour cause d'épidémie.

Revenons aux groupes de travail. Contrairement à beaucoup d'organisations de normalisation, l'IETF a des groupes de travail qui sont, sauf exception, focalisés sur une tâche bien précise, et qui ont une durée de vie limitée. Un groupe qui réussit est un groupe qui sera fermé, ceux qui trainent des années et des années ne sont pas en général les plus efficaces.

D'abord, comment est-ce qu'on crée un groupe de travail ? La section 2 du RFC décrit la naissance d'un groupe. Le point de départ est en général un individu ou un groupe d'individus qui décident qu'un problème technique donné est à la fois important, et traitable par l'IETF. Rappelons qu'on ne fait pas un groupe juste pour bavarder. Il doit y avoir un but précis, et réaliste. Première étape, en parler aux directeurs de la zone concernée. (Note personnelle : je me souviens d'être passé par ces étapes pour le projet « DNS privacy », qui a donné naissance au groupe dprive.) C'est l'IESG qui décide ou non de créer le groupe. Les critères :

  • Une bonne compréhension du problème (l'IETF n'est pas un organisme de recherche, et ne travaille pas sur des problèmes ouverts),
  • Des objectifs réalistes et atteignables (« supprimer le spam » ou bien « rendre impossible les problèmes de sécurité » ne sont pas réalistes),
  • Sujet non déjà traité dans un groupe existant,
  • De claires indications que des gens vont effectivement travailler sur le problème ; il ne suffit pas que des gens aient dit « ce serait bien que », il faut des volontaires déterminés à écrire les futurs RFC, la normalisation, c'est du travail,
  • Et que ces gens soient compétents sur le sujet, ce qui n'est pas toujours évident sur certains problèmes où les experts ne sont pas à l'IETF,
  • Et que le projet ne vienne pas d'une seule personne, ou d'une seule entreprise (qui, dans ce cas, pourrait très bien se débrouiller seule) ; le RFC estime qu'il faut au moins quatre à cinq personnes actives, et une ou deux douzaines qui suivent de près, pour que le groupe ait un sens,
  • L'IETF ne travaille pas pour l'amour de l'art, il faut aussi des indications comme quoi le résultat sera vraiment utilisé en vrai dans le vrai monde,
  • Et le RFC suggère aussi de regarder si le travail ne serait pas mieux fait en dehors de l'IETF, citant l'exemple de clubs privés d'organisations (comme 3GPP) ; politiquement, cela me semble contestable qu'une organisation ouverte comme l'IETF envisage de laisser le champ libre à ces clubs privés,
  • Que les questions de propriété intellectuelle liées à ce sujet soient bien comprises (vœu pieux, vu leur complexité),
  • Que le projet implique une vraie action de l'IETF, pas juste un coup de tampon approbateur sur une technologie déjà développée complètement à l'extérieur (problème fréquent dans des organisations comme l'ISO ou l'ETSI.) Je mentionnais QUIC précédemment : l'IETF a beaucoup modifié la version originelle, proposée par Google.

Pour tester tous ces points, il y aura parfois une session relativement informelle, la BoF, avant la décision finale de créer le groupe (voir aussi la section 2.4 qui détaille ces BoF, et le RFC 5434, publié par la suite.)

Étape suivante, le groupe a besoin d'une charte qui définit son but (regardez par exemple celle du groupe quic.) Notez que les chartes indiquent des étapes, avec des dates, qui ne sont quasiment jamais respectées (celles du groupe quic viennent d'être prolongées.) La charte indique également :

  • Le nom du groupe ; l'humour geek est souvent présent et on voit des groupes nommés clue, bier, kitten, tictoc…
  • Les personnes responsables, les deux co-présidents du groupe, et le directeur de zone qui supervise ce groupe,
  • La liste de diffusion du groupe, puisque c'est le principal outil de travail de l'IETF, pour assurer la traçabilité du travail, elles sont toutes archivées sur le service MailArchive (voici par exemple le travail de quic.)

Le dernier groupe créé, au moment de la publication de cet article, est le groupe webtrans.

Une fois créé, comment fonctionne le groupe ? Les groupes disposent d'une grande autonomie, l'IETF essaie de ne pas trop micro-gérer chaque détail (c'est pas complètement réussi.) L'idée de base est que le groupe doit être ouvert, et atteindre des décisions par le biais du « consensus approximatif » (approximatif pour éviter qu'un râleur isolé n'aie un droit de veto sur le groupe.) En pratique, c'est aux présidents du groupe de gérer ce fonctionnement. Les règles sont plutôt des guides que des lois formelles à respecter absolument. Donc, les règles :

  • L'activité de l'IETF est publique (contrairement à des organismes comme l'ISO) donc les groupes également,
  • L'essentiel de l'activité doit se faire en ligne (même en l'absence de confinement), pour éviter d'exclure ceux qui ne peuvent pas se déplacer, via une liste de diffusion (exemple, celle du groupe regext, qui normalise les interfaces des registres),
  • Mais il y a quand même des réunions physiques, normalement trois fois par an, même si elles n'ont normalement pas de pouvoir de décision (toujours pour éviter d'exclure les gens qui n'ont pas pu venir, par exemple pour des raisons financières),
  • (D'ailleurs, opinion personnelle, les réunions formelles des groupes de travail sont parfois assez guindées, avec peu de réel travail, celui-ci se faisant hors réunion, dans les couloirs ou bien en ligne),
  • Le consensus approximatif est une notion difficile, qui n'est pas rigoureusement définie, pour éviter des règles trop rigides, le RFC note toutefois que 51 % des participants, ce n'est pas un consensus,
  • Et comment estimer s'il y a consensus ? Dans la salle, on peut faire lever les mains, ou procéder au humming (procédure où on émet un son la bouche fermée, l'intensité du son permet de juger du soutien de telle ou telle position, cf. RFC 7282), qui a l'avantage d'un relatif anonymat, sur la liste de diffusion, c'est plus difficile, le RFC met en garde contre un simple comptage des messages, qui favorise les gens les plus prompts à écrire beaucoup ; là encore, ce sera aux présidents du groupe de déterminer le consensus.

Et une fois que le groupe a bien travaillé, et produit les documents promis ? On a vu que l'IETF n'aimait guère les groupes qui trainent dix ans sans buts précis, donc l'idéal est de mettre fin au groupe à un moment donné (section 4). Au moment de la rédaction de cet article, c'est ce qui vient d'arriver au groupe doh (qui avait normalisé le protocole du même nom, cf. l'annonce de la terminaison, et la page actuelle du groupe.)

Toute cette activité nécessite du monde, et il y a donc plusieurs postes importants à pourvoir (section 6 du RFC). D'abord, les président·e·s des groupes de travail. Il est important de comprendre que ce ne sont pas eux ou elles qui vont écrire les documents. Leur rôle est de faire en sorte que le groupe fonctionne, que les travaux avancent, mais pas de rédiger. C'est déjà pas mal de travail, entre les groupes où ça s'engueule, les trolls négatifs, ou bien les auteurs qui ne bossent pas et qui ne répondent pas aux sollicitations (je plaide coupable, ici, j'ai fait souffrir plusieurs présidents de groupe.) Les présidents sont responsables du résultat, il faut que les normes soient produites, et qu'elles soient de qualité. Cela implique une activité de modération de la liste (pas la censure, comme entend souvent aujourd'hui ce terme de « modération », mais des actions qui visent à calmer les discussions), l'organisation des sessions physiques, la production de compte-rendus de ces réunions, la distribution des tâches (il n'y a pas que l'écriture, il y a aussi la lecture, il faut s'assurer que les documents ont été attentivement relus par plusieurs personnes compétentes) et d'autres activités.

Et comme il faut bien que quelqu'un écrive, il faut également au groupe des rédacteurs. On les appelle parfois « auteurs », parfois « éditeurs », pour mettre en avant le fait que le vrai auteur est le groupe de travail. Quelque soit le terme, le travail est le même : rédiger, relire, intégrer les décisions du groupe de travail, etc. C'est un travail souvent ardu (je parle d'expérience.)

Une autre catégorie d'acteurs du groupe de travail est celle des design teams. Un design team est un sous-ensemble informel du groupe de travail, chargé de travailler à un projet lorsqu'il semble que le groupe entier serait trop gros pour cela. Les design teams ne sont pas forcément formalisés : deux personnes dans un couloir décident de travailler ensemble, et c'est un design team.

Le but final est de produire des documents. La section 7 du RFC décrit le processus d'écriture. Tout futur RFC commence sa vie comme Internet-Draft. (Le meilleur moyen d'accéder aux Internet-Drafts est sans doute le DataTracker.) Comme leur nom l'indique, les Internet-Draft sont des brouillons, pas des documents définitifs. N'importe qui peut écrire et soumettre (notez que les instructions dans le RFC ne sont plus d'actualité) un Internet-Draft, sa publication ne signifie aucune approbation par l'IETF. Si vous ressentez le désir d'en écrire un, notez que les instructions du RFC sur le format désormais dépassées, il faut plutôt lire le RFC 7990.

Une fois le document presque prêt, il va passer par l'étape du dernier appel au groupe (WGLC, pour Working Group Last Call.) Comme son nom l'indique, ce sera la dernière occasion pour le groupe d'indiquer si le document est considéré comme publiable. Après, il quittera le groupe et sera de la responsabilité de l'IETF toute entière, via l'IESG (section 8 de notre RFC.)

Ce RFC est ancien, je l'avais dit, et plusieurs mises à jour ont eu lieu depuis, sans le remplacer complètement. Cela a été le cas des RFC 3934, RFC 7475 et RFC 7776.


Téléchargez le RFC 2418


L'article seul

RFC 8748: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : R. Carney (GoDaddy), G. Brown (CentralNic Group), J. Frakes
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 15 mars 2020


Historiquement, le protocole EPP d'avitaillement des ressources Internet (notamment les noms de domaine) n'indiquait pas le prix de création ou de renouvellement d'un nom. Typiquement, tous les noms coûtaient le même prix. Mais certains registres préfèrent vendre plus cher sex.example que suitedelettressanstropdesignification.example. D'où cette extension EPP qui permet d'indiquer le coût d'un nom de domaine particulier, extension qui est aujourd'hui très répandue.

Il y a donc deux logiques possibles, une purement technique (les noms de domaine ont tous le même coût pour le registre et devraient donc coûter pareil au client) et une logique business, où on essaie de faire payer le client plus cher pour les noms les plus demandés. Aux débuts d'EPP (ou de son prédécesseur RGP, dans le RFC 3915), il allait de soi qu'il n'y avait qu'un prix puisque les coûts réels sont les mêmes pour tous les domaines, mais ce n'est plus le cas aujourd'hui. Il faut donc pouvoir informer sur les prix, EPP n'étant pas juste un canal technique mais aussi un canal de vente. Comme cela avait été dit lors d'une discussion à l'IETF, « Arguably, in a situation where many TLDs are now offering domains at various pricing tiers (with no further policy requirements), general availability is no longer just a matter of "domain taken/reserved/valid?", but also of "how much is the registrant willing to pay?". »

L'ancien modèle était donc :

  • Certaines opérations sur les objets avitaillés (cf. RFC 5730) sont payantes, typiquement <create>, <renew> et <transfer>, d'autres gratuites (par exemple <update>),
  • Le prix est le même pour tous les domaines,
  • Ce prix n'est pas indiqué via le canal EPP, on le découvre dans la documentation fournie par le registre.

Le nouveau modèle, où le tarif est indiqué via le canal EPP, permet d'avoir des prix différents par domaine, mais permet également de découvrir automatiquement le tarif, sans se plonger dans la documentation.

La section 3 du RFC décrit ce qui se passe dans chaque commande EPP facturable. L'extension utilise un espace de noms XML qui vaut urn:ietf:params:xml:ns:epp:fee-1.0 (abrégé à fee: dans les exemples du RFC mais bien sûr, comme toujours avec les espaces de noms XML, chacun choisit son abréviation.) Voici un exemple où le client vérifie la disponibilité d'un domaine et son prix, avec <check> :


<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
       <domain:check
          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>example.net</domain:name>
       </domain:check>
   </check>
  <extension>
    <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
      <fee:currency>USD</fee:currency>
      <fee:command name="create">
        <fee:period unit="y">2</fee:period>
      </fee:command>
    </fee:check>
  </extension>
  </command>
</epp>
	    
  

Le client a demandé quel était le prix en dollars étatsuniens pour une réservation de deux ans. Ici, le serveur lui répond que le domaine est libre (avail="1") :


...
  <resData>
    <domain:chkData
      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:cd>
        <domain:name avail="1">example.net</domain:name>
      </domain:cd>
    </domain:chkData>
  </resData>
  <extension>
       <fee:cd avail="1">
        <fee:objID>example.net</fee:objID>
        <fee:class>standard</fee:class>
        <fee:command name="create" standard="1">
          <fee:period unit="y">2</fee:period>
          <fee:fee
            description="Registration Fee"
            refundable="1"
            grace-period="P5D">10.00</fee:fee>
        </fee:command>
...  

  

Et qu'il en coûtera dix dollars. Notez que le prix dépend de la commande (d'où le <fee:command name="create"> chez le client, et dans la réponse) ; un renouvellement peut coûter moins cher qu'une création, par exemple. Notez aussi que le RFC ne spécifie pas comment le prix est déterminé ; cela peut être configuré manuellement par le registre, ou bien suivre un algorithme (prix plus élevé si le nom est dans un dictionnaire, ou s'il fait moins de N caractères…)

Le serveur EPP aurait pu refuser, si les paramètres étaient inconciliables avec sa politique :


<fee:cd avail="0">
    <fee:objID>example.net</fee:objID>
    <fee:reason>Only 1 year registration periods are
    valid.</fee:reason>
</fee:cd>

  

En quelle monnaie sont indiqués les coûts ? Un élément XML <fee:currency> va permettre de l'indiquer. Sa valeur est un code à trois lettres tiré de la norme ISO 4217, par exemple EUR pour l'euro et CNY pour le yuan. Si le registre se fait payer, non pas dans une monnaie reconnue mais dans une unité de compte privée (des « crédits » internes, par exemple), il peut utiliser le code XXX. Le serveur ne doit pas faire de conversion monétaire. S'il a indiqué des coûts en dollars étatsuniens et que le client indique ce qu'il paie en pesos mexicains, le serveur doit rejeter la commande (ce qui est logique, vu la volatilité des taux de conversion.)

Cette extension à EPP permet également d'indiquer des périodes pendant lesquelles les objets, par exemple les noms de domaine, sont enregistrés. L'unité de temps (mois ou année) est indiquée également.

L'extension permet également d'indiquer des actions commerciales comme une remise, un remboursement (par exemple en cas d'utilisation de la période de grâce du RFC 3915), etc.

Un mécanisme courant chez les registres est d'avoir un compte par client, où le client dépose une certaine somme, d'où les créations ultérieures de noms de domaine sont déduites. Cela donne au registre de la trésorerie, et cela simplifie la comptabilité. L'extension de ce RFC permet de consulter le montant restant (balance) et d'indiquer si l'épuisement de ce compte signifie un arrêt des opérations payantes, ou bien si le serveur fait crédit au client.

Les prix peuvent dépendre du nom de domaine (hotels.example étant plus cher que fzoigqskjjazw34.example) mais aussi de la phase actuelle des enregistrements. Par exemple, une phase initiale, dite de « lever de soleil » (RFC 8334) pour un nouveau domaine d'enregistrement peut avoir des prix plus élevés.

Le serveur peut exiger que le client marque son approbation en indiquant, dans ses requêtes, le prix à payer (section 4). Voilà ce que cela donnerait pour la commande de création :


...
  <command>
     <create>
       <domain:create
         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
         <domain:name>example.net</domain:name>
         <domain:period unit="y">2</domain:period>
         <domain:registrant>jd1234</domain:registrant>
         ...
       </domain:create>
     </create>
     <extension>
       <fee:create xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
         <fee:currency>USD</fee:currency>
         <fee:fee>10.00</fee:fee>
       </fee:create>
     </extension>
   </command>

Pour une demande de vérification de disponibilité (<check>), le serveur peut répondre que le domaine n'est pas libre si le client n'utilise pas l'extension de coût. Le principe est que, si un <check> indique qu'un domaine est libre, un <create> avec les mêmes extensions ou la même absence d'extension doit réussir. « Libre » veut donc dire « libre, aux conditions que tu as indiquées ».

Les détails de l'extension dans toutes les commandes EPP figurent en section 5, et le schéma en section 6.

L'extension décrite dans le RFC a été ajoutée au registre des extensions EPP, spécifié par le RFC 7451.

Cette extension EPP est déjà mise en œuvre par CentralNic et par d'autres registres mais attention, pas forcément avec la version du RFC, cela peut être des brouillons antérieurs.


Téléchargez le RFC 8748


L'article seul

RFC 8739: Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)

Date de publication du RFC : Mars 2020
Auteur(s) du RFC : Y. Sheffer (Intuit), D. Lopez, O. Gonzalez de Dios, A. Pastor Perales (Telefonica I+D), T. Fossati (ARM)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 12 mars 2020


Quand une Autorité de Certification (AC) émet un certificat numérique, une question de sécurité se pose : que se passe-t-il si un attaquant met la main sur la clé privée associée à ce certificat, et peut donc usurper l'identité du titulaire légitime ? La réponse traditionnelle était la révocation du certificat par l'AC dès qu'elle est prévenue. Pour diverses raisons, ce processus de révocation est peu fiable, ce qui laisse comme seule ligne de défense l'expiration du certificat. C'est le rôle du champ « Not After » dans un certificat. Pour la sécurité, on voudrait que la date d'expiration soit proche, pour ne pas laisser un éventuel attaquant profiter de son forfait trop longtemps. Mais ce n'est pas très pratique pour le titulaire que de renouveller son certificat très souvent, même avec un protocole comme ACME qui permet l'automatisation. Ce nouveau RFC propose une extension à ACME, qui autorise des certificats de très courte durée de vie (quelques jours seulement) mais renouvellés encore plus facilement qu'avec le ACME classique.

Petit rappel sur ACME : ce protocole, normalisé dans le RFC 8555, permet d'obtenir de manière automatique un certificat correspondant à une identité qui est, la plupart du temps, un nom de domaine. Comme ACME permet l'automatisation, il résout le problème de la révocation en utilisant des certificats dont la durée de vie se compte en mois et plus en années. Ainsi, l'AC Let's Encrypt émet des certificats qui durent trois mois. Mais même trois mois, ça peut être long, si quelqu'un a piqué votre clé privée et se sert de ce certificat. Si on souhaite des certificats durant quelques jours, peut-on utiliser ACME ? En théorie, oui, mais, en pratique, l'AC pourrait ne pas aimer cette charge supplémentaire, et puis que ferait le titulaire si l'AC était indisponible pendant 48 h et qu'on ne puisse pas renouveller le certificat ?

D'où l'idée des certificats STAR (Short-Term, Automatically-Renewed), initialement décrits dans l'article « Towards Short-Lived Certificates », de Topalovic, E., Saeta, B., Huang, L., Jackson, C., et D. Boneh, puis dans l'Internet-Draft draft-nir-saag-star. Les certificats seront de très courte durée de vie, et publiés un peu à l'avance par l'AC, sans demande explicite du client. Celui-ci pourra par contre demander l'interruption de la série de certificats, si sa clé privée a été compromise.

La section 2 de notre RFC explique le déroulement des opérations. Le client (IdO, pour Identifier Owner) demande à l'AC une série de certificats STAR, l'AC, aux intervalles indiqués, crée et publie les certificats, à tout moment, l'IdO peut arrêter la série. Commençons par le commencement, le démarrage de la série. C'est du ACME classique (RFC 8555), avec ses défis (par exemple, l'IdO doit prouver qu'il contrôle bien le nom de domaine qui sert d'identité). L'IdO doit envoyer l'extension ACME nommée auto-renewal. L'AC indique au client où seront publiés les certificats de la série.

Ensuite, la publication de la série. Tous les certificats de la série utilisent la même clé privée. (Par défaut, les clients ACME classiques créent une nouvelle clé pour chaque renouvellement du certificat.) Ces certificats sont publiés à l'URL annoncé à la fin de la phase précédente.

Lorsqu'il le souhaite, l'IdO peut demander à l'AC d'interrompre la publication de la série de certificats. Notez qu'on ne révoque jamais ces certificats STAR, puisque de toute façon ils expirent très vite.

Les détails du protocole figurent en section 3 du RFC. Ainsi, l'objet auto-renewal (désormais dans le registre des champs de l'objet Order) a plusieurs champs intéressants, comme start-date (début de la série), end-date (fin de la série, mais elle pourra se terminer plus tôt, en cas d'annulation explicite), lifetime (durée de vie des certificats, notez que la valeur réelle dépendra de la politique de l'AC, cf. section 6.2). Voici un exemple de cet objet, à ajouter aux requêtes de demande de certificat :

"auto-renewal": {
          "start-date": "2019-01-10T00:00:00Z",
          "end-date": "2019-01-20T00:00:00Z",
          "lifetime": 345600,          // 4 days
          "lifetime-adjust": 259200    // 3 days
        }
  

Les champs possibles dans un auto-renewal sont listés dans un registre IANA. D'autres champs pourront être ajoutés dans le futur, en suivant la politique « Spécification nécessaire » (RFC 8126.)

L'objet Order (section 7.1.6 du RFC 8555 sera en état ready tant que la série des certificats continuera.

L'AC annoncera sa capacité à faire du STAR (ici à la fin de son annonce) :

     {
       "new-nonce": "https://example.com/acme/new-nonce",
       "new-account": "https://example.com/acme/new-account",
       "new-order": "https://example.com/acme/new-order",
       ...
       "meta": {
         "terms-of-service": "https://example.com/acme/terms/2017-5-30",
         ...
         "auto-renewal": {
           "min-lifetime": 86400,
           "max-duration":  31536000,
           "allow-certificate-get": true
         }
       }
    }
  

Pour arrêter la série avant end-date, le client ACME mettra cet état à canceled :

POST /acme/order/ogfr8EcolOT HTTP/1.1
Host: example.org
Content-Type: application/jose+json

{
       "protected": base64url({
         "alg": "ES256",
         "kid": "https://example.com/acme/acct/gw06UNhKfOve",
         "nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
         "url": "https://example.com/acme/order/ogfr8EcolOT"
       }),
       "payload": base64url({
         "status": "canceled"
       }),
       "signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
}
  

Le serveur ACME répondra alors 403 à toutes les requêtes de récupération d'un certificat de la série annulée, de préférence en ajoutant (RFC 7807) urn:ietf:params:acme:error:autoRenewalCanceled. (Cette erreur, et quelques autres, ont été ajoutées au registre des erreurs ACME.)

Comme vous avez vu, la théorie est simple. Maintenant, il y a un certain nombre de détails opérationnels sur lesquels il faut se pencher, détaillés en section 4. D'abord, le problème des horloges. Les certificats X.509 utilisent partout des temps (la date limite de validité, par exemple) et le respect de ces temps dépend de l'horloge de la machine. Si votre ordinateur a deux mois d'avance, il considérera les certificats comme expirés alors qu'ils ne devraient pas l'être. C'est un problème général de la cryptographie, comme montré par l'article « Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors », qui signale que des déviations de plusieurs jours chez les clients ne sont pas rares. Mais c'est évidemment plus grave avec des certificats à très courte durée de vie. Si on a des certificats Let's Encrypt classiques, qui durent trois mois et qu'on renouvelle une semaine avant leur expiration, même si l'horloge du client déconne de plusieurs jours, ça passera. En revanche, avec les certificats STAR, la désynchronisation des horloges aura des conséquences dans bien plus de cas.

La décision d'utiliser STAR ou pas, et le choix de la durée de vie des certificats, va dépendre de la population d'utilisateurs qu'on attend. Le RFC note que les problèmes d'horloge sont bien plus fréquents sur Windows que sur Android, par exemple.

Autre risque avec STAR, la charge supplémentaire pour les journaux Certificate Transparency (RFC 6962). Si STAR devenait le principal mode d'émission de certificats (c'est peu probable), leur trafic serait multiplié par cent. Avant la publication de ce RFC, de nombreuses discussions avec le groupe de travail IETF trans et avec les opérateurs des principaux journaux ont montré qu'il n'y avait a priori pas de risque, ces journaux peuvent encaisser la charge supplémentaire.

Questions mises en œuvre de STAR, il y a eu une scission (non publique ?) de Boulder, le serveur de Let's Encrypt et du client certbot pour y ajouter STAR. Il y a également un client et serveur avec STAR dans Lurk.

La section 6 de notre RFC revient sur les questions de sécurité liées à STAR. Ainsi, comme l'expiration remplace la révocation, on ne peut plus exiger la suppression immédiate d'un certificat. (Mais, on l'a dit, la révocation marche tellement mal en pratique que ce n'est pas une grande perte.) En cas de compromission de la clé privée, on peut demander l'arrêt de l'émission des certificats mais (et cela ne semble pas mentionné par le RFC), si on perd son compte ACME, ou simplement le numnique ACME, on ne peut plus annuler cette émission, et on doit attendre l'expiration de la séquence (indiquée par end-date.)


Téléchargez le RFC 8739


L'article seul

Version 13 d'Unicode

Première rédaction de cet article le 11 mars 2020


Ce mercredi 11 mars est sortie la version 13 d'Unicode. Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 143924

Combien de caractères sont arrivés avec la version 13 ?

ucd=>
 10.0    |  8518
 11.0    |   684
 12.0    |   554
 12.1    |     1
 13.0    |  5930

5930 nouveaux, le rythme de création repart, après une version 12 qui était très modérée. Quels sont ces nouveaux caractères ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='13.0';
 codepoint |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+1FAD5   | FONDUE
 ...
 U+10E80   | YEZIDI LETTER ELIF
 U+10E81   | YEZIDI LETTER BE
 U+10E82   | YEZIDI LETTER PE
 ...
 U+1F9A3   | MAMMOTH
 U+1F9A4   | DODO
 U+1F9AB   | BEAVER
 ...
 U+1FBA0   | BOX DRAWINGS LIGHT DIAGONAL UPPER CENTRE TO MIDDLE LEFT
 U+1FBA1   | BOX DRAWINGS LIGHT DIAGONAL UPPER CENTRE TO MIDDLE RIGHT
 U+1FBA2   | BOX DRAWINGS LIGHT DIAGONAL MIDDLE LEFT TO LOWER CENTRE

On trouve donc le lot habituel de nouveaux émojis, comme la fondue ou le mammouth. Parmi ces nouveaux émojis, notons le drapeau trans. Comme souvent dans Unicode, pour limiter l'explosion du nombre d'émojis, le drapeau trans n'est pas en un seul caractère mais s'obtient par une combinaison, U+1F3F3 U+FE0F U+200D U+26A7 U+FE0F, où U+1F3F3 est le drapeau blanc et U+26A7 le signe transgenre. Toujours dans les émojis, on notera l'arrivée des symboles liés aux communs comme U+1F16D, le symbole des Creative Commons. Il avait été refusé pendant longtemps comme symbole politique, alors que le copyright a son U+A9 depuis la version 1 d'Unicode…

Tiens, d'ailleurs, combien de caractères Unicode sont des symboles (il n'y a pas que les emojis parmi eux, mais Unicode n'a pas de catégorie « emoji ») :

 ucd=> SELECT count(*) FROM Characters  WHERE category IN ('Sm', 'Sc', 'Sk', 'So');
 count 
-------
  7564

Ou, en plus détaillé, et avec les noms longs des catégories :

ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description;
   description   | count 
-----------------+-------
 Modifier_Symbol |   123
 Other_Symbol    |  6431
 Math_Symbol     |   948
 Currency_Symbol |    62

Pour conclure sur les émojis, je vais citer Benjamin Bayart : « Alors, sans vouloir manquer de respects aux amateurices d'émojis, franchement, savoir si avec une série de caractères combinants on peut représenter une émoji "Courgette au curry qui fait du tambour avec un poireau bleu et un chapeau pointu", j'en comprend le côté amusant, mais c'est pas ça, le sens d'Unicode. Et ça m'exaspère qu'on laisse toujours le côté fantastique de cet outil [Unicode] dans l'ombre, pour montrer son côté le plus complètement inutile. »

Il y a surtout dans cette version 13 des nouvelles écritures comme le yezidi (qui renait, peut-être à cause de l'intérêt porté à leur lutte contre Daech), et plein de caractères pour faire de l'« art Unicode » en dessinant avec des caractères. Par contre, l'écriture maya n'est pas encore intégrée.

Si vous avez les bonnes polices de caractères, voici les caractères pris en exemple plus haut : 🫕, 𐺀, 𐺁, 𐺂, 🦣, 🦤, 🦫, 🮠, 🮡, 🮢, (ce dernier étant dans Unicode depuis la version 4), 🅭… (Si vous n'avez pas les bonnes polices, chaque lettre est un lien vers Uniview.) Pour le drapeau trans, voici la combinaison qui est censée l'afficher, si vous avez logiciel et police récents : 🏳️‍⚧️.


L'article seul

Fiche de lecture : Déclic

Auteur(s) du livre : Maxime Guedj, Anne-Sophie Jacques
Éditeur : Les Arènes
978-2-7112-0197-6
Publié en 2020
Première rédaction de cet article le 10 mars 2020


Encore un livre pour parler du pouvoir excessif des GAFA et du capitalisme de surveillance ? Oui mais le sujet n'est pas encore épuisé et chaque livre a un angle différent. Celui-ci est clairement destiné aux utilisateurs et utilisatrices, pas informaticiens et pas biberonnés aux communiqués de la Quadrature du Net depuis des années. Comme je suppose que la plupart des lecteurs et lectrices de mon blog sont plutôt informés sur la surveillance de masse, je leur dis : faites circuler ce livre pour les personnes de votre entourage qui sont à la merci des GAFA.

Le livre est court, pour ne pas épuiser le lecteur, et comprend trois parties. 1) Expliquer le fonctionnement des GAFA et comment, loin d'être bienveillants, ils nous exploitent et nous fichent. (Si vous lisez ce blog, vous savez probablement tout ça. Mais pensez aux autres.) 2) Montrer qu'il y a des alternatives, que la situation est certes grave, mais que l'avenir dépend de nous, on peut le changer. 3) Donner une liste de ressources (documents, logiciels, services) pour « changer le monde, un octet à la fois » (slogan de Framasoft.)

La première partie s'attaque à une tâche difficile : expliquer à des non-informaticiens tout ce qui se passe derrière l'écran et qui abuse des données personnelles confiées. Si tout professionnel sait bien que la nature du numérique fait que collecter, traiter et analyser des données est facile et bon marché (après tout, l'informatique a justement été inventée pour cela), les utilisateurs ne sont pas forcément au courant et peuvent croire des discours du genre « ne vous inquiétez pas, tout est anonymisé, il n'y a aucun risque ». D'autant plus qu'avec le numérique, le pistage peut être discret. Sans Exodus Privacy, serait-on bien conscient de l'abondance de pisteurs dans les applications de notre ordiphone, y compris chez les services publics, et chez les médias qui critiquent vertueusement les GAFA ? Je trouve que ce livre se tire bien de cette tâche pédagogique. (Mais vous pouvez aussi lire l'excellent livre de Snowden, très pédagogique.)

La deuxième partie est tout aussi cruciale ; informer les utilisatrices et les utilisateurs des risques est bien sûr un pré-requis à toute action. Mais s'arrêter là serait dangereux : pour le cerveau humain, quand il n'y a pas de solution, il n'y a pas de problème. Si on se contente de dénoncer le danger, on risque davantage de générer de la résignation que de l'action. Il faut donc aussi, contrairement aux très nombreux livres qui encombrent les librairies avec des discours anxiogènes sur les vilains écrans et les méchants GAFA, proposer, sinon des solutions toutes faites, au moins des perspectives. C'est donc ici que les auteur·e·s exposent les CHATONS, le logiciel libre mais aussi des perspectives moins souvent présentées, comme les réseaux sociaux décentralisés. Là encore, ce livre est utile et bien fait.

Si plein de personnages connus sont félicités, à juste titre, dans ce livre (Aaron Swartz, Elinor Ostrom, Richard Stallman, Linus Torvalds…), une mention spéciale revient à Alexandra Elbakyan, la peu médiatique responsable de l'indispensable Sci-Hub. Au moment où l'épidémie de COVID-19 frappe la planète, c'est l'occasion de rappeler que la libre diffusion des articles scientifiques est un des enjeux essentiels d'aujourd'hui. Je me joins aux auteur·e·s du livre pour la congratuler chaudement.

[Et merci aussi à Hippase de Métaponte, qui, violant le ridicule secret imposé par Pythagore, avait décidé que les maths méritaient d'être connues de tous.]

La troisième partie était délicate, elle aussi. Il s'agit de présenter une liste de logiciels, de ressources et de services pour aider à la libération des utilisatrices et utilisateurs. De telles listes ne sont pas faciles à faire : il n'est pas toujours possibles de tout tester en détail, et ces listes se périment vite (même quand elles sont en ligne : l'Internet rend la distribution des mises à jour plus facile, mais il ne change rien au problème de maintenance d'une liste.) Personnellement, je ne vois pas de solution à ce problème : la liste du livre ne plaira probablement à personne à 100 %. Le débat lors du lancement du livre le 26 février 2020 avait montré que les solutions alternatives ne sont pas toujours équivalentes à celles des GAFA (« lorsque je veux planter un arbre, je vais sur Ecosia, lorsque je veux un résultat, je vais sur Google », avait dit un participant), et qu'il faudrait prévenir les utilisateurices qu'ielles auront parfois à faire des efforts.

En résumé, c'est un livre à lire si vous vous posez des questions sur le numérique et que vous voulez aller au-delà du « Facebook, c'est des fake news, faut réguler », ou bien si vous connaissez déjà tout cela mais que vous voulez aider les gens de votre entourage à « échapper au piège des géants du Web ».

Sinon, vous pouvez aussi écouter un podcast des auteur·e·s.


L'article seul

Se cacher de qui ? Chiffrement, sécurité informatique et modèle de menace

Première rédaction de cet article le 9 mars 2020


Depuis les révélations d'Edward Snowden, il est difficile d'ignorer le fait que des méchants nous espionnent via les outils numériques. Les solutions proposées se limitent fréquemment à la technique : chiffrement de bout en bout et vous êtes en sécurité. Mais c'est évidemment plus compliqué que cela, comme l'analysent bien Ksenia Ermoshina et Francesca Musiani dans leur article « Hiding from Whom? Threat-models and in-the-making encryption technologies ».

L'article repose sur beaucoup de travail de terrain, auprès de dissidents, lanceurs d'alerte et défenseurs des droits humains un peu partout dans le monde. Ils et elles ne sont pas en général informaticiens et ne maitrisent pas tous les détails techniques. Mais elles ou ils comprennent souvent le modèle de menace : on veut se protéger contre qui ? Ce n'est pas la même chose d'être un employé qui ne veut pas être surveillé par son patron, et d'être un agent secret infiltré dans un pays ennemi disposant de puissants moyens de surveillance. C'est en effet le point crucial souvent oublié des discours sur la sécurité informatique : qui est l'ennemi ?

Évidemment, s'il existait un outil de communication idéal, simple à utiliser, parfaitement sécurisé, ne nécessitant pas de faire confiance à tel ou tel acteur, et largement déployé, le problème serait simple. Il suffirait de dire « utilisez cet outil ». Mais comme il n'existe pas, il faut s'adapter. Et cela nécessite de bien comprendre les menaces. Par exemple, les interviews par les auteures de femmes au Moyen-Orient montrent une claire prise de conscience du fait que le risque, pour la femme, est à la maison (ce qui n'est évidemment pas limité au monde musulman.)

Comprendre les menaces est évidemment plus facile à dire qu'à faire. Les auteures dégagent deux axes de classification des utilisateurs, l'axe du risque (haut risque vs. faible risque) et l'axe compétences techniques (connaissances étendues vs. faibles connaissances.) Il y a des gens à faible risque et compétences élevées (l'informaticien spécialiste des questions de sécurité et vivant dans un pays calme et démocratique) et, malheureusement pour eux, des gens à risque élevé et compétences limitées (la militante écologiste dans un pays autoritaire.) Et il faut aussi compter avec le graphe social : dans beaucoup de circonstances, si on est à faible risque mais qu'on fréquente des gens à haut risque, on devient une cible.

Ah, et vous voulez encore compliquer les choses ? Notez alors que l'utilisation de l'application la plus efficace n'est pas forcément une bonne idée, si elle est peu répandue : l'ennemi peut considérer que la seule utilisation de cette application indique que vous êtes dangereux. Être trop différent peut être un délit et en rester à WhatsApp, malgré toutes ses faiblesses, peut être plus sûr…

Bref, la sécurité, c'est compliqué, vous vous en doutiez, il n'y a pas de solution magique. L'intérêt de cet article est d'élargir la perspective, surtout celle des informaticiens, et de comprendre la variété et la complexité des problèmes de sécurité.


L'article seul

Tests pour des programmes en ligne de commande

Première rédaction de cet article le 2 mars 2020


Tout développeur sait bien qu'il faut tester les programmes. Et il ou elle sait également qu'il doit s'agir de tests entièrement automatiques, pouvant être exécutés très souvent, idéalement à chaque changement du code ou de l'environnement. Il existe une quantité incroyable d'outils pour faciliter l'écriture de tels tests, pour tous les langages de programmation possibles. Souvent, ces outils sont même inclus dans la bibliothèque standard du langage, tellement les tests sont indispensables. Mais, lorsque j'ai eu besoin d'écrire un jeu de tests pour un programme en ligne de commande, je me suis aperçu qu'il n'existait pas beaucoup d'outils. Heureusement, Feth en a développé un, test_exe_matrix.

Les cadriciels existants pour écrire des tests sont typiquement spécifiques d'un langage de programmation donné. Le programme est structuré sous forme d'une ou plusieurs bibliothèques, dont les fonctions sont appelées par le programme de test, qui regarde si le résutat est celui attendu. Pour prendre un exemple simple, le langage Python a à la fois un cadriciel standard, unittest, et une alternative, que je trouve plus agréable, pytest. Pour illustrer, écrivons un test_add.py qui sera un jeu de tests de l'opération d'addition :

#!/usr/bin/env python3

import random

import pytest

@pytest.fixture(scope="module")
def generator():
    g = random.Random()
    yield g
    
def test_trivial():
    assert 2 + 2 == 4

def test_negative():
    assert 42 + (-42) == 0

def test_zero(generator):
    for i in range(0,10):
        x = generator.randint(0, 100)
        assert x + 0 == x
  

pytest va exécuter toutes les fonctions dont le nom commence par test_. Si l'assertion réussit, c'est bon, si elle échoue, pytest affiche le problème (en utilisant l'introspection, c'est un de ses avantages). Il suffit donc au développeur qui aurait modifié la mise en œuvre de l'opérateur + de lancer pytest et il verra bien si le code marche toujours ou pas. (Inutile de dire qu'un vrai jeu de test pour l'opérateur d'addition serait bien plus détaillé.)

Tout cela, c'est bien connu. Mais si je veux tester du code qui n'est pas une bibliothèque mais un exécutable en ligne de commande ? Il peut y avoir plusieurs raisons pour cela :

  • C'est un programme privateur dont je n'ai pas les sources,
  • Je veux tester l'analyse des arguments,
  • Le programme n'est pas structuré sous forme d'une bibliothèque, tout est dans l'exécutable.

Étant à la fois dans le deuxième et dans le troisième cas, j'ai cherché une solution pour le tester. Mon cahier des charges était :

  • Permettre de tester des programmes en ligne de commande Unix.
  • Il faut pouvoir spécifier les arguments et le code de retour attendu.
  • Il faut pouvoir spécifier des chaînes de caractères qui doivent être sur la sortie standard et l'erreur standard.

Comme indiqué plus haut, Feth Arezki a développé un outil qui correspond à ce cahier des charges, test_exe_matrix. Il est bâti au dessus de pytest (ce qui est raisonnable, cela évite de tout refaire de zéro). Le principe est le suivant : on écrit un fichier en YAML décrivant les commandes à lancer et les résultats attendus. Puis on lance test_exe_matrix, et il indique si tout s'est bien passé ou pas, et en cas de problèmes, quels tests ont échoué. Voici un exemple de fichier de configuration avec un seul test, un test de la commande echo :

---
tests:
  - exe: '/bin/echo'
    name: "test echo stdout substring"
    args:
      - '-n'
      - 'coincoin'
    retcode: 0
    partstdout: 'inco'
    stderr: ''
  

La commande testée sera /bin/echo -n coincoin. Le paramètre retcode indique que le code de retour attendu est 0 (un succès, dans le shell Unix) et le paramètre partstdout indique qu'on attend cette chaine de caractères inco sur la sortie standard. Si on avait utilisé stdout, test_exe_matrix aurait exigé que l'entièreté de la sortie standard soit égale à cette chaîne. Testons maintenant :

% test_exe_matrix tmp.yaml
========================================== test session starts ===========================================
platform linux -- Python 3.6.9, pytest-5.3.1, py-1.8.1, pluggy-0.13.1
Tests from /home/stephane/src/Tests/CLI/test_exe_matrix/tmp.yaml
rootdir: /home/stephane
collected 2 items                                                                                        

../../../../.local/lib/python3.6/site-packages/test_exe_matrix/test_the_matrix.py ..               [100%]

=========================================== 2 passed in 0.12s ============================================
  

C'est parfait, tous les tests passent.

Un peu plus compliqué, avec la commande curl :

---
tests:
  - exe: '/usr/bin/curl'
    args:
      - 'https://www.bortzmeyer.org/'
    retcode: 0
    partstdout: 'Blog Bortzmeyer'
    timeout: 3 # Depuis Starbucks, c'est long
  

On a ajouté le paramètre timeout qui met une limite au temps d'exécution. Comme précédement, test_exe_matrix tmp.yaml va exécuter les tests et montrer que tout va bien.

Comme tous les bons cadriciels de test, test_exe_matrix permet aussi de tester des choses qui sont censées échouer, ici avec un domaine qui n'existe pas :

---
tests:
    - exe: '/usr/bin/curl'
      args:
          - 'https://www.doesnotexist.example/'
      retcode: 6
  

On oublie souvent de tester que, non seulement le logiciel marche bien dans les cas normaux, mais aussi qu'il échoue à juste titre lorsque la situation l'exige. Ici, on vérifie que curl a bien renvoyé le code de retour 6 et non pas 0. D'ailleurs, c'est l'occasion de montrer ce que fait test_exe_matrix lorsqu'un test échoue. Si je mets retcode: 0 dans le fichier de configuration précédent :


% test_exe_matrix tmp.yaml
...
================================================ FAILURES ================================================
...
exetest = {'args': ['https://www.doesnotexist.example/'], 'exe': '/usr/bin/curl', 'retcode': 0, 'timeout': 1}
...
E           AssertionError: expected retcode is 0, but process ended withcode 6
E           assert 0 == 6
...
../../../../.local/lib/python3.6/site-packages/test_exe_matrix/test_the_matrix.py:127: AssertionError
====================================== 1 failed, 1 passed in 0.14s =======================================

  

En utilisant l'introspection, test_exe_matrix a pu montrer exactement quel test échouait.

À l'heure actuelle, test_exe_matrix est en plein développement, et l'installation est donc un peu rugueuse. Si vous n'avez pas déjà Poetry, il faut l'installer, par exemple avec (oui, c'est dangereux, je sais) :

% curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3
  

Une fois que vous avez Poetry, vous pouvez installer test_exe_matrix, par exemple avec :

% poetry build
% pip3 install dist/test_exe_matrix-0.0.18-py3-none-any.whl  
  

Bien sûr, avant de suggérer le développement d'un nouveau logiciel, j'ai regardé ce qui existait, et ait été très surpris de ne rien trouver qui corresponde à mon cahier des charges, qui semblait pourtant modeste :

  • Bats : il faut faire pas mal de shell bash pour l'utiliser.
  • Btest est proche de ce que je cherche mais le test du code de retour n'est que binaire (0 ou pas 0), et on ne peut pas indiquer une chaîne qui doit être présente dans la sortie. Mettre un | grep <chaine> à la fin de la commande, ferait perdre le code de retour de la commande principale. (Dam_ned note qu'on peut peut-être s'en tirer avec set -o pipefail ou utiliser le tableau $PIPESTATUS.)
  • Avec Lift, je ne vois pas comment indiquer des chaînes de carcatères à tester dans la sortie standard.
  • Roundup : lui aussi semble exiger d'écrire pas mal de code shell.
  • Quant à Aruba, je n'ai tout simplement pas compris comment ça marchait.
  • Testing-suite : très simple mais ne semble pas permettre de tester le code de retour.

L'article seul

RFC 8738: Automated Certificate Management Environment (ACME) IP Identifier Validation Extension

Date de publication du RFC : Février 2020
Auteur(s) du RFC : R. Shoemaker (ISRG)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 1 mars 2020


Le protocole ACME, surtout connu via son utilisation par l'AC Let's Encrypt, permet de prouver la « possession » d'un nom de domaine, pour avoir un certificat comprenant ce nom. Ce court RFC spécifie une extension à ACME qui permet de prouver la « possession » d'une adresse IP, ce qui permettra d'obtenir via ACME des certificats utilisant une adresse.

Le protocole ACME est normalisé dans le RFC 8555. Son principe est qu'on demande un certificat pour un identificateur (à l'heure actuelle, forcément un nom de domaine) et que le serveur ACME va alors vous défier de prouver que vous contrôlez bien ce nom, par exemple en publiant une chaîne de caractères choisie par le serveur dans un serveur HTTP accessible via ce nom de domaine. Or, les identificateurs dans les certificats PKIX ne sont pas forcément des noms de domaine. Les adresses IP, par exemple, sont prévues. Examinons les certificats du résolveur DNS public Quad9 :

% openssl s_client -connect 9.9.9.9:853 -showcerts | openssl x509 -text 
...
X509v3 Subject Alternative Name: 
    DNS:*.quad9.net, DNS:quad9.net, IP Address:9.9.9.9, IP Address:9.9.9.10, IP Address:9.9.9.11, IP Address:9.9.9.12, IP Address:9.9.9.13, IP Address:9.9.9.14, IP Address:9.9.9.15, IP Address:149.112.112.9, IP Address:149.112.112.10, IP Address:149.112.112.11, IP Address:149.112.112.12, IP Address:149.112.112.13, IP Address:149.112.112.14, IP Address:149.112.112.15, IP Address:149.112.112.112, IP Address:2620:FE:0:0:0:0:0:9, IP Address:2620:FE:0:0:0:0:0:10, IP Address:2620:FE:0:0:0:0:0:11, IP Address:2620:FE:0:0:0:0:0:12, IP Address:2620:FE:0:0:0:0:0:13, IP Address:2620:FE:0:0:0:0:0:14, IP Address:2620:FE:0:0:0:0:0:15, IP Address:2620:FE:0:0:0:0:0:FE, IP Address:2620:FE:0:0:0:0:FE:9, IP Address:2620:FE:0:0:0:0:FE:10, IP Address:2620:FE:0:0:0:0:FE:11, IP Address:2620:FE:0:0:0:0:FE:12, IP Address:2620:FE:0:0:0:0:FE:13, IP Address:2620:FE:0:0:0:0:FE:14, IP Address:2620:FE:0:0:0:0:FE:15
...
  

On voit qu'outre des noms comme quad9.net, ce certificat inclut aussi des adresses IP comme 9.9.9.9 et 2620:fe::9. Mais un tel certificat ne pouvait pas s'obtenir automatiquement via ACME.

Notre RFC résout ce problème en ajoutant un nouveau type d'identificateur ACME, ip (section 3 du RFC). Les types d'identificateurs ACME sont décrits dans la section 9.7.7 du RFC 8555. Le nouveau type ip a été placé dans le registre IANA des types d'identificateur. La valeur doit être une adresse IP sous forme texte (normalisée très sommairement dans la section 2.1 du RFC 1123 pour IPv4, et dans la section 4 du RFC 5952 pour IPv6.)

Comme il s'agit d'authentifier des adresses IP, le défi ACME de type dns-01 n'est pas pertinent et ne doit pas être utilisé (section 7). Par contre, on peut (section 4 du RFC) utiliser les défis http-01 (RFC 8555, section 8.3) et le récent tls-alpn-01 (RFC 8737.)

Pour le défi HTTP, le serveur ACME va se connecter en HTTP à l'adresse IP indiquée, en mettant cette adresse dans le champ Host:. Pour le défi TLS avec ALPN, le certificat doit contenir un subjectAltName de type iPAddress. Un piège : contrairement au champ Host: de HTTP, l'adresse IP nue ne peut pas être utilisée dans le SNI (RFC 6066, « Currently, the only server names supported are DNS hostnames »). Il faut donc utiliser un nom dérivé de l'adresse, en in-addr.arpa ou ip6.arpa. Par exemple, si on veut un certificat pour 2001:db8::1, il faudra mettre 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa dans le SNI.

Un défi utilisant la « résolution inverse » (via une requête DNS dans in-addr.arpa ou ip6.arpa) avait été envisagé mais n'a pas été retenu (les domaines de la « résolution inverse » sont en général mal maintenus et il est difficile d'obtenir des entrées dans ces domaines.)

La section 9 de notre RFC étudie les conséquences de cette extension pour la sécurité. Le principal point à noter est que ce RFC ne spécifie qu'un mécanisme. L'AC a toute liberté pour définir une politique, elle peut par exemple refuser par principe les adresses IP dans les certificats, comme elle peut les accepter avec des restrictions ou des contrôles supplémentaires. Par exemple, il ne serait pas raisonnable d'allouer de tels certificats pour des adresses IP appartenant à des plages très dynamiques, pouvant changer d'utilisateur très souvent.

Côté mise en œuvre, pour le serveur Boulder (celui utilisé par Let's Encrypt), la discussion est ici.


Téléchargez le RFC 8738


L'article seul

RFC 8737: Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension

Date de publication du RFC : Février 2020
Auteur(s) du RFC : R. Shoemaker (ISRG)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 1 mars 2020


Ce court RFC normalise un mécanisme d'authentification lors d'une session ACME, permettant de prouver, via TLS et ALPN, qu'on contrôle effectivement le domaine pour lequel on demande un certificat.

Le protocole ACME (RFC 8555) laisse le choix entre plusieurs mécanismes d'authentification pour répondre aux défis du serveur ACME « prouvez-moi que vous contrôlez réellement le domaine pour lequel vous me demandez un certificat ! ». Le RFC 8555 propose un défi fondé sur HTTP (http-01), dans sa section 8.3, et un défi utilisant le DNS (dns-01), dans sa section 8.4. Notez que le défi HTTP est fait en clair, sans HTTPS. Or, outre la sécurité de TLS, certains utilisateurs d'ACME auraient bien voulu une solution purement TLS, notamment pour les cas où la terminaison de TLS et celle de HTTP sont faites par deux machines différentes (CDN, répartiteurs de charge TLS, etc.)

D'où le nouveau défi normalisé par ce RFC, tls-alpn-01. Il repose sur le mécanisme ALPN, qui avait été normalisé dans le RFC 7301. Déjà mis en œuvre dans des AC comme Let's Encrypt, il permet une vérification plus solide. Ce type de défi figure maintenant dans le registre des types de défis ACME. Notez qu'il existait déjà un type utilisant TLS, tls-sni-01 / tls-sni-02, mais qui avait des failles, autorisant un utilisateur d'un serveur TLS à obtenir des certificats pour d'autres domaines du même serveur. tls-sni est aujourd'hui abandonné.

Les détails du mécanisme figurent dans la section 3 de notre RFC. Le principe est que le serveur ACME se connectera en TLS au nom de domaine indiqué en envoyant l'extension ALPN avec le nom d'application acme-tls/1 et vérifiera dans le certificat la présence d'un token, choisi aléatoirement par le serveur ACME, token que le client ACME avait reçu sur le canal ACME. (Ce nom d'application, acme-tls/1 est désormais dans le registre des applications ALPN.)

Bien sûr, c'est un peu plus compliqué que cela. Par exemple, comme le client ACME va devenir le serveur TLS lors du défi, il lui faut un certificat. La section 3 du RFC explique les règles auxquelles doit obéir ce certificat :

  • Auto-signé, puisqu'on n'est pas encore authentifié auprès de l'AC,
  • Un subjectAlternativeName (RFC 5280) qui a comme valeur le nom de domaine à valider,
  • Une extension acmeIdentifier (mise dans le registre des extensions aux certificats PKIX), qui doit être marquée comme critique, pour éviter que des clients TLS passant par là et n'ayant rien à voir avec ACME s'en servent, et dont la valeur est l'autorisation ACME (RFC 8555, section 8.1).

Le client ACME doit ensuite configurer ce qu'il faut sur son serveur TLS pour que ce soit ce certificat qui soit retourné lors d'une connexion TLS où le SNI vaut le domaine à valider et où ALPN vaut acme-tls/1. Il annonce alors au serveur ACME qu'il est prêt à répondre au défi. Le serveur ACME se connecte au serveur TLS (créé par le client ACME) et fait les vérifications nécessaires (nom de domaine dans le certificat, nom qui doit être un A-label, donc en Punycode, et extension du certificat acmeIdentifier contenant la valeur indiquée par le serveur ACME lors du défi).

Une fois la vérification faite, le serveur ACME raccroche : ces certificats ne sont pas conçus pour échanger de vraies données sur la session TLS créée. D'ailleurs, les certificats auto-signés créés pour le type de défi tls-alpn-01 ne permettent pas d'authentification au sens du RFC 5280. Pour la même raison, le client TLS (créé par le serveur ACME) n'est pas obligé d'aller jusqu'au bout de l'établissement de la session TLS.

La section 5 de notre RFC fait le point sur quelques suppositions faites au sujet de la mise en œuvre de TLS, suppositions importantes pour ACME. D'abord, si plusieurs organisations ou personnes partagent la même adresse IP, ce qui est courant en cas d'hébergement plus ou moins mutualisé, ACME compte bien que leurs configurations TLS soient séparées, pour éviter qu'une de ces entités puisse obtenir un certificat pour une autre, hébergée au même endroit (cf. annexe A du RFC, qui décrit le comportement surprenant de certains hébergeurs.) ACME espère également que les serveurs TLS vont respecter le RFC 7301 en rejetant l'application acme-tls/1 s'ils ne la connaissent pas. (Certains programmeurs paresseux ont peut-être fait en sorte que le serveur TLS accepte n'importe quelle application signalée en ALPN.)

L'AC Let's Encrypt accepte déjà ce type de défi depuis juillet 2018. (Le RFC est en retard par rapport au déploiement effectif.) Le client ACME dehydrated permet d'utiliser le nouveau type de défi. Cet article utilise nginx côté serveur, avec son module SSL PreRead, qui permet d'aiguiller une requête en fonction de l'ALPN, mais, personnellement, je n'ai pas réussi (ça peut être un problème avec la gestion des modules dans le paquetage Debian de nginx, gestion quasiment pas documentée.)

Côté serveur, on a aussi ce qu'il faut dans Apache, avec le module mod_md (cf. plus précisement ce point de la documentation.)

Côté client ACME, d'autres clients gèrent ce type de défi, mais pas encore certbot (cf. le ticket #6724 .)


Téléchargez le RFC 8737


L'article seul

RFC 8731: Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448

Date de publication du RFC : Février 2020
Auteur(s) du RFC : A. Adamantiadis (libssh), S. Josefsson (SJD AB), M. Baushke (Juniper Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF curdle
Première rédaction de cet article le 29 février 2020


Cela fait déjà pas mal de temps que des mises en œuvre du protocole SSH intègrent les courbes elliptiques « Bernstein », comme Curve25519. Ce RFC est donc juste une formalité, la normalisation officielle de cette utilisation.

SSH est normalisé dans le RFC 4251. C'est peut-être le protocole cryptographique de sécurisation d'un canal Internet le deuxième plus répandu, loin derrière TLS. Il permet de se connecter de manière sécurisée à une machine distante. En application du principe d'agilité cryptographique (RFC 7696), SSH n'est pas lié à un algorithme cryptographique particulier. Le protocole d'échange des clés, normalisé dans le RFC 4253, permet d'utiliser plusieurs algorithmes. Le RFC 5656 a étendu ces algorithmes aux courbes elliptiques.

Les courbes Curve25519 et Curve448, créées par Daniel Bernstein, sont décrites dans le RFC 7748. Depuis des années, elles s'imposent un peu partout, à la place des courbes NIST comme P-256. La libssh a ces courbes depuis des années, sous l'ancien nom de curve25519-sha256@libssh.org. Notre RFC ne fait qu'officialiser ces algorithmes, sous les nouveaux noms de curve25519-sha256 et curve448-sha512.

La section 3 du RFC décrit les détails de l'utilisation de ces algorithmes pour l'échange de clé. La méthode est proche de l'ECDH de la section 4 du RFC 5656.

Voici un exemple de session utilisant cet algorithme, avec OpenSSH 7.6 :

% ssh -v ...
...	
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
      

Téléchargez le RFC 8731


L'article seul

RFC 8746: Concise Binary Object Representation (CBOR) Tags for Typed Arrays

Date de publication du RFC : Février 2020
Auteur(s) du RFC : C. Bormann (Universitaet Bremen TZI)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF cbor
Première rédaction de cet article le 29 février 2020


Ce nouveau RFC étend le format de fichiers CBOR (normalisé dans le RFC 7049) pour représenter des tableaux de données numériques, et des tableaux multidimensionnels.

Le format CBOR est en effet extensible par des étiquettes (tags) numériques qui indiquent le type de la donnée qui suit. Aux étiquettes définies dans la norme originale, le RFC 7049, ce nouveau RFC ajoute donc des étiquettes pour des types de tableaux plus avancés, en plus du type tableau de base de CBOR (qui a le type majeur 4, cf. RFC 7049, et dont les données ne sont pas forcément toutes de même type).

Le type de données « tableau de données numériques » est utile pour les calculs sur de grandes quantités de données numériques, et bénéficie de mises en œuvres adaptées puisque, opérant sur des données de même type, contrairement aux tableaux CBOR classiques, on peut optimiser la lecture des données. Pour comprendre l'utilité de ce type, on peut lire « TypedArray Objects » (la spécification de ces tableaux dans la norme ECMA de JavaScript, langage dont CBOR reprend le modèle de données) et « JavaScript typed arrays » (la mise en œuvre dans Firefox).

La section 2 spécifie ce type de tableaux dans CBOR. Un tableau typé (typed array) est composé de données numériques de même type. La représentation des nombres (par exemple entiers ou flottants) est indiquée par l'étiquette. En effet, il n'y a pas de représentation canonique des nombres dans un tableau typé (contrairement aux types numériques de CBOR, types majeurs 0, 1 et 7) puisque le but de ces tableaux est de permettre la lecture et l'écriture rapides de grandes quantités de données. En stockant les données sous diverses formes, on permet de se passer d'opérations de conversion.

Il n'y a pas moins de 24 étiquettes (désormais enregistrées dans le registre IANA des étiquettes CBOR) pour représenter toutes les possibilités. (Ce nombre important, les étiquettes étant codées en général sur un seul octet, a suscité des discussions dans le groupe de travail, mais se justifie par le caractère très courant de ces tableaux numériques. Voir la section 4 du RFC.) Par exemple, l'étiquette 64 désigne un tableau typé d'octets (uint8), l'étiquette 70 un tableau typé d'entiers de 32 bits non signés et petit-boutiens (uint32), l'étiquette 82 un tableau typé de flottants IEEE 754 de 64 bits gros-boutiens, etc. (CBOR est normalement gros-boutien, comme tous les protocoles et formats Internet, cf. section 4 du RFC.) Les étiquettes ne sont pas attribuées arbitrairement, chaque nombre utilisé comme étiquette encode les différents choix possibles dans les bits qui le composent. Par exemple, le quatrième bit de l'étiquette indique si les nombres sont des entiers ou bien des flottants (cf. section 2.1 du RFC pour les détails).

Le tableau typé est ensuite représenté par une simple chaîne d'octets CBOR (byte string, type majeur 2). Une mise en œuvre générique de CBOR peut ne pas connaitre ces nouvelles étiquettes, et considérera donc le tableau typé comme une bête suite d'octets.

La section 3 de notre RFC décrit ensuite les autres types de tableaux avancés. D'abord, les tableaux multidimensionnels (section 3.1). Ils sont représentés par un tableau qui contient deux tableaux unidimensionnels. Le premier indique les tailles des différentes dimensions du tableau multidimensionnel, le second contient les données. Deux étiquettes, 40 et 1040, sont réservées, pour différencier les tableaux en ligne d'abord ou en colonne d'abord. Par exemple, un tableau de deux lignes et trois colonnes, stocké en ligne d'abord, sera représenté par deux tableaux unidimensionnels, le premier comportant deux valeurs, 2 et 3, le second comportant les six valeurs, d'abord la première ligne, puis la seconde.

Les autres tableaux sont les tableaux homogènes (étiquette 41), en section 3.2. C'est le tableau unidimensionnel classique de CBOR, excepté que tous ses élements sont du même type, ce qui peut être pratique au décodage, pour les langages fortement typés. Mais attention : comme rappelé par la section 7 du RFC, consacrée à la sécurité, le décodeur doit être prudent avec des données inconnues, elles ont pu être produites par un programme malveillant ou bogué, et donc non conformes à la promesse d'homogénéité du tableau.

La section 5 de notre RFC donne les valeurs des nouvelles étiquettes dans le langage de schéma CDDL (RFC 8610).


Téléchargez le RFC 8746


L'article seul

RFC 8719: High-Level Guidance for the Meeting Policy of the IETF

Date de publication du RFC : Février 2020
Auteur(s) du RFC : S. Krishnan (Kaloom)
Réalisé dans le cadre du groupe de travail IETF mtgvenue
Première rédaction de cet article le 28 février 2020


Le groupe mtgvenue de l'IETF était chargé de définir une politique pour le choix des lieux pour les réunions physiques de l'IETF. Ce nouveau RFC pose le principe général d'une rotation entre divers continents. Le RFC 8718 décrit ensuite les détails.

L'IETF a trois réunions physiques par an. L'idée est d'avoir en moyenne (mais pas forcément pour chaque année) une réunion en Amérique du Nord, une en Europe et une en Asie (cf. cette présentation de la politique « 1-1-1 ».) Le but est de répartir les coûts et temps de voyage entre les différents participants. Cette politique était jusqu'à présent informelle, ce RFC la documente officiellement. Elle se base sur la répartition constatée des participants à l'IETF. Notez que les frontières exactes des continents sont volontairement laissées floues, pour ne pas se lier les mains dans certains cas (demandez-vous si le Mexique est en Amérique du Nord, ou si Chypre est en Europe ou en Asie…)

Certaines réunions, dites « exploratoires » peuvent se tenir dans d'autres continents. L'IETF a fait une fois une réunion à Buenos Aires, et une fois à Adelaide.

Sur la base de cette politique « 1-1-1 », les décisions effectives seront prises en suivant le RFC 8718. Et, bien sûr, la politique n'est pas 100 % rigide. L'Internet change, les participants à l'IETF également, et d'autres lieux deviendront envisageables.


Téléchargez le RFC 8719


L'article seul

RFC 8715: Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust

Date de publication du RFC : Février 2020
Auteur(s) du RFC : J. Arkko (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Le passage de la structure administrative de l'IETF vers « IASA 2.0 » (IASA = IETF Administrative Support Activity, cf. RFC 8711) a nécessité des changements dans la manière dont les membres de l'IETF Trust sont désignés. Ces changements sont décrits dans le RFC 8714, et expliqués brièvement dans ce court RFC.

Petit rappel : l'IETF Trust gère la propriété intellectuelle de l'IETF, comme la marque ou comme le nom de domaine ietf.org et, bien sûr, comme les RFC, dont la licence dépend formellement de cet IETF Trust. Cet IETF Trust est enregistré aux États-Unis. Au début, les membres de l'IAOC (IETF Administrative Oversight Committee) étaient également membres de l'IETF Trust. L'IAOC ayant été supprimé par le RFC 8711, il fallait donc changer les règles de désignation, ce qu'a fait le RFC 8714.

Lors des discussions sur la création de l'« IASA 2 » (IETF Administrative Support Activity, deuxième version), il avait été envisagé de fusionner l'IETF Trust avec la nouvelle structure, l'IETF LLC. Finalement, l'IETF Trust reste une organisation indépendante. Les raisons ? D'abord, une volonté de minimiser les changements liés au projet « IASA 2 », ensuite, l'observation du fait que le travail de l'IETF Trust est assez différent de celui de la IETF LLC (décrite dans le RFC 8711). L'IETF Trust a une activité calme, avec peu ou pas de problèmes urgents à résoudre, et les changements sont rares.

Mais comme il fallait bien tenir compte de la disparition de l'IAOC, le choix a été de réduire la taille de l'IETF Trust, plutôt que de créer un mécanisme alternatif à l'IAOC (puisque, comme indiqué plus haut, l'IETF Trust ne demande pas beaucoup de travail). Les cinq membres sont désignés par le comité de nomination de l'IETF (« NomCom »), par l'IESG et par l'ISOC. Pour ce dernier cas, le RFC note qu'on aurait pu utiliser l'IETF LLC et pas l'ISOC, mais que l'ISOC semblait plus adaptée, pour une tâche qui est assez politique (l'IETF LLC est normalement purement administrative).

Sinon, vous pouvez voir ici un appel à candidatures du NomCom pour l'IETF Trust.


Téléchargez le RFC 8715


L'article seul

RFC 8714: Update to the Process for Selection of Trustees for the IETF Trust

Date de publication du RFC : Février 2020
Auteur(s) du RFC : J. Arkko (Ericsson), T. Hardie
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Un RFC purement bureaucratique, faisant partie de la série des RFC sur la nouvelle structure administrative de l'IETF, décrite dans le RFC 8711. Celui-ci change légèrement la manière dont sont désignés les membres de l'IETF Trust, la structure qui gère la propriété intellectuelle de l'IETF.

Cet IETF Trust avait été créé pour s'occuper de toutes les questions liées aux marques, noms de domaine, droits sur les RFC, etc. C'était aussi la seule solution pour récupérer partiellement des droits qui avaient été détournés par CNRI. Il était spécifié dans le RFC 4371 que les membres de l'IAOC (IETF Administrative Oversight Committee) étaient automatiquemement membres de l'IETF trust.

La section 3 de notre RFC contient le changement important : comme la nouvelle structure administrative de l'IETF, décrite dans le RFC 8711 supprime l'ancienne IAOC, les membres de l'IETF trust ne seront plus issus de l'IAOC. Les cinq membres de l'IETF Trust sont désignés, pour trois d'entre eux par le comité de nomination de l'IETF (RFC 8713), pour l'un par l'IESG et pour le dernier par l'ISOC. Leur mandat est de trois ans mais le RFC prévoit des mandats plus courts pour certains, pour lisser la transition.

Un exemple du processus de sélection des trois membres « NomCom » (comité de nomination) se trouve en ligne. Regardez l'appel aux nominations (ou bien celui-ci). Comme vous le voyez avec le premier exemple, le processus de remplacement de l'ancien IETF trust a été fait bien avant la publication formelle de ce RFC.

Les raisons de ce changement sont décrites plus longuement dans le RFC 8715.


Téléchargez le RFC 8714


L'article seul

RFC 8718: IETF Plenary Meeting Venue Selection Process

Date de publication du RFC : Février 2020
Auteur(s) du RFC : E. Lear (Cisco Systems)
Réalisé dans le cadre du groupe de travail IETF mtgvenue
Première rédaction de cet article le 28 février 2020


La question de la sélection du lieu pour les réunions physiques de l'IETF a toujours suscité des discussions passionnées, d'autant plus que chaque participant, et son chat, a un avis. Il y a de nombreux critères (coût, distance, agréments du lieu, goûts personnels…) Ce nouveau RFC décrit le nouveau mécanisme par lequel est sélectionné un lieu, et les critères à respecter.

En théorie, venir aux réunions physiques n'est pas indispensable. L'IETF, organisme de normalisation technique de l'Internet, travaille, étudie les propositions, les amende, les approuve ou les rejette entièrement en ligne (avec l'aide de quelques outils comme le DataTracker). Ceci dit, en pratique, venir aux trois réunions physiques par an aide certainement à faire avancer son sujet favori. Ces réunions rassemblent des centaines de participants IETF pendant une semaine et sont l'occasion de nombreuses discussions. À noter que, pendant la réunion, une liste de discussion permet également des bavardages généralisés, où les conseils sur les bons bars et restaurants rencontrent les avis sur la meilleure route vers l'aéroport, et des récriminations sur les ascenseurs, l'air conditionné, le manque de cookies, etc. Ce RFC sort d'ailleurs au moment exact où l'IETF se déchire sur l'opportunité ou non de maintenir la réunion de Vancouver malgré l'épidémie.

La reponsabilité du choix d'un lieu pour les réunions incombe à l'IASA (IETF Administrative Support Activity, RFC 8711). Ce RFC ne lui supprime pas cette responsabilité mais lui fournit des éléments à prendre en compte. L'IETF a trois rencontres physiques par an, s'inscrivant dans le cadre de ses missions, qui sont décrits dans le RFC 3935. (Notez que certains participants contestent ces rencontres physiques, considérant qu'une organisation de normalisation des protocoles Internet pourrait se « réunir » en ligne.) La section 2 du RFC décrit les principes fondamentaux à prendre en compte pour le choix du lieu de la réunion :

  • Permettre la participation du plus grand nombre, quel que soit leur pays d'origine, ce qui implique que les pays ayant une politique de visa très restrictive, comme les États-Unis, sont déconseillés,
  • Et cela implique également que l'IETF préfère se tenir à l'écart des pays qui discriminent selon le genre, la couleur de peau, l'orientation sexuelle, etc ; c'est d'ailleurs un tel cas, soulevé par Ted Hardie, qui avait été à l'origine de la création du groupe mtgvenue, lorsque le choix de se réunir à Singapour avait été contesté en raison des lois homophobes de ce pays,
  • Un accès Internet de qualité est évidemment nécessaire, et non censuré ; cela avait donné lieu à de sévères discussions lors de la réunion (la seule jusqu'à ce jour) en Chine (le RFC note aussi, dans sa section 7, que la vie privée est importante et que les participants doivent être informés d'une éventuelle surveillance),
  • Le but est de travailler, et cela implique un environnement qui s'y prête bien, par exemple la possibilité de réunions informelles dans les environs, et dans de bonnes conditions (RFC 6771),
  • Le coût est un problème crucial, beaucoup de participants n'étant pas financés par une entreprise ou un gouvernement.

En revanche, la même section 2 cite des non-objectifs :

  • À part les cas de discrimination cités plus haut, qui concernent directement les participants à l'IETF, le choix du lieu de la réunion n'a pas pour objectif de valider ou de critiquer la politique du gouvernement local, ou les mœurs locales,
  • Avoir le maximum de participants n'est pas un but en soi, les réunions IETF n'ont pas un objectif commercial,
  • Et, évidemment, il n'y aura pas de critères touristiques (ah, les réunions à Minneapolis en hiver…)

Compte-tenu de ces objectifs de haut niveau, la section 3 du RFC liste les critères. D'abord, ceux qui sont impératifs :

  • L'endroit précis de la réunion (en général un grand hôtel, mais parfois un centre de conférences) doit fournir assez d'espace pour toutes les activités,
  • Il doit être accessible aux handicapés en fauteuil roulant (d'autres formes de handicap sont mentionnées plus loin, avec des critères moins stricts),
  • Il doit pouvoir être connecté à l'Internet dans de bonnes conditions (IPv4 et IPv6, pas de NAT, capacité suffisante, etc ; notez que, la plupart du temps, le lieu ne fournit pas cela par défaut et c'est à l'IETF de tout installer et configurer avant la réunion).

Il y a ensuite les critères importants. Évidemment, l'idéal serait de trouver un endroit qui satisfasse tous les critères mais, en général, ce n'est pas possible. Le choix sera toujours un compromis. Il faut donc déterminer quels critères on peut accepter de sacrifier, et c'est la raison pour laquelle il n'y a finalement que trois critères impératifs. Les critères importants mais non impératifs sont :

  • Le lieu doit être raisonnablement accessible d'un grand nombre d'endroits (la réunion de Buenos Aires, la seule qui se soit tenue en Amérique latine, avait été très critiquée de ce point de vue, le coût total et le temps total de voyage avaient été très importants, par rapport à, disons, New York ou Singapour),
  • Il doit être possible de trouver une organisation locale qui participe à l'organisation, et des sponsors qui acceptent de financer (les frais d'inscription, pourtant très élevés, ne couvrent pas tout le budget),
  • Les barrières à l'entrée (typiquement les visas) doivent être le plus basses possibles (là encore, cela dépend du participant : pour aller en France, la barrière pour un Slovène est basse, la Slovénie étant dans Schengen, celle pour un Malien est bien plus haute ; c'est donc le « coût » total qu'il faut considérer),
  • Le lieu doit offrir des conditions de sécurité acceptables (critère parfois subjectif, les États-uniens, par exemple, voient souvent le reste du monde comme une jungle, et des habitants de Chicago ou Los Angeles s'inquiètent parfois à l'idée d'aller à Yokohama…),
  • Par ailleurs, il faut suivre les principes (assez généraux) du RFC 8719.

  Il faut se rappeler que l'IETF est internationale, et que la notion de « lieu éloigné » dépend donc du participant, c'est le coût total de voyage qui compte, pas celui de telle ou telle personne, d'où la politique « 1-1-1 », une réunion en Amérique du Nord, puis une en Europe, puis une en Asie, politique qui vise à répartir les coûts sur les divers participants

Pour l'endroit exact de la réunion (en général un grand hôtel), il y a des critères supplémentaires :

  • De la place pour les réunions informelles (couloirs, annexes, bars et cafétérias, etc) et des endroits où se rencontrer dans les environs, puisque, comme souvent dans les réunions formelles, le travail le plus important se fait en dehors des salles de réunion (on voit souvent des petits groupes écrire des Internet-Drafts assis dans les couloirs),
  • Prix « conformes aux tarifs d'affaire habituels » (ce qui est déjà très cher, si on prend en compte les habitudes étatsuniennes).

Dans le cas typique, l'IETF se tient dans un grand hôtel pour hommes d'affaires riches. (La dernière (au moment de l'écriture de cet article) réunion, à Montréal, était au Fairmont.) Et les participants au budget voyage le plus important logent sur place. Il existe aussi des overflow hotels où logent les moins riches. Dans l'hôtel principal et, parfois, dans les overflow hotels, on dispose du réseau IETF même dans sa chambre. Ce réseau est installé par une équipe de volontaires de l'IETF avant la réunion (les réseaux des hôtels sont en général catastrophiques, pas d'IPv6, pas de DNSSEC, des ports filtrés, etc, une réunion à Paris avait battu les records). Beaucoup de participants vont chez Airbnb ou carrément en auberge de jeunesse et doivent alors se débrouiller pour le réseau.

Les ingénieurs et ingénieures sont des êtres humains et doivent donc manger. D'où des critères concernant nourriture et boisson :

  • Disponibilité de ressources alimentaires proches, pour tous les goûts, toutes les bourses, tous les critères, par exemple de santé ; j'ai déjà vu des conférences dans des resorts isolés, où on était obligés de se contenter de l'offre locale, souvent très chère,
  • Ces ressources doivent être disponibles sous forme de restaurants mais aussi de magasins pour ceux qui préfèrent ensuite aller manger dehors (il n'y a pas de repas servi, aux réunions IETF).

Enfin, il y a des critères sur des points variés :

  • Il est préférable que tout soit au même endroit, pour éviter les déplacements,
  • Il est préférable qu'on puisse revenir, et qu'il y ait des contrats pour plusieurs évenements, avec prix réduits.

Même si tous ces critères ne sont pas impératifs, mis ensemble, ils sont très exigeants. Des gens demandent parfois pourquoi, par exemple, il n'y a jamais eu de réunion de l'IETF en Inde, pays certainement important pour l'Internet. C'est entre autres en raison de spécificités locales, par exemple la difficulté d'obtention des visas. (Cf. cette discussion.)

On notera que les critères sont finalement peu nombreux. De très nombreuses autres propositions avaient été faites, qui risquaient de mener à un catalogue de critères, très épais et, de toute façon, impossibles à satisfaire simultanément. Le rapport « droits humains » notait que certains critères pouvaient être incompatibles entre eux (une personne aveugle voudrait pouvoir être accompagnée de son chien guide, et une autre personne est allergique aux chiens, voire en a une phobie.)

C'est ainsi que des critères comme la disponibilité d'une crèche ont été retirés (notez que le RIPE le fait et que l'IETF va tenter le coup), de même que la demande de toilettes non genrées, qui était dans certaines versions du projet de RFC.

Comme vous vous en doutez, la discussion à l'IETF sur ce RFC n'a pas été évidente. De toute façon, la décision sur le choix d'un lieu reviendra à l'IASA, sauf pour les critères impératifs, qui nécessiteront une discussion générale.


Téléchargez le RFC 8718


L'article seul

RFC 8721: Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents

Date de publication du RFC : Février 2020
Auteur(s) du RFC : J. Halpern (Ericsson)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Une fois les droits de publication, et de modification, offerts par le(s) auteur(s) d'un RFC à l'IETF trust, quels droits ce dernier va-t-il transmettre aux lecteurs et lectrices d'un RFC ? Le RFC 5378 spécifie les droits « entrants » à l'IETF trust, et notre RFC 8721 spécifie les droits sortants : que puis-je faire avec un RFC ? Ai-je le droit de le lire ? De le redistribuer ? De le traduire ? Ce RFC est une légère modification du RFC 5377, qu'il remplace. Le but de cette modification était de s'adapter à la nouvelle structure administrative de l'IETF, décrite dans le RFC 8711. Notamment, l'ancien IAOC (RFC 4071) disparait.

La section 1 du RFC rappelle un point important : c'est l'IETF trust qui décide. Le RFC 8721, publié par l'IETF, n'est qu'indicatif et ne fixe que des grands principes. Le texte exact de la licence des RFC est écrit par l'IETF trust (http://trustee.ietf.org/license-info/ et il existe aussi une FAQ sur ces textes.) La section 2 revient d'ailleurs sur les raisons de ce choix (pouvoir s'adapter aux changements légaux aux ÉUA, pays de l'IETF trust et de l'ISOC).

On pourra trouver ce texte standard, ce boilerplate, sur le site du Trust dans la Trust Legal Provisions.

La section 2 du RFC décrit les buts que suit l'IETF en publiant des RFC (cf. RFC 3935). Clairement, l'élaboration d'une licence doit se faire en gardant ces buts à l'esprit : faire fonctionner l'Internet le mieux possible, notamment en assurant l'interopérabilité des mises en œuvres des protocoles TCP/IP.

La section 3 explique l'articulation de ce RFC avec le RFC 5378 : les droits sortants (ceux que l'IETF trust accorde aux utilisateurs) doivent être inférieurs ou égaux aux droits entrants (ceux que l'auteur a accordé à l'IETF trust). Autrement dit, l'IETF ne peut pas donner de droits qu'elle n'a pas. Si l'auteur d'un RFC interdit toute modification à son texte, le RFC publié ne permettra pas de modifications (et ne pourra d'ailleurs pas être publié sur le chemin des normes).

La section 4 s'attaque aux droits que l'IETF trust devrait donner aux utilisateurs :

  • Droit de publier et de republier (section 4.1), une très ancienne politique de l'IETF,
  • Droit (évidemment) d'implémenter la technique décrite dans le RFC (section 4.3). C'est ici qu'apparait la distinction entre code et texte. (Le code inclut également le XML, l'ASN.1, etc.) Par un mécanisme non spécifié dans le RFC (cela a été choisi par la suite comme une liste publiée par l'IETF trust), le code est marqué spécialement (entre <CODE BEGINS> et <CODE ENDS>, comme défini dans la Trust Legal Provisions) et l'implémenteur aura davantage de droits sur le code, notamment le droit de modification. Cela ne résout pas, et de loin, tous les problèmes. Par exemple, cela ne permet pas de modifier du texte d'un RFC qui est inclus dans la documentation d'un logiciel.
  • Droit de modifier le texte ? Non, ce droit est exclu par la section 4.4, en tout cas pour le texte (le code inclus dans les RFC reste modifiable, pour permettre son intégration dans des logiciels libres.)

Comme indiqué plus haut, il n'y a pas de changements de fond depuis le RFC 5377, uniquement la suppression des références à l'ancien IAOC (IETF Administrative Oversight Committee).


Téléchargez le RFC 8721


L'article seul

RFC 8716: Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC

Date de publication du RFC : Février 2020
Auteur(s) du RFC : P. Resnick (Episteme Technology Consulting LLC), A. Farrel (Old Dog Consulting)
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Les procédures de l'IETF en cas de harcèlement lors des réunions physiques ou en ligne sont décrites dans le RFC 7776. Ce RFC 7776 reste d'actualité, il n'est modifié que sur un point : le remplacement de l'ancienne IAOC (IETF Administrative Oversight Committee) par les institutions du projet « IASA version 2 », décrit dans le RFC 8711.

On peut résumer notre nouveau RFC 8716 simplement : partout où, dans le RFC 7776, il y a écrit IAOC, remplacer par IETF LLC (IETF Administration Limited Liability Company, cf. RFC 8711), et partout où il y a écrit IAD (IETF Administrative Director), remplacer par IETF Executive Director. C'est tout.


Téléchargez le RFC 8716


L'article seul

RFC 8713: IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees

Date de publication du RFC : Février 2020
Auteur(s) du RFC : M. Kucherawy, R. Hinden (Check Point Software), J. Livingood (Comcast)
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Voici un nouveau RFC « bureaucratique » autour des processus menant au choix et à la désignation des membres d'un certain nombre d'organismes de la galaxie IETF, comme l'IAB ou l'IESG. Ce RFC remplace le RFC 7437, mais il y a peu de changements ; les principaux portent sur les conséquences de la nouvelle structure administrative de l'IETF, « IASA 2 », décrite dans le RFC 8711.

Ce RFC concerne la désignation des membres de l'IAB, de l'IESG et de certains membres de la IETF LLC (voir la section 6.1 du RFC 8711) et de l'IETF Trust. Il ne concerne pas l'IRTF et ses comités propres. Il ne concerne pas non plus le fonctionnement quotidien de ces comités, juste la désignation de leurs membres.

Le processus tourne autour d'un comité nommé NomCom (pour Nominating Committee, comité de nomination).Comme expliqué en section 2, il faut bien différencier les nommés (nominee), les gens dont les noms ont été soumis au NomCom pour occuper un poste à l'IAB, l'IESG, à l'IETF LLC ou à l'IETF Trust, des candidats (candidate) qui sont les gens retenus par le NomCom. Le NomCom, comme son nom l'indique, n'a pas de pouvoir de désignation lui-même, celle-ci est décidée (on dit officiellement « confirmée ») par un organisme différent pour chaque comité (l'IAB pour l'IESG, l'ISOC pour l'IAB, l'IESG pour l'IETF Trust, etc). Une fois confirmé, le candidat devient... candidat confirmé (confirmed candidate). Et s'il n'est pas confirmé ? Dans ce cas, le NomCom doit se remettre au travail et proposer un ou une autre candidat·e.

La section 3 de notre RFC explique le processus général : il faut désigner le NomCom, le NomCom doit choisir les candidats, et ceux-ci doivent ensuite être confirmés. Cela peut sembler compliqué, mais le but est d'éviter qu'une seule personne ou une seule organisation puisse mettre la main sur l'IETF. Le processus oblige à travailler ensemble.

À première vue, on pourrait penser que le NomCom a un vaste pouvoir mais, en fait, au début du processus, il ne peut pas décider des postes vacants, et, à sa fin, il n'a pas le pouvoir de confirmation.

Un point important et souvent oublié est celui de la confidentialité (section 3.6 du RFC). En effet, l'IETF se vante souvent de sa transparence, tout doit être public afin que chacun puisse vérifier que tout le processus se déroule comme prévu. Mais le travail du NomCom fait exception. Toutes ses délibérations, toutes les informations qu'il manipule, sont confidentielles. Autrement, il serait difficile de demander aux personnes nommées de fournir des informations personnelles, et les personnes extérieures au NomCom qui sont interrogées hésiteraient à s'exprimer franchement sur tel ou tel candidat. Et la publicité des débats risquerait d'encourager des campagnes de soutien extérieures au NomCom, et du lobbying, toutes choses qui sont formellement interdites. La section 9, sur la sécurité, revient sur cette importance de la confidentialité : puisque le NomCom enquête littéralement sur les nommés, il peut récolter des informations sensibles et il doit donc faire attention à les garder pour lui.

Le résultat est annoncé publiquement. Voici, par exemple, l'annonce de la sélection des membres de l'IESG, début 2019.

Et le NomCom lui-même, comment est-il choisi (section 4) ? De ses quatorze membres, seuls dix ont le droit de vote. D'abord, les dix membres du NomCom votants doivent répondre à un certain nombre de critères (section 4.14) : ils doivent avoir été physiquement présents à trois des cinq précédentes réunions de l'IETF (c'est une des exceptions au principe comme quoi la participation à l'IETF n'impose pas de venir aux réunions physiques), et c'est vérifié par le secrétariat de l'IETF (chaque participant peut facilement voir sur sa page sur le Datatracker s'il est éligible ou pas.) Et ils doivent (évidemment), être très familiers avec les processus internes de l'IETF. Une fois qu'on a un ensemble (pool) de volontaires qui acceptent de participer au NomCom (voyez un appel à volontaires typique), comment choisit-on les dix membres de plein exercice ? Eh bien, c'est là que c'est amusant, ils sont choisis au hasard... Il n'existe en effet pas de critères consensuels sur la meilleure méthode de choix des membres du NomCom (rappelez-vous qu'à l'IETF, on ne peut pas voter, puisqu'il n'y a pas de notion de « membre » et donc pas de corps électoral rigoureusement défini). Le tirage au sort se fait selon la méthode, ouverte et publiquement vérifiable, spécifiée par le RFC 3797. Voici par exemple les sources de données aléatoires pour 2018 et un exemple de résultat.

Le président du NomCom, lui, est désigné par l'ISOC. La liste des membres du NomCom est en ligne.

Une fois sélectionnés, les membres du NomCom se mettent au travail (section 5 du RFC). Ils ne sont bien sûr pas éligibles pour les postes qu'il vont devoir pourvoir. Lorsqu'ils doivent prendre une décision, le NomCom vote (une procédure rare à l'IETF). Les nominations peuvent être faites par n'importe quel participant à l'IETF, y compris le nommé lui-même. La décision de retenir tel ou tel nommé comme candidat doit s'appuyer sur sa connaissance de l'IETF et ses qualifications pour le poste (qui ne sont pas forcément les mêmes pour tous les comités : par exemple, l'IETF LLC nécessite des compétences administratives qui sont moins importantes à l'IAB). L'IETF étant une organisation de grande taille, le NomCom ne connait pas forcément tout le monde, et peut donc aller à la « pêche aux informations » en consultant des gens extérieurs sur tel ou tel nommé.

Le « mandat » typique dure deux ans (trois à l'IETF LLC et au Trust). Il n'y a pas de limite au nombre de « mandats » mais le NomCom peut évidemment décider de donner la priorité aux nommés qui n'ont pas encore eu de mandat, ou pas encore effectué beaucoup de mandats.

Les informations récoltées par le NomCom, et ses discussions sont archivées (mais non publiques : voir plus haut au sujet de la confidentialité). Ces archives sont directement utiles s'il faut, par exemple, remplir un poste et qu'on ne veut pas recommencer le processus de zéro pour certains nommés.

Les humains étant ce qu'ils sont, il y aura des désaccords en interne. Comment le NomCom gère-t-il les contestations (section 6) ? Idéalement, le NomCom doit essayer de les régler tout seul (ne serait-ce que pour préserver la confidentialité déjà mentionnée). Si cela ne marche pas, le problème est transmis à l'ISOC, qui nomme un arbitre, dont les décisions sont définitives (pas d'appel).

J'ai parlé ici surtout de pourvoir des postes, mais il peut aussi y avoir révocation (recall, section 7) d'un membre d'un des comités concernés. Cette révocation peut être demandé par au moins vingt participants à l'IETF, qui doivent être éligibles au NomCom, à l'ISOC. Un Recall Committee est alors créé, et peut décider à la majorité des trois quarts d'une révocation, sur la base des griefs présentés par les signataires de la demande de révocation.

Bien des choses au sujet du NomCom ne sont pas écrites, et la tradition orale joue un rôle important dans son fonctionnement. L'annexe C rassemble plusieurs grains de sagesse issus de cette tradition. Par exemple, avoir été président d'un groupe de travail IETF est considéré comme une bonne préparation à l'IESG. Il y a aussi des considérations sur l'équilibre global entre les membres d'un comité. Il ne s'agit pas seulement que chaque membre soit individuellement bon, il faut aussi que le comité rassemble des gens de perspectives différentes (âge, expérience, région d'origine, monde académique vs. entreprises à but lucratif, etc). La tradition orale recommande aussi d'éviter qu'une même organisation n'occupe trop de postes dans un comité. Même si les gens de cette organisation ne forment pas un bloc, l'impression donnée serait mauvaise pour l'IETF.

L'annexe B de notre RFC contient les changements depuis le RFC 7437. Rien de crucial, mais on notera :

  • L'IAOC n'existe plus depuis le RFC 8711 et a donc été remplacée par l'IETF LLC (et idem pour l'IAD remplacé par l'IETF Executive Director.)
  • Et plein de petits détails, parfois incorporés depuis un précédent RFC, comme les RFC 7776.

Téléchargez le RFC 8713


L'article seul

RFC 8712: The IETF-ISOC Relationship

Date de publication du RFC : Février 2020
Auteur(s) du RFC : G. Camarillo (Ericsson), J. Livingood (Comcast)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


L'IETF, l'organisme qui écrit les normes techniques de l'Internet fait partie de la galaxie des nombreuses organisations qui ont un rôle plus ou moins formel dans le fonctionnement du réseau. Ce nouveau RFC décrit les relations de l'IETF avec un autre de ces organismes, l'Internet Society (ISOC). Ce RFC remplace le RFC 2031, notamment pour s'adapter à la nouvelle structuration de l'IETF, dite « IASA 2 » (IASA veut dire IETF Administrative Support Activity).

Historiquement, l'IETF n'était qu'un sigle et une idée. Il n'y avait pas d'organisation formelle de l'IETF. Au début, cela marchait bien comme cela, mais des inquiétudes se sont fait jour. Si l'IETF n'existe pas juridiquement, qui est responsable des RFC ? Si une entreprise mécontente d'un RFC fait un procès, chose courante aux États-Unis, à qui va-t-elle le faire ? Aux individus auteurs du RFC ? C'est entre autres en raison de ce genre de risques que l'IETF s'est mise sous un parapluie juridique, celui de l'Internet Society (ISOC), organisation créée pour donner une structure à l'Internet, permettant par exemple d'avoir un budget, d'empêcher des escrocs de déposer la marque « Internet », pour faire du lobbying, etc. C'est donc l'ISOC qui est la représentation juridique de l'IETF, mais aussi de l'IAB et de l'IRTF. (Cela date de 1995, via un groupe de travail qui se nommait Poised, qui a lancé l'effort de formalisation des processus IETF.) Si une entreprise, motivée par des juristes aussi méchants que dans un roman de Grisham, veut faire un procès en raison d'un RFC, elle doit faire un procès à l'ISOC (qui a ses propres bataillons de juristes).

La relation exacte entre l'IETF et l'ISOC était spécifiée dans le RFC 2031. Depuis, a émergé le concept d'« IASA » (IASA veut dire IETF Administrative Support Activity), une structuration plus forte des activités non techniques de l'IETF. Encore depuis, la création de « IASA 2 », dans le RFC 8711, a changé les choses, nécessitant le remplacement du RFC 2031. L'IASA version 2 créé une nouvelle structure, l'IETF LLC (LLC veut dire Limited Liability Company), qui est une filiale de l'ISOC.

Assez d'histoire, voyons d'abord, les principes (section 2 de notre RFC). L'ISOC a dans ses missions d'encourager et d'aider le développement de normes techniques ouvertes, ce qui correspond au rôle de l'IETF. Le but est donc d'être efficace, et de produire des bonnes normes, librement accessibles, et via un processus ouvert.

La section 3 précise la répartition des rôles : à l'IETF le développement des normes, à l'ISOC la partie juridique et financière. L'ISOC ne doit pas intervenir dans les choix techniques.

Cela ne veut pas dire que l'ISOC se contente de regarder. La section 4 du RFC rappelle qu'elle contribue au choix des membres du NomCom (qui fait les nominations à certains postes, cf. RFC 8713), de l'IAB, et qu'elle sert d'appel ultime en cas de conflit. D'autre part, l'ISOC est membre de certaines organisations très formelles, comme l'UIT, et sert donc de relais pour l'IETF auprès de cette organisation (RFC 6756).

L'ISOC a aussi un rôle de popularisation des technologies Internet et de sensibilisation à certains enjeux. Par exemple, elle a créé le programme Deploy 360, qui promeut notamment DNSSEC et IPv6.

Et en sens inverse (section 5 du RFC), l'IETF a une représentation au conseil d'administration de l'ISOC (RFC 3677).

Du point de vue juridique, rappelons que l'IETF LLC est rattachée à l'ISOC comme décrit dans l'accord entre l'IETF et l'ISOC d'août 2018 (oui, il a fallu du temps pour publier ce RFC…) Notez que le RFC qualifie la LLC de disregarded (ignorée, négligée) mais c'est en fait le sens fiscal de disregarded qui compte : la LLC ne paie pas d'impôts, l'ISOC le fait pour elle.

L'IETF a une structure pour gérer sa propriété intellectuelle, l'IETF Trust, créée par le RFC 5378, puis mise à jour dans les RFC 8715 et RFC 8714. C'est l'IETF Trust qui gère les marques, le copyright, etc. C'est officiellement cet IETF Trust qui vous donne le droit de lire et de distribuer les RFC. La nouvelle structure ne change pas le rôle de l'IETF Trust.

Enfin, le fric (qui fait tourner le monde). La section 7 du RFC rappelle que c'est souvent l'ISOC qui finance les activités de l'IETF. Les détails financiers sont en ligne.

Voilà, cela fait déjà beaucoup de choses à savoir, et c'est bien sûr encore pire si on inclut tous les RFC de la nouvelle structuration IASA mais il faut se rappeler que cette complexité est en partie volontaire. D'abord, il faut éviter la domination d'une organisation unique qui contrôlerait tout, et ensuite certaines organisations nécessitent des compétences spécifiques (par exemple, à l'IETF, il faut être pointu sur les questions techniques).


Téléchargez le RFC 8712


L'article seul

RFC 8722: Defining the Role and Function of IETF Protocol Parameter Registry Operators

Date de publication du RFC : Février 2020
Auteur(s) du RFC : D. McPherson, O. Kolkman (ISOC), J.C. Klensin, G. Huston (APNIC), Internet Architecture Board
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Ce RFC officiel de l'IAB décrit le rôle de l'opérateur des registres des protocoles utilisé par l'IETF. Des tas de protocoles normalisés par cet organisme ont besoin de garder une trace des noms ou numéros réservés (par exemple les numéros de port de TCP ou UDP, les numéros d'options DHCP, etc.) C'est le rôle de l'opérateur du registre qui garde ces réservations (aujourd'hui, essentiellement l'IANA). Ce RFC remplace le RFC 6220, suite à la création de la nouvelle structure administrative de l'IETF, dans le RFC 8711.

L'IETF n'assure pas ce rôle d'opérateur du registre elle-même. Elle se focalise sur la production de normes (les RFC) et délègue la gestion du registre. Pourquoi les valeurs en question ne sont-elles pas directement mises dans les RFC ? Parce qu'elles évoluent plus vite que la norme elle-même. Ainsi, l'enregistrement d'un nouveau type d'enregistrement DNS est un processus bien plus souple que de modifier un RFC et la liste de tels types ne peut donc pas être figée dans un RFC (ceux-ci ne sont jamais modifiés, seulement remplacés, et cela n'arrive pas souvent).

Mais on ne peut pas non plus laisser chacun définir ses propres paramètres, car cela empêcherait toute interprétation commune. D'où cette idée d'un registre des paramètres. Les règles d'enregistrement dans ce registre, la politique suivie, sont décrites pour chaque norme dans la section IANA considerations du RFC, en utilisant le vocabulaire et les concepts du RFC 8126 (pour les types d'enregistrements DNS, cités plus haut, les détails sont dans le RFC 6895).

Plusieurs autres SDO suivent ce même principe de séparation entre la normalisation et l'enregistrement (en revanche, les groupes fermés d'industriels qui tentent d'imposer leur standard ne séparent pas en général ces deux fonctions). Par exemple, l'ISO définit, pour la plupart de ses normes, une Registration Authority ou bien une Maintenance Agency qui va tenir le registre. (Exemples : l'opérateur du registre de ISO 15924 est le consortium Unicode et celui du registre de ISO 639 est SIL. Contre-exemple : l'opérateur du registre de ISO 3166 est l'ISO elle-même.) Pourquoi cette séparation ? Les raisons sont multiples mais l'une des principales est la volonté de séparer la politique de base (définie dans la norme) et l'enregistrement effectif, pour gérer tout conflit d'intérêts éventuel. Un opérateur de registre séparé peut être plus indépendant, afin de ne pas retarder ou bloquer l'enregistrement d'un paramètre pour des raisons commerciales ou politiques. Notons aussi que bien d'autres fonctions liées à l'IETF sont également assurées à l'extérieur, comme la publication des RFC.

Contre-exemple, celui du W3C, qui utilise très peu de registres et pas d'opérateur de registre officiel séparé. En pratique, c'est l'IANA qui gère plusieurs registres Web, comme celui des URI bien connus (RFC 8615), celui des types de fichiers (comme application/pdf ou image/png), celui des en-têtes (utilisés notamment par HTTP), etc. En dehors de l'IANA, le W3C a quelques registres gérés en interne comme celui de Xpointer. Pour le reste, la politique du W3C est plutôt qu'un registre est un point de passage obligé et que de tels points ne sont pas souhaitables.

Dans le cas de l'IETF, les documents existants sont le RFC 2026, qui décrit le processus de normalisation mais pas celui d'enregistrement. Ce dernier est traditionnellement connu sous le nom de « fonction IANA » (d'où la section IANA considerations des RFC) même si, en pratique, ce n'est pas toujours l'IANA qui l'effectue. (Les registres de l'IANA sont en https://www.iana.org/protocols/.)

La section 2 du RFC expose donc le rôle et les responsabilités du(des) opérateur(s) de registres de paramètres. Celui(ceux)-ci, nommés avec majuscules IETF Protocol Parameter Registry Operator, seront choisis par l'IETF LLC (RFC 8711). J'ai mis le pluriel car l'IANA n'assure pas actuellement la totalité du rôle : il existe d'autres opérateurs de registres, en général sur des tâches très secondaires comme par exemple le RIPE-NCC pour l'enregistrement en e164.arpa (ENUM, cf. RFC 6116). Dans le futur, on pourrait imaginer un rôle moins exclusif pour l'IANA.

La section 2.1 est la (longue) liste des devoirs qu'implique le rôle d'opérateur de registre. Il y a bien sûr le tenue du registre à proprement parler mais ce n'est pas tout. En voici une partie :

  • Donner des avis sur les futurs RFC (concrètement, relire les sections IANA considerations à l'avance, pour voir si elles ne poseraient pas de problèmes insurmontables au registre).
  • Suivre les RFC : l'opérateur du registre n'est pas censé déterminer la politique mais l'appliquer. Si un RFC dit que l'enregistrement dans tel registre se fait sans contrainte, l'opérateur du registre ne peut pas refuser un enregistrement, par exemple. Chaque registre a une politique d'enregistrement, expliquée dans le RFC correspondant (les règles générales figurent dans le RFC 8126).
  • Bien indiquer dans chaque registre les références notamment le numéro du RFC qui normalise ce registre et pour chaque paramètre enregistré dans le registre, indiquer la source de ce paramètre et la date d'enregistrement.
  • En cas de désaccord ou de problème, se tourner vers l'IESG, seule habilitée à trancher.
  • Diffuser gratuitement les registres qui sont tous publics par défaut (contrairement à ce qui se passe chez l'ultra-dinosaure ISO). Un exemple est le registre de DHCP, en https://www.iana.org/assignments/bootp-dhcp-parameters/.
  • Maintenir les listes de diffusion spécifiées pour certains registres, par exemple lorsque l'enregistrement nécessite un examen par un expert, sous l'œil du public.
  • Produire des rapports réguliers à destination de l'IAB, suivant le RFC 2860 mais aussi suivant l'accord supplémentaire qui l'a complété, et à destination de toute l'IETF. Aujourd'hui, cela se fait sous la forme de l'exposé IANA qu'il y a à chaque plénière de l'IETF. Ces rapports incluent des points comme les performances de l'opérateur du registre (délai de traitement, par exemple).
  • Ne pas oublier que les droits de propriété intellectuelle sur ces registres sont gérés par l'IETF Trust (RFC 4371).

Après cette description des devoirs de l'opérateur du registre, la section 2 continue avec les devoirs des autres acteurs. En section 2.2, ceux de l'IAB, qui supervise l'opérateur du registre : l'IAB procède à la délégation formelle du registre, après que l'IETF LLC ait identifié les candidats. L'IAB décide, l'IETF LLC gère la relation avec l'opérateur.

En section 2.3, le rôle de l'IESG : celui-ci s'occupe de la partie technique, vérifier que les RFC comportent une bonne section IANA considerations, identifier les experts techniques si le RFC précise que l'enregistrement est précédé d'une évaluation technique (exemple : le RFC 5646, où l'enregistrement d'une langue dans le registre des langues est précédé d'une telle évaluation par un linguiste), répondre aux questions de l'opérateur du registre si celui-ci a un problème pratique.

En section 2.4, le rôle de l'IETF Trust (RFC 4371). Il gère la propriété intellectuelle de l'IETF donc est « propriétaire » du contenu des registres. Enfin, en section 2.5, le rôle de l'IETF LLC, bras administratif de l'IETF, qui est de gérer au quotidien les relations avec l'opérateur du registre. (C'est la principale nouveauté de ce RFC, par rapport au RFC 6220, que le remplacement de l'ancienne structure par cette IETF LLC.)

Voilà, l'essentiel était là mais la section 3 rajoute quelques détails.


Téléchargez le RFC 8722


L'article seul

RFC 8720: Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries

Date de publication du RFC : Février 2020
Auteur(s) du RFC : R. Housley (Vigil Security), O. Kolkman (Internet Society)
Pour information
Première rédaction de cet article le 28 février 2020


Traditionnellement, le fonctionnement de la normalisation dans l'Internet sépare deux fonctions : l'IETF développe les normes techniques (qui sont publiées dans les RFC, documents immuables) et un opérateur de registres techniques, actuellement l'IANA, gère les nombreux registres qui stockent les paramètres des protocoles de l'IETF. Au contraire des RFC, ces registres changent tout le temps. Ce nouveau RFC décrit les principes de haut niveau sur lesquels repose le fonctionnement de ces registres. Il remplace le RFC 7500, sans changement crucial, juste en intégrant la nouvelle organisation administrative de l'IETF, qui voit le remplacement de l'IAOC par l'IETF LLC.

Ces registres sont cruciaux pour le bon fonctionnement de l'Internet. Presque tous les protocoles Internet dépendent d'un ou de plusieurs registres. Aujourd'hui, il existe plus de 2 000 registres à l'IANA (la liste complète est en https://www.iana.org/protocols). Les valeurs stockées peuvent être des nombres, des chaînes de caractères, des adresses, etc. Leur allocation peut être centralisée (tout est à l'IANA) ou décentralisée, avec l'IANA déléguant à des registres qui à leur tour délèguent, comme c'est le cas pour les noms de domaine et pour les adresses IP.

Notons aussi que, pendant longtemps, la gestion des registres et la publication des RFC étaient assurés par le même homme, Jon Postel à l'ISI. Aujourd'hui, les deux opérations sont complètement séparées, https://www.iana.org/ et https://www.rfc-editor.org/.

L'IANA n'a pas de pouvoirs de police : le respect des registres IANA dépend uniquement de la bonne volonté générale. Évidemment, la pression est forte pour respecter ces registres, puisque le bon fonctionnement de l'Internet en dépend. Ce RFC présente les principes sur lesquels ces registres reposent (sections 2 et 3 du RFC) :

  • Unicité des identificateurs. C'est l'un des principaux buts des registres, s'assurer que qu'il n'y a qu'un seul .fr ou .org, ou que l'algorithme 13 de DNSSEC désigne bien ECDSA pour tout le monde.
  • Stabilité. Les registres doivent tenir plus longtemps que la page Web corporate moyenne. Leur contenu existant ne doit pas changer sauf s'il y a une très bonne raison.
  • Prédictabilité. Le processus d'enregistrement doit être prévisible et ne pas comporter de soudaines surprises (« finalement, il faut tel papier en plus »). Parfois, un jugement humain est nécessaire (cf. RFC 8126) donc le processus n'a pas à être algorithmique, ni à être limité dans le temps, mais il ne doit pas soudainement ajouter des étapes non prévues.
  • Publicité. Les registres doivent être publics (en pratique, le principal mode de distribution est via le Web). Ce n'est pas si évident que cela, les dinosaures attardés de la normalisation, comme l'AFNOR, l'ISO ou l'IEEE ne le font pas.
  • Ouverture. Le processus qui détermine les politiques d'enregistrement doit être ouvert à tous ceux qui désirent participer. Dans presque tous les cas, c'est l'IETF qui détermine cette politique (les exceptions sont importantes comme la gestion de la racine des noms de domaine), via un RFC développé en effet dans un processus ouvert. Le RFC 8126 détaille les politiques IANA possibles. (Parmi elles, certaines nécessitent un examen par un expert, le jugement humain mentionné plus haut.)
  • Transparence. La gestion des registres ne doit pas être opaque. On peut écrire à l'IANA, ou bien passer les voir Away From Keyboard pendant les réunions IETF, où l'IANA a toujours un stand.
  • Redevabilité. L'IANA doit rendre compte de sa gestion. Selon le RFC 8722, la supervision de la fonction IANA incombe à l'IAB (RFC 2850). En outre, l'IETF LLC (RFC 8711) a un SLA avec l'actuel opérateur de la fonction IANA, l'ICANN. L'IAB et l'IETF LLC sont eux-même redevables devant une communauté plus large, via le processus NomCom (RFC 8713). Pour les adresses IP et les ressources associées, le RFC 7249 fait gérer la redevabilité par les RIR (RFC 7020). Ceux-ci sont des organisations ouvertes et eux-même redevables devant leurs membres. (Avez-vous noté quel registre n'était pas mentionné comme bon exemple par le RFC ?)

La section 5 décrit le changement depuis le prédécesseur, le RFC 7500. Il ne s'agit que d'un changement bureaucratique ; l'ancienne IAOC (IETF Administrative Oversight Committee) a été, dans le RFC 8711, remplacée par une nouvelle structure, l'IETF LLC (Limited Liability Company), nécessitant la mise à jour du RFC 7500.


Téléchargez le RFC 8720


L'article seul

RFC 8730: Independent Submission Editor Model

Date de publication du RFC : Février 2020
Auteur(s) du RFC : N. Brownlee (The University of Auckland), R. Hinden (Check Point Software)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Si vous n'aimez pas les RFC de procédure, et que vous ne voulez que de la technique, rassurez-vous, ce document est court : il spécifie le rôle et les qualités de l'ISE (Independent Submission Editor), celui (ou celle) qui supervise les RFC qui ne passent pas par l'IETF. Il remplace le RFC 6548, remplacement nécessaire compte tenu de la nouvelle structure adminstrative de l'IETF, introduite par le RFC 8711.

Comment, ça existe, des RFC non-IETF ? Tous les RFC ne naissent pas au sein d'un des nombreux groupes de travail de l'IETF ? Eh oui, c'est souvent oublié, mais c'est le cas, il existe une voie indépendante qui permet à des individus de publier un RFC, quel que soit l'avis de l'IETF. Cette voie est décrite dans le RFC 4846. Autrefois, il n'existait qu'un seul RFC Editor pour examiner et préparer tous les RFC. Mais cette tâche est désormais répartie entre plusieurs éditeurs spécialisés et l'ISE est en charge de la voie indépendante.

Ce mécanisme de répartition des tâches pour les RFC est décrit dans le RFC 8728 (modèle du RFC Editor, « v2 ») et ce RFC 8730.

La section 2.1 décrit les qualifications attendues de l'ISE. Ce doit être quelqu'un d'expérimenté (senior), compétent techniquement dans les sujets traités à l'IETF (ce qui fait beaucoup !), connu et reconnu de la communauté IETF, sachant écrire et corriger, connaissant très bien l'anglais, et capable de travailler dans le milieu souvent agité de l'IETF.

Sa tâche principale (section 2.2) est de maintenir la qualité des RFC de la voie indépendante, par la relecture et l'approbation des documents, avant transmission au Producteur des RFC (RFC Production Center). Mais il doit aussi traiter les errata pour les RFC de la voie indépendante, contribuer à définir les évolutions de cette voie, interagir avec les autres acteurs des RFC, et fournir des statistiques à l'IAB et l'IETF LLC (cf. RFC 8711). Il peut se faire assister par un conseil consultatif, dont il nomme les membres « at the pleasure of the ISE », dit le RFC dans une jolie formule. Il y a aussi un conseil éditorial, également nommé par l'ISE (section 3 du RFC).

Le site officiel des RFC contient une page consacrée à la voie indépendante, si cela vous tente d'y publier.

L'ISE est nommé par l'IAB. Aujourd'hui, c'est Adrian Farrel, qui joue ce rôle.

Il y a peu de changements depuis le RFC précédent, le RFC 6548, essentiellement le remplacement de l'ancienne structure administrative de l'IETF (l'IAOC) par la nouvelle (l'IETF LLC).


Téléchargez le RFC 8730


L'article seul

RFC 8711: Structure of the IETF Administrative Support Activity, Version 2.0

Date de publication du RFC : Février 2020
Auteur(s) du RFC : B. Haberman (Johns Hopkins University), J. Hall (CDT), J. Livingood (Comcast)
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Le sigle IASA (IETF Administrative Support Activity) désigne les structures qui font le travail administratif, non-technique, pour l'IETF. L'actvité de l'IETF est de produire des normes (sous forme de RFC) et cette activité nécessite toute une organisation et des moyens concrets, des employés, des logiciels, des déclarations pour le fisc, des serveurs, des réunions, et c'est tout cela que gère l'IASA. Dans sa première version, qui avait été spécifiée dans le RFC 4071 en 2005, l'IASA était gérée par l'ISOC, et était surtout formée par l'IAOC (IETF Administrative Oversight Committee). Dans cette « version 2 » de l'IASA, l'IAOC disparait, et l'essentiel des tâches revient à un nouvel organisme, une LLC (Limited Liability Company). Ce nouveau RFC remplace le RFC 4071 et décrit cette IETF Administration LLC et ses relations avec l'IETF.

L'IETF était à l'origine une structure informelle, des ingénieurs qui se réunissaient, discutaient, et écrivaient des RFC. Petit à petit, elle a grossi et s'est structurée (certains diraient « bureaucratisée »). La précédente structure était encore assez légère, reposant largement sur l'ISOC. L'IETF ayant continué à grossir, les enjeux ont continué à devenir de plus en plus importants pour la société dans son ensemble, il a été nécessaire de créer une organisation propre, la LLC (Limited Liability Company). Le conseil d'administration de cette LLC assurera les tâches qui étaient auparavant celles de l'IAOC. Les différents RFC qui mentionnaient l'IAOC ont été mis à jour pour cela (d'où la publication, entre autres, des RFC 8721, RFC 8714 ou RFC 8716). De même, l'ancienne fonction d'IAD IETF Administrative Director, la personne qui dirigeait le travail de l'IASA, est supprimée et ses tâches passent au directeur de la LLC, avec le titre de IETF Executive Director. C'était auparavant Portia Wenze-Danley mais Jay Daley lui a succédé le 24 octobre 2019.

C'est donc désormais cette « IETF LLC » qui est la structure légale de l'IETF mais aussi de l'IRTF, de l'IAB et, partiellement, du RFC Editor.

Cette réorganisation très importante ne change pourtant rien au processus de production des normes, qui, lui, reste couvert par le RFC 2026 (et ses nombreuses mises à jour, comme le RFC 6410). Cette écriture des normes techniques n'est pas pilotée par l'IASA mais par l'IESG et l'IAB (cf. RFC 2850). Même chose pour le travail de l'IRTF (RFC 2014). Si vous ne vous intéressez qu'à la technique, vous pouvez donc sauter le reste de cet article, qui ne parlera que de gouvernance et de droit.

Aucun changement non plus pour les procédures d'appels en cas de désaccord, ou pour les nominations (RFC 8713).

Comme la LLC n'a pas beaucoup de moyens, et que l'activité de l'IETF se déroule dans un environnement parfois compliqué, notamment du point de vue juridique (risque de procès), l'IETF continue de s'appuyer sur l'Internet Society (ISOC). L'accord entre LLC et ISOC est disponible en ligne. Voir aussi le RFC 8712.

La section 4 de notre RFC définit un certain nombre de termes, et pose les principes qui régissent la LLC. Parmi les définitions :

  • LLC (Limited Liability Company, le nom complet est IETF Administration LLC) : le nouvel organisme, créé par le projet « IASA [version] 2 », qui gérera la partie « administrative » de l'IETF ; c'est le représentant légal de l'IETF.
  • Directeur (IETF LLC Executive Director) : la personne qui dirigera la LLC. Ce rôle remplace l'ancien IAD.
  • Conseil d'Administration (IETF LLC Board) : le groupe de personnes qui supervise la LLC (le directeur s'occupant des opérations quotidiennes).

Le LLC va donc s'occuper :

  • Des réunions physiques, un gros travail organisationnel,
  • Des finances, et de la récolte de fonds,
  • De la conformité aux lois et réglements divers. (La LLC est enregistrée aux États-Unis et doit donc suivre les lois de ce pays.)

Elle ne s'occupera pas du développement des normes (le travail central de l'IETF, qui ne relève pas de cette gestion administrative).

Les principes que lesquels va s'appuyer la LLC pour cela :

La section 5 du RFC expose la structure choisie pour mettre en pratique ces principes. Un directeur (aujourd'hui Jay Daley) pour les fonctions opérationnelles du quotidien, et plusieurs employés (traditionnellement, l'IETF fonctionnait avec une équipe très réduite, mais cela n'est plus possible aujourd'hui). Mais une spécificité de l'IETF est aussi son caractère associatif et fondé sur le volontariat. De nombreux participants à l'IETF donnent de leur temps pour effectuer des fonctions de support de l'IETF. C'est ainsi que, pendant longtemps, les outils logiciels de travail en groupe étaient tous développés et maintenus par des participants volontaires. De même, la gestion du réseau pendant les réunions, ou bien les activités de sensibilisation et d'éducation sont traditionnellement assurées en dehors des cadres organisés. Le but de la LLC n'est pas d'absorber tous ces efforts. Au contraire, le RFC insiste sur l'importance pour la LLC de travailler avec les volontaires, sans chercher à les remplacer.

Et qui est membre du conseil d'administration de la LLC ? La section 6 l'explique (cela avait été une des discussions les plus vives lors de la création de la LLC). Certains membres sont nommés par l'IESG, d'autres par l'ISOC. Vous pouvez voir sur le site Web de la LLC la liste des membres actuels.

L'argent étant une question évidemment cruciale, la section 7 discute le financement de la LLC. (Au fait, les informations financières sont elles aussi en ligne, pour la transparence. Et voici le plan pour le budget 2020.) Bien évidemment, le RFC précise que les éventuels dons, par exemple d'entreprises, ne donnent aucun droit particulier et ne permettent pas de donner des consignes à la LLC (du moins en théorie). L'argent ainsi récolté doit servir uniquement aux activités IETF, et proches (comme l'IRTF).

La LLC doit obéir à un certain nombre de règles, détaillées en section 8, et développées dans ses politiques publiques. Par exemple, la LLC doit avoir des politiques internes contre la corruption, ou en faveur de la protection des données personnelles. D'autre part, sa nature d'organisation officiellement enregistrée aux États-Unis l'oblige à appliquer certaines lois états-uniennes comme les sanctions contre ceux que le gouvernement de Washington va qualifier de terroristes. Pour l'instant, l'IETF n'a jamais pris de décision dans des domaines politiquement délicats comme celui-ci. Mais dans le futur ? Compte-tenu de l'actuelle crise entre le gouvernement Trump et Huawei, faudra-t-il un jour se demander si les employés de Huawei doivent être exclus des réunions ? Cela signifierait sans doute la fin de l'IETF.

Pour résumer les principaux changements entre l'« IASA 1 » (RFC 4071) et l'« IASA 2 » décrite par ce RFC : L'IAOC et l'IAD disparaissent, remplacés par la LLC, son conseil d'administration et son directeur.


Téléchargez le RFC 8711


L'article seul

RFC 8729: The RFC Series and RFC Editor

Date de publication du RFC : Février 2020
Auteur(s) du RFC : R. Housley (Vigil Security), L. Daigle (Thinking Cat)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


Les RFC, qui incluent notamment les normes techniques de l'Internet, sont en général réalisés par l'IETF mais sont publiés par une entitée séparée, le RFC editor. Ce RFC documente les RFC, et le rôle du RFC Editor. Il remplace le RFC 4844, avec assez peu de changements, essentiellement l'adaptation à la nouvelle structure administrative de l'IETF, décrite dans le RFC 8711.

Comme pour beaucoup de choses dans l'Internet, la définition exacte des rôles des différents acteurs n'avait pas été formalisée car personne n'en ressentait le besoin. Au fur et à mesure que l'Internet devient une infrastructure essentielle, cette absence de formalisation est mal ressentie et la politique actuelle est de mettre par écrit tout ce qui était implicite auparavant.

C'est le cas du rôle du RFC Editor. Autrefois le titre d'une seule personne, Jon Postel, ce nom désigne désormais une organisation plus complexe. Relire les RFC avant publication, les corriger, leur donner un numéro et assurer leur distribution, tels sont les principaux rôles du RFC Editor.

Notre RFC décrit le but des RFC (section 2) : « documenter les normes de l'Internet, et diverses contributions ». Puis, il explique le rôle du RFC Editor, sa place dans le processus de publication et les fonctions qu'il doit assurer (le cahier des charges de l'IETF avait été publié dans le RFC 4714). Pour plus de détails sur le travail, on peut consulter le site Web du RFC Editor.

Il faut noter (section 5 du RFC) que le RFC editor reçoit des textes candidats par plusieurs voies. Si la plus connue est celle de l'IETF, il peut aussi publier des RFC d'autres origines notamment ceux des soumissions indépendantes (RFC 4846). Il est supervisé par l'IAB et par la nouvelle IETF LLC (RFC 8711.) Le fonctionnement détaillé du RFC Editor et son organisation figurent dans le RFC 8728.

Le RFC editor a une mission difficile puisqu'il doit agir avec prudence, voire avec conservatisme, pour assurer la qualité et la disponibilité des RFC pendant de très longues périodes.

Il y a peu de changements depuis le RFC précédent sur ce sujet (le RFC 4844), essentiellement le remplacement de l'ancienne IAOC par l'IETF LLC décrite dans le RFC 8711.


Téléchargez le RFC 8729


L'article seul

RFC 8728: RFC Editor Model (Version 2)

Date de publication du RFC : Février 2020
Auteur(s) du RFC : O. Kolkman, J. Halpern (Ericsson), R. Hinden (Check Point Software)
Pour information
Réalisé dans le cadre du groupe de travail IETF iasa2
Première rédaction de cet article le 28 février 2020


L'articulation compliquée entre l'IETF qui produit les normes TCP/IP et le RFC Editor qui les publie, n'a jamais cessé de faire couler de l'encre (ou d'agiter des électrons). Dans ce document, l'IAB décrit un modèle pour le RFC Editor, modèle où les fonctions de ce dernier sont éclatées en plusieurs fonctions logiques. Elles peuvent ainsi être réparties entre plusieurs groupes. Ce RFC remplace le RFC 6635, avec peu de changements : c'est toujours le modèle « v2 » du modèle RFC Editor.

Le document de référence actuel est le RFC 8729. Comme le rappelle la section 1, il décrit les tâches du RFC Editor de manière globale, comme si c'était forcément une seule entité (c'était, à l'origine, une seule personne, Jon Postel). La section 2 note que la tâche de RFC Editor est actuellement une partie de l'IASA (dont la récente réforme, décrite dans le RFC 8711, a nécessité ce nouveau RFC) et financée par son budget.

La même section 2 s'attaque à la définition du rôle du RFC Editor sous forme de fonctions séparées. Elles sont ici légèrement modifiées, compte-tenu de l'expérience et des problèmes de communication rencontrés, problèmes de communication qui n'existaient évidemment pas lorsque Postel faisait tout lui-même. Le terme de RFC Editor désigne collectivement toutes ces fonctions. L'IAB voit maintenant trois fonctions (voir aussi le dessin 1 de notre RFC) :

  • Éditeur de la série des RFC,
  • Producteur des RFC,
  • Publieur des RFC,
  • Enfin, l'éditeur des contributions indépendantes, décrit à part, dans le RFC 8730.

Chaque section va ensuite détailler ces tâches. Il y a également des rôles de supervision, tenus par l'IAB (RFC 2850) et l'IETF LLC (RFC 8711).

L'Éditeur de la série des RFC (RFC Series Editor, poste actuellement vacant depuis le départ d'Heather Flanagan) est décrit en premier, en section 2.1. Il ou elle est responsable du travail à long terme, il doit définir les principes qui assurent la pérennité des RFC, réfléchir à la stratégie, développer le RFC 7322, le guide de style des RFC, de la langue des RFC, etc. Il sert aussi de « visage » aux RFC, vis-à-vis, par exemple, des journalistes. L'Éditeur est censé travailler avec la communauté IETF pour les décisions politiques. Désigné par l'IAB, il ou elle sera formellement un employé de l'IETF LLC, la structure administrative de l'IETF.

Le RFC 8728 évalue la charge de travail à un mi-temps, ce qui me semble très peu. Notre RFC décrit les compétences nécessaires (section 2.1.6) pour le poste d'Éditeur de la série des RFC, compétences en anglais et en Internet, capacité à travailler dans l'environnement... spécial de l'IETF, expérience des RFC en tant qu'auteur souhaitée, etc.

Le travail quotidien est, lui, assuré par le Producteur des RFC (RFC Production Center) dont parle la section 2.2. C'est un travail moins stratégique. Le Producteur reçoit les documents bruts, les corrige, en discute avec les auteurs, s'arrange avec l'IANA pour l'allocation des numéros de protocoles, attribue le numéro au RFC, etc.

Les RFC n'étant publiés que sous forme numérique, il n'y a pas d'imprimeur mais le numérique a aussi ses exigences de publication et il faut donc un Publieur des RFC (RFC Publisher), détaillé en section 2.3. Celui-ci s'occupe de... publier, de mettre le RFC dans le dépôt où on les trouve tous, d'annoncer sa disponibilité, de gérer l'interface permettant de soumettre les errata, de garder à jour ces errata, et de s'assurer que les RFC restent disponibles, parfois pendant de nombreuses années.

Chacune de ces fonctions pourra faire l'objet d'une attribution spécifique (à l'heure actuelle, les fonctions de Producteur et de Publieur sont assurées par le même groupe à l'AMS). La liste à jour peut être vue sur le site officiel.

Un comité joue un rôle de supervision et de contrôle du RFC Editor : le RSOC (RFC Series Oversight Committee) est décrit en section 3.

Combien cela coûte et qui choisit les titulaires des différentes fonctions ? La section 4 décrit ce rôle, dévolu à l'IETF LLC ( IETF Administration Limited Liability Company, cf. RFC 8711). Le budget est publié en sur le site de l'IETF LLC et on y trouvera aussi les futures évaluations du RFC Editor. On peut aussi trouver cette information, ainsi que plein d'autres sur le fonctionnement du RFC Editor, via le site officiel).

Comme indiqué plus haut, il n'y a pas de grand changement depuis le RFC 6635, juste le remplacement de l'ancienne IAOC par l'IETF LLC.


Téléchargez le RFC 8728


L'article seul

RFC 8709: Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol

Date de publication du RFC : Février 2020
Auteur(s) du RFC : B. Harris, L. Velvindron (cyberstorm.mu)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF curdle
Première rédaction de cet article le 26 février 2020


Un très court RFC, juste pour ajouter au protocole SSH les algorithmes de signature Ed25519 et Ed448. Ces algorithmes sont déjà disponibles dans OpenSSH.

Ce protocole SSH est normalisé dans le RFC 4251, et a de nombreuses mises en œuvre, par exemple dans le logiciel libre OpenSSH. Pour authentifier le serveur, SSH dispose de plusieurs algorithmes de signature. Ce nouveau RFC en ajoute deux, dont Ed25519, qui avait été normalisé dans le RFC 8032. (En toute rigueur, l'algorithme se nomme EdDSA et Ed25519 est une des courbes elliptiques possibles avec cet algorithme. Mais je reprends la terminologie du RFC.) À noter que les courbes elliptiques sous-jacentes peuvent également être utilisées pour l'échange de clés de chiffrement, ce que décrit le RFC 8731.

La section 3 de notre RFC donne les détails techniques, suivant le RFC 4253. L'algorithme se nomme ssh-ed25519. Son copain avec la courbe elliptique Ed448 est ssh-ed448. Ils sont tous les deux enregistrés à l'IANA.

Le format de la clé publique est la chaîne "ssh-ed25519" suivie de la clé, telle que décrite dans le RFC 8032, section 5.1.5 (et 5.2.5 pour Ed448). Avec OpenSSH, vous pouvez la voir dans ~/.ssh/id_ed25519.pub. Les signatures sont faites selon la technique du RFC 8032, sections 5.1.6 et 5.2.6. Leur format est décrit en section 6, et la vérification de ces signatures en section 7, en suivant la procédure des sections 5.1.7 et 5.2.7 du RFC 8032.

La façon la plus courante de vérifier la clé publique du serveur SSH auquel on se connecte est le TOFU. Si on préfère une vérification plus sérieuse, on peut utiliser les clés SSH publiées dans le DNS, méthode décrite dans le RFC 4255, utilisant des enregistrements de type SSHFP. Cela fait longtemps que ces enregistrements peuvent utiliser Ed25519 (cf. RFC 7479) et notre RFC ajoute le cas de Ed448, par exemple :

example.net.  IN SSHFP 6 2 ( a87f1b687ac0e57d2a081a2f282672334d90ed316d2b818ca9580ea384d924 01 )
  

(Il est enregistré à l'IANA.)

Ed25519 a été ajouté à OpenSSH en janvier 2014 (donc bien avant la publication de ce RFC.) C'est l'option -t de ssh-keygen qui permet de sélectionner cet algorithme :

% ssh-keygen -t ed25519  -f /tmp/ed25519
Generating public/private ed25519 key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /tmp/ed25519.
Your public key has been saved in /tmp/ed25519.pub.
The key fingerprint is:
SHA256:VEN6HVM0CXq+TIflAHWCOQ88tfR35WXQZ675mLIhIIs stephane@godin
The key's randomart image is:
+--[ED25519 256]--+
|         o==O+*++|
|         oB* B.+*|
|        o o== oo=|
|       . . o.= .o|
|      . S   + oo |
|     . o . o oo  |
|    E .   . +  + |
|           ...o .|
|            .o   |
+----[SHA256]-----+
  

À noter que OpenSSH 7.6 n'a pas ed448. D'une manière générale, ed25519 a été beaucoup plus souvent mise en œuvre dans les clients et serveurs SSH.


Téléchargez le RFC 8709


L'article seul

RFC 8740: Using TLS 1.3 with HTTP/2

Date de publication du RFC : Février 2020
Auteur(s) du RFC : D. Benjamin (Google)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF httpbis
Première rédaction de cet article le 24 février 2020


Voici un très court RFC, pour résoudre un petit problème d'interaction entre TLS 1.3 et HTTP/2.

Les anciennes versions du protocole de sécurité TLS avaient un mécanisme de renégociation des paramètres de la session, permettant de changer certains paramètres même après que la session ait démarré. C'était parfois utilisé pour l'authentification du client TLS, par exempe lorsqu'un serveur HTTP décide de demander ou pas un certificat client en fonction de la requête dudit client. Or, dans la version 2 de HTTP, HTTP/2, normalisée dans le RFC 7540, il peut y avoir plusieurs requêtes HTTP en parallèle. On ne peut donc plus corréler une requête HTTP avec une demande de certificat. Le RFC 7540 (section 9.2.1) interdit donc d'utiliser la renégociation.

Mais la nouvelle version de TLS, la 1.3, spécifiée dans le RFC 8446, a supprimé complètement le mécanisme de renégociation. À la place, un mécanisme d'authentification spécifique a été normalisé (section 4.6.2 du RFC 8446.) Or, ce mécanisme pose les mêmes problèmes que la rénégociation avec le parallélisme que permet HTTP/2. Il fallait donc l'exclure aussi, ce qui n'avait pas été remarqué tout de suite. C'est ce que fait notre RFC. Pas d'authentification après la poignée de main initiale, elle est incompatible avec HTTP/2 (ou avec le futur HTTP/3, d'ailleurs, qui permet également des requêtes en parallèle) et elle doit déclencher une erreur.

À noter que la renégociation était également utilisée pour dissimuler le vrai certificat serveur, par exemple pour contourner certaines solutions de censure. Comme TLS 1.3 chiffre désormais le certificat serveur, la renégociation n'est plus utile pour ce scénario. En outre, la renégociation avait posé quelques problèmes de sécurité (cf. une faille fameuse, et le RFC 7457.)

Outre la renégociation, il y a d'autres messages qui peuvent survenir après la poignée de main initiale. C'est le cas des KeyUpdate (RFC 8446, sections 4.6.3 et 7.2) mais ils concernent la session TLS entière, pas juste une requête HTTP, donc ils sont compatibles avec le parallélisme de HTTP/2. Quant aux NewSessionTicket (RFC 8446, section 4.6.1), ils dépendent, eux, de la requête HTTP, mais leur interaction avec HTTP/2 est prévue et documentée dans le RFC 8470, et ils sont donc acceptés.


Téléchargez le RFC 8740


L'article seul

RFC 8656: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)

Date de publication du RFC : Février 2020
Auteur(s) du RFC : T. Reddy (McAfee), A. Johnston (Villanova University), P. Matthews (Alcatel-Lucent, apparemment en fait Nokia, J. Rosenberg (jdrosen.net)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tram
Première rédaction de cet article le 23 février 2020


Le protocole TURN, que décrit notre RFC, est le dernier recours des applications coincées derrière un routeur NAT et qui souhaitent communiquer avec une application dans la même situation (cf. RFC 5128). Avec TURN, le serveur STUN ne se contente pas d'informer sur l'existence du NAT et ses caractéristiques, il relaie chaque paquet de données. Ce nouveau RFC remplace la définition originelle de TURN (dans le RFC 5766), et inclut plusieurs changements qui étaient jusqu'à présent spécifiés dans des RFC séparés, comme IPv6 ou DTLS, et ajoute la possibilité de relayer les messages ICMP.

Être situé derrière un routeur NAT n'est jamais une situation enviable. De nombreuses applications fonctionnent mal ou pas du tout dans ce contexte, nécessitant des mécanismes spécifique de traversée des NAT. Le socle de tous ces mécanismes de traversée est STUN (RFC 8489), où le client STUN (notre machine bloquée par le NAT) communique avec un serveur STUN situé dans le monde libre pour apprendre sa propre adresse IP externe. Outre cette tâche de base, des extensions à STUN permettent d'aider davantage le client, c'est par exemple le cas de TURN que normalise notre RFC.

L'idée de base est que deux machines Héloïse et Abélard, chacune peut-être située derrière un NAT, vont utiliser STUN pour découvrir s'il y a un NAT entre elles (sinon, la communication peut se faire normalement) et, s'il y a un NAT, s'il se comporte « bien » (tel que défini dans les RFC 4787 et RFC 5382). Dans ce dernier cas, STUN seul peut suffire, en informant les machines de leur adresse extérieure et en ouvrant, par effet de bord, un petit trou dans le routeur pour permettre aux paquets entrants de passer.

Mais, parfois, le NAT ne se comporte pas bien, par exemple parce qu'il a le comportement « address-dependent mapping » (RFC 4787, section 4.1). Dans ce cas, il n'existe aucune solution permettant le transport direct des données entre Héloïse et Abélard. La solution utilisée par tous les systèmes pair-à-pair, par exemple en téléphonie sur Internet, est de passer par un relais. Normalement, le serveur STUN ne sert qu'à un petit nombre de paquets, ceux de la signalisation et les données elles-mêmes (ce qui, en téléphonie ou en vidéo sur IP, peut représenter un très gros volume) vont directement entre Héloïse et Abélard. Avec TURN, le serveur STUN devient un relais, qui transmet les paquets de données. turn

TURN représente donc une charge beaucoup plus lourde pour le serveur, et c'est pour cela que cette option est restreinte au dernier recours, au cas où on ne peut pas faire autrement. Ainsi, un protocole comme ICE (RFC 8445) donnera systématiquement la préférence la plus basse à TURN. De même, le serveur TURN procédera toujours à une authentification de son client, car il ne peut pas accepter d'assurer un tel travail pour des inconnus (l'authentification - fondée sur celle de STUN, RFC 8489, section 9.2 - et ses raisons sont détaillées dans la section 5). Il n'y aura donc sans doute jamais de serveur TURN complètement public mais certains services sont quand même disponibles comme celui de Viagénie.

TURN est défini comme une extension de STUN, avec de nouvelles méthodes et de nouveaux attributs (enregistrés à l'IANA). Le client TURN envoie donc une requête STUN, avec une méthode d'un type nouveau, Allocate, pour demander au serveur de se tenir prêt à relayer (les détails du mécanisme d'allocation figurent dans les sections 6 et 7). Le client est enregistré par son adresse de transport (adresse IP publique et port). Par exemple, si Héloise a pour adresse de transport locale 10.1.1.2:17240 (adresse IP du RFC 1918 et port n° 17240), et que le NAT réécrit cela en 192.0.2.1:7000, le serveur TURN (mettons qu'il écoute en 192.0.2.15) va, en réponse à la requête Allocate, lui allouer, par exemple, 192.0.2.15:9000 et c'est cette dernière adresse qu'Héloïse va devoir transmettre à Abélard pour qu'il lui envoie des paquets, par exemple RTP. Ces paquets arriveront donc au serveur TURN, qui les renverra à 192.0.2.1:7000, le routeur NAT les transmettant ensuite à 10.1.1.2:17240 (la transmission des données fait l'objet des sections 11 et 12). Pour apprendre l'adresse externe du pair, on utilise ICE ou bien un protocole de « rendez-vous » spécifique (RFC 5128.) Un exemple très détaillé d'une connexion faite avec TURN figure dans la section 20 du RFC.

Ah, et comment le serveur TURN a-t-il choisi le port 9000 ? La section 7.2 détaille les pièges à éviter, notamment pour limiter le risque de collision avec un autre processus sur la même machine, et pour éviter d'utiliser des numéros de port prévisibles par un éventuel attaquant (cf. RFC 6056).

Et pour trouver le serveur TURN à utiliser ? Il peut être marqué en dur dans l'application, mais il y a aussi la solution de découverte du RFC 8155. Pour noter l'adresse d'un serveur TURN, on peut utiliser les plans d'URI turn: et turns: du RFC 7065.

TURN fonctionne sur IPv4 et IPv6. Lorsqu'IPv4 et IPv6 sont possibles, le serveur TURN doit utiliser l'algorithme du RFC 8305, pour trouver le plus rapidement possible un chemin qui fonctionne.

TURN peut relayer de l'UDP, du TCP (section 2.1), du TLS ou du DTLS, mais le serveur TURN enverra toujours de l'UDP en sortie (une extension existe pour utiliser TCP en sortie, RFC 6062) La section 3.1 explique aussi pourquoi accepter du TCP en entrée quand seul UDP peut être transmis : la principale raison est l'existence de pare-feux qui ne laisseraient sortir que TCP. La meilleure solution, recommandée par le RFC, serait quand même qu'on laisse passer l'UDP, notamment pour WebRTC (RFC 7478, section 2.3.5.1.)

Ah, et à propos d'UDP, notre RFC recommande d'éviter la fragmentation, et donc d'envoyer vers le pair qui reçoit les données des paquets UDP suffisamment petits pour ne pas avoir besoin de la fragmentation, celle-ci n'étant pas toujours bien gérée par les middleboxes.

Les données peuvent circuler dans des messages STUN classiques (nommés Send et Data, cf. section 11) ou bien dans des canaux virtuels (channels, sortes de sous-connexions, section 12) qui permettent d'éviter de transmettre les en-têtes STUN à chaque envoi de données.

Enfin, la section 21, très détaillée, note également que TURN ne peut pas être utilisé pour contourner la politique de sécurité : l'allocation ne se fait que pour une adresse IP d'un correspondant particulier (Abélard), TURN ne permet pas à Héloïse de faire tourner un serveur. Ce point permet de rassurer les administrateurs de pare-feux et de leur demander de ne pas bloquer TURN.

Autre point important de cette section sur la sécurité : comme certains messages ne sont pas authentifiés, un méchant peut toujours envoyer au client des messages qui semblent venir du serveur et réciproquement. Le problème existe, mais c'est un problème plus général d'IP. TURN ne le résout pas mais ne l'aggrave pas (section 21.1.4). Pour le cas du multimédia, on peut par exemple utiliser SRTP (RFC 3711) pour empêcher cette attaque.

Comme TURN relaie les paquets, au lieu de simplement les router, l'adresse IP source va identifier le serveur TURN et pas le vrai expéditeur. Un méchant pourrait donc être tenté d'utiliser TURN pour se cacher. Il peut donc être utile que le serveur TURN enregistre les données comme l'adresse IP et le port de ses clients, pour permettre des analyses a posteriori.

Une question intéressante est celle du traitement des en-têtes IP (voir la 3.6). TURN travaille dans la couche 7, il n'est pas un « routeur virtuel » mais un relais applicatif. En conséquence, il ne préserve pas forcément des en-têtes comme ECN ou comme le TTL. D'ailleurs, un serveur TURN tournant comme une application sans privilèges particuliers n'a pas forcément accès aux valeurs de l'en-tête IP. Tout cela permet son déploiement sur des systèmes d'exploitation quelconque, où il n'est pas forcément facile de changer ces en-têtes. Pour la même raison, la découverte traditionnelle de MTU (RFC 1191) à travers TURN ne marche donc pas.

À propos d'implémentations, il existe plusieurs mises en œuvre libres de TURN, comme turnserver, CoTurn, Restund ou Pion.

Les changements depuis les RFC précédents, notamment le RFC 5766, sont résumés dans les sections 24 et 25 :

  • Notre RFC intègre le RFC 6156, qui ajoutait IPv6 à TURN. Le client peut spécifier la version d'IP souhaitée, avec le nouvel attribut REQUESTED-ADDRESS-FAMILY et il y a de nouveaux codes d'erreur comme 440 ou 443,
  • TURN peut maintenant accepter du DTLS en entrée,
  • La découverte du serveur (RFC 8155) et les plans d'URI turn: et turns: (RFC 7065) ont été intégrés,
  • TURN relaie désormais l'ICMP.

Téléchargez le RFC 8656


L'article seul

RFC 8489: Session Traversal Utilities for NAT (STUN)

Date de publication du RFC : Février 2020
Auteur(s) du RFC : M. Petit-Huguenin (Impedance Mismatch), G. Salgueiro (Cisco), J. Rosenberg (Five9), D. Wing, R. Mahy, P. Matthews (Nokia)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF tram
Première rédaction de cet article le 23 février 2020


Le NAT a toujours été une des plaies de l'Internet, entre autres parce qu'il perturbe les applications qui veulent transmettre une référence à leur adresse IP. STUN, décrit dans ce RFC, est un des protocoles qui permet de limiter les dégâts. (Il s'agit ici d'une mise à jour du RFC 5389.)

Pour plusieurs raisons, dont le manque d'adresses IPv4, de nombreuses machines sont connectées à l'Internet derrière un routeur qui fait du NAT. Leur adresse étant alors privée, elles ne peuvent pas la transmettre à l'extérieur, ce qui est une gêne considérable pour tous les protocoles qui reposent sur la référence à des adresses IP, comme SIP. SIP lui-même (RFC 3261) marche à travers le NAT mais les données audio ou vidéo transmises (typiquement par RTP) le sont à une adresse IP que l'appelant donne à l'appelé et, si cette adresse est privée, le flux multi-média n'arrivera jamais.

La bonne solution serait de déployer IPv6, qui fournit des adresses en quantité illimitée, ou à la rigueur de permettre un meilleur contrôle du routeur NAT avec PCP (RFC 6887) mais, en attendant, STUN est une solution simple et qui marche souvent.

STUN s'inscrit donc dans la catégorie des protocoles de « réparation » du NAT, catégorie décrite dans le RFC 3424.

STUN résout partiellement le problème des NAT de la manière suivante : un serveur STUN doit être installé quelque part sur l'Internet public (il existe des serveurs STUN publics) et reçoit des demandes envoyées en UDP (ou TCP, voir sections 6.2.2 et 6.2.3, ou encore TLS ou DTLS) au port 3478. Le serveur STUN peut alors connaitre l'adresse publique, celle mise par le routeur NAT et, en répondant au client, il pourra informer celui-ci « Voilà à quoi tes paquets ressemblent, vus de l'extérieur ». stun

Le nom du serveur STUN est typiquement configuré dans le client, puis le serveur recherché dans le DNS via les enregistrements SRV (RFC 2782), comme détaillé dans la section 8. (Le traditionnel client Unix en ligne de commande, montré plus loin, ne connait pas les SRV.)

Le principe est simple, mais le RFC est plus compliqué que cela, notamment en raison des problèmes de sécurité (la section 16 du RFC est très détaillée sur ce point). Par exemple, le client STUN doit en fait commencer par une connexion TCP pour obtenir un mot de passe temporaire. (D'autres méthodes d'authentification sont possibles.)

Lorsque STUN fonctionne sur UDP, ou bien sur DTLS, le client STUN doit également être préparé à rémettre les paquets qui seraient perdus (section 6.2.1).

Un autre problème est qu'il y a en fait plusieurs sortes de NAT (voir par exemple le RFC 2663). Par exemple, certains routeurs NAT (Symmetric NAT pour le RFC 3489) n'attribuent pas l'adresse externe uniquement en fonction de la source mais aussi en fonction de la destination. Ceux-ci ne fonctionnent pas avec STUN, qui a besoin de NAT cone, c'est-à-dire où les paquets d'une même machine auront toujours la même adresse IP externe.

Voici une démonstration d'un client STUN (assez ancien mais qui marche) qui, en se connectant à un serveur STUN public va apprendre son adresse IP publique, et le port, les deux ensemble formant l'adresse de transport (cf. section 4) :

% ifconfig -a
hme0: [...] inet 172.19.1.2
(Adresse privée, probablement NATée...)

% stun stun.1und1.de -v
STUN client version 0.97
...
MappedAddress = 192.0.2.29:30189
SourceAddress = 212.227.67.33:3478
ChangedAddress = 212.227.67.34:3479
Unknown attribute: 32800
ServerName = Vovida.org 0.96
...
Primary: Independent Mapping, Port Dependent Filter, preserves ports, no hairpin	
...
(Mon adresse telle que vue de l'extérieur est donc 192.0.2.29, à noter que le terme
MappedAddress n'est plus utilisé, le RFC parle de ReflexiveAddress.)

Une fois l'adresse extérieure détectée, tout n'est pas terminé car rien n'indique, par exemple, que les paquets vont effectivement passer. C'est pour cela que la section 13 insiste que STUN n'est qu'un outil, devant s'insérer dans une solution plus globale, comme ICE (RFC 8445). À lui seul, STUN ne permet pas la traversée de tous les NAT. La section 13 décrit en détail ce concept d'utilisation de STUN et les règles que doivent suivre les protocoles qui utilisent STUN.

La section 5 décrit le format des paquets. Un paquet STUN doit comprendre l'indication d'une méthode, qui indique le genre de services que désire le client. Notre RFC 8489 ne décrit qu'une seule méthode, Binding, qui permet d'obtenir son adresse IP extérieure mais TURN (RFC 8656), par exemple, en définit d'autres. Après la méthode et un identificateur de transaction (qui sert au serveur STUN à séparer ses clients), suivent les attributs, encodés en TLV (la liste des attributs figure en section 14). Les numéros des attributs sont compris entre 0x0000 et 0x7FFF s'ils doivent être reconnus par le serveur (autrement, la requête est rejetée) et entre 0x8000 et 0xFFFF si leur compréhension est facultative (cette notion d'attributs obligatoires ou facultatifs facilite les évolutions ultérieures du protocole). Il y a aussi un magic cookie, une valeur fixe (0x2112A442) qui sert à reconnaitre les agents STUN conformes (il n'existait pas dans les vieilles versions de STUN).

La section 19 de notre RFC résume les changements faits depuis le prédécesseur, le RFC 5389. Rien de bien crucial, d'autant plus que la plupart de ces changements sont l'intégration de RFC qui avaient étendu le protocole STUN après la parution du RFC 5389 :

  • DTLS est désormais intégré (RFC 6347),
  • L'algorithmes pour calculer le délai avant retransmission a été modifié suivant le RFC 6298,
  • Les URI du RFC 7064 sont désormais inclus,
  • SHA-256 et des nouveaux algorithmes pour TLS arrivent,
  • Les identificateurs et mots de passe peuvent être en Unicode (RFC 8265),
  • Possibilité d'anonymat pour les identificateurs (ce qui a nécessité des nouvelles règles dans le numnique envoyé par le serveur, pour éviter les attaques par repli),
  • Ajout de l'attribut ALTERNATE-DOMAIN, pour indiquer que le serveur proposé en alternative peut avoir un autre nom,
  • Et pour les programmeurs, des vecteurs de test en annexe B (venus du RFC 5769).

Il existe de nombreux logiciels clients et serveurs pour STUN (mais pas forcément déjà conforme aux légers changements de ce RFC). Le client est en général embarqué dans une application qui a besoin de contourner le NAT, par exemple un softphone, ou bien un navigateur Web qui fait du WebRTC. On peut citer :

Et si vous cherchez une liste de serveurs STUN publics, il y a celle-ci.


Téléchargez le RFC 8489


L'article seul

À propos du débat sur la 5G

Première rédaction de cet article le 19 février 2020


Il y à en ce moment en France, et dans d'autres pays, un débat vigoureux sur le déploiement de la 5G. Je vous rassure, je ne vais pas donner un avis définitif sur tous les aspects de ce débat, mais il me semble que plusieurs points importants n'ont que peu ou pas été abordés.

5G est un terme qui regroupe un ensemble de techniques et de normes pour les télécommunications mobiles, techniques qui peuvent être déployées ensemble ou séparément. Les promoteurs de la 5G promettent des miracles, mais il y a des opposants.

D'abord, je voudrais dire que ce débat, cette friction, est une excellente chose. (Et c'est relativement récent.) Les techniques jouent un rôle crucial dans notre société, les techniques de communication sont partout et influencent fortement ce que nous pouvons faire ou ne pas faire, et il est donc très bien que les citoyens et citoyennes soient informés qu'un désaccord existe. Déployer ou pas la 5G est en effet un choix politique (politique au sens « concerne la vie de la société », évidemment pas au sens « qui sera ministre des Déclarations Ridicules à la Télé ».) Il n'y a pas de loi physique (ou sociale) qui ferait du déploiement de la 5G un événement inéluctable, comme la chute des pommes ou comme l'explosion de Bételgeuse. « On n'arrête pas le progrès » est une phrase idiote, d'abord parce que toute nouvelle technique n'est pas forcément un progrès (ce peut être une régression) et ensuite parce que, justement, le progrès se décide. C'est le cas pour l'invention (ce qui se fait dans les labos, et qui dépend des thèmes à la mode, et de leur financement) et encore plus pour l'innovation (le déploiement hors des labos, qui nécessite des investissements lourds et donc des décisions difficiles.)

Donc, le débat actuel sur la 5G est une bonne chose. Mais sur quoi porte-t-il ? Les partisans de la 5G mettent en avant :

  • Les performances accrues, en capacité et surtout en latence,
  • La possibilité de nouveaux services, par exemple pour les objets connectés, via des nouveautés comme une qualité de service garantie.

Les opposants critiquent (j'ai essayé de faire une liste exhaustive, mais il faut bien noter que tous les opposants ne partagent pas tous ces arguments) :

  • Les risques d'espionnage liés au fait que les équipements 5G sont souvent fabriqués par des entreprises chinoises, notamment Huawei, qui fait en ce moment l'objet d'une campagne menée par le gouvernement des États-Unis,
  • Plus généralement, le risque de perte de souveraineté liés à cette dépendance vis-à-vis d'un fournisseur chinois,
  • Les problèmes de santé liés au rayonnement électromagnétique,
  • Les problèmes écologiques liés à la consommation énergétique des nombreux équipements nécessaires (puisque la portée de la 5G est inférieure, il faudra davantage de stations de base),
  • Lié au précédent, le problème philosophique du « progrès ». Voulons-nous de cette course à la communication toujours plus rapide ?

Ah et puis il parait que la 5G peut aussi poser des problèmes aux prévisions météo mais je n'ai pas creusé la question.

Je ne vais pas faire un dossier complet sur la 5G, sujet sur lequel je ne suis pas un expert. Mais je voudrais mettre en avant quelques points qui, il me semble, ont été un peu oubliés dans le débat. Je vais suivre l'ordre des arguments donnés ci-dessus, en commençant par les arguments « pour ».

Sur les performances, il est important de rappeler que le vécu d'un utilisateur ou d'une utilisatrice ne dépend pas que de la 5G. Quand M. Michu ou Mme Toutlemonde, dans la rue, regarde le site Web de Wikipédia, le résultat final, en terme de performances, dépend de toute une chaîne, les performances des deux ordinateurs aux extrémités, celles du réseau mobile, mais aussi celles de tous les liens Internet entre M. Michu et Wikipédia. Le goulet d'étranglement, le point le moins performant et qui limite la performance globale, n'est pas forcément le réseau mobile. Par exemple, les sites Web modernes nécessitent souvent des calculs complexes pour leur affichage, et la rapidité de chargement des fichiers n'y changera rien. Dire « la 5G permettra d'accélérer la visualisation des pages Web » est au mieux une simplification, au pire un mensonge publicitaire.

Et puis ces performances mirifiques sont très théoriques : elles reposent sur des comparaisons faites en laboratoire, or les ondes sont très sensibles à l'environnement extérieur, et la réalité ne sera donc jamais aussi belle que la théorie. Regardez simplement comment, aujoud'hui, vous n'avez pas la 4G partout et que votre ordiphone se rabat souvent en 3G voire moins.

Concernant les services nouveaux, on a entendu beaucoup d'arguments marketing. Le record étant sans doute la promesse de pouvoir faire de la téléchirurgie via la 5G car elle offrirait « des garanties de service ». La réalité est moins rose : aucune technique ne peut promettre qu'il n'y aura jamais de panne. Faire de la téléchirurgie sans avoir de solution de secours (par exemple un autre chirurgien sur place) serait criminel, 5G ou pas 5G.

Il faut aussi rajouter que ces nouveaux services ne sont pas forcément quelque chose de positif. Globalement, la 5G est surtout poussée par les opérateurs de télécommunications traditionnels, qui sont historiquement des adversaires de la neutralité du réseau. La 5G, par la virtualisation du réseau, permettrait plus facilement de faire des services différenciés, donc probablement de violer ladite neutralité.

Et les arguments des opposants, ou des gens critiques vis-à-vis de la 5G ? Commençons par le risque d'espionnage, souvent mentionné, et qui a mené à une guerre commerciale entre le gouvernement étatsunien et Huawei. Grosso-modo, disent les inquiets, si on laisse faire, une grande partie des équipements 5G installés seront fabriqués par Huawei (puisque ce sont les moins chers), et Huawei aura donc la possibilité technique d'espionner tout le trafic. Le problème de cet argument, c'est que ce n'est pas mieux avec les fournisseurs non-chinois. Il faudrait être naïf pour croire que seul Huawei a des portes dérobées. D'autre part, le modèle de menace de l'Internet a toujours été qu'on ne pouvait pas faire confiance au réseau, car on ne peut pas évaluer la totalité de la chaîne. Le RFC 3552 en déduit logiquement que la sécurité doit être de bout en bout, donc qu'il faut chiffrer la communication de bout en bout, 5G ou pas, Huawei ou pas. (Rappelez-vous que le lien 5G n'est qu'une partie de la chaîne qui connecte deux personnes qui communiquent et qu'analyser la sécurité en ne regardant que la 5G serait une sérieuse erreur.) Évidemment, ce point de vue comme quoi le chiffrement de bout en bout est indispensable n'est pas partagé par les opérateurs de télécommunications, qui voudraient bien continuer à surveiller le trafic (cf. RFC 8404.)

D'autre part, il n'y a pas que le fournisseur de matériel, il y a aussi les boites qui gèrent le réseau, et, là, la sous-traitance est fréquente, et la perte de compétence inquiétante, comme le démontre l'excellent article de Bert Hubert.

Si le chiffrement protège bien contre la surveillance, il ne protège pas contre les dénis de service. Que se passe-t-il si un ordre venu de Beijing bloque subitement toutes les commmunications ? Le problème est réel (mais bien moins cité que celui de confidentialité, pourtant plus facile à résoudre.) Pour ce problème, en effet, le choix du fournisseur des équipements 5G est crucial mais, comme on l'a dit, les Chinois n'ont pas le monopole des portes dérobées. La solution ici, nécessite au minimum de n'utiliser que du logiciel libre dans les équipements de communication, afin de pouvoir les évaluer, mais on en est loin.

Et les conséquences sur la santé ? La question est très difficile à analyser car on a peu d'études scientifiques sérieuses sur la question. (PS : si vous avez une bonne bibliographie sur ce sujet, n'hésitez pas à me la communiquer. Il y a entre autre cette étude de l'IARC et cette synthèse des Décodeurs du Monde.) Il ne fait aucun doute que les ondes électromagnétiques peuvent être dangereuses (exposez-vous au soleil au Sahara sans protection et vous constaterez douloureusement que les ondes font parfois mal.) La question est de savoir dans quelles conditions (fréquence, puissance, durée d'exposition, etc.) Si les ondes ont vraiment un effet sur la santé, cet effet dépend forcément de ces conditions, et les discours anti-ondes sont toujours muets sur ce point. La recherche en ce domaine est d'autant plus difficile qu'il est possible que les éventuels effets médicaux soient à long terme, surtout pour des doses faibles. Et le débat est brouillé par des « anti-ondes » qui racontent n'importe quoi sur le Web, parfois relayés par des médias peu rigoureux, et par des commerçants charlatans qui cherchent à placer des remèdes miracles. On est rarement dans la rationalité ici, les effets, pourtant, eux, bien connus, de la pollution due au trafic routier ne suscitent pas la même mobilisation que « les ondes ».

Voyons maintenant l'argument écologique. Les fréquences utilisées par la 5G portent moins loin, il va falloir davantage de stations de base (ce qui va poser d'intéressants problèmes de main d'œuvre), donc a priori davantage de consommation énergétique. Mais en contrepartie, la puissance dépassée par chaque base sera inférieure, donc les partisans de la 5G avancent qu'elle pourrait diminuer la facture énergétique. J'avoue ne pas connaitre les chiffres exacts. (Là encore, si vous avez des études sérieuses, je prends. Je connais déjà cet exposé détaillé de la Commission Européenne et l'étude de Jancovici souvent citée.) Je vais donc passer mon tour sur ce point. Notez que, comme souvent dans les débats techniques, on voit parfois passer des erreurs qui font douter de la qualité générale du texte. Par exemple dans ce document de la GSMA, on lit « can potentially increase cell energy consumption from 5-7 kW per 4G site per month to over 20 kW », mélangeant puissance (en watts) et énergie (en joules ou à la rigueur en watts*heures.)

Notez aussi qu'une conséquence du déploiement de la 5G serait sans doute le grand remplacement des terminaux (les ordiphones) et que cela a un coût (les équipements informatiques ont une empreinte écologique bien plus forte lors de la fabrication que lors de l'utilisation. Éteindre l'appareil qu'on n'utilise pas, c'est bien, ne pas le remplacer trop vite, c'est mieux.)

Il reste un dernier argument contre le déploiement de la 5G, l'argument qu'on pourrait appeler « philosophique ». En gros, en a-t-on besoin ? Le débat ne peut évidemment pas être tranché par la technique ou par les experts. D'un côté, on peut dire que l'augmentation des performances (dont on a vu qu'elle n'était pas garantie) est un but en soi. Après tout, chaque fois qu'on a augmenté les performances des ordinateurs et des réseaux, on a trouvé des usages (pas forcément souhaitables…) à cette augmentation. D'un autre côté, il n'y a pas de loi fondamentale disant que cela devrait continuer éternellement. Contrairement aux prévisions de la science-fiction, voitures volantes et avions à propulsion nucléaire ne se sont pas généralisés. Donc, le « progrès » n'est pas automatique. La question de fond est « qui va décider ? » Comment se font les choix qui impactent toute notre société ? Qui a décidé de déployer la 5G, et pour quels intérêts ?


L'article seul

RFC 8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility

Date de publication du RFC : Janvier 2020
Auteur(s) du RFC : D. Benjamin (Google)
Pour information
Réalisé dans le cadre du groupe de travail IETF tls
Première rédaction de cet article le 29 janvier 2020


Ce nouveau RFC s'attaque à un problème fréquent dans l'Internet : des programmeurs paresseux, incompétents ou pressés par les délais imposés mettent en œuvre un protocole normalisé (comme TLS) sans bien lire les normes, et notamment sans tenir compter des variations que la norme permet. Ils programment rapidement, testent avec une ou deux implémentations trouvées et, si ça marche, en déduisent que c'est bon. Mais dès qu'une autre implémentation introduit des variantes, par exemple un paramètre optionnel et qui n'était pas utilisé avant, la bogue se révèle. Le cas s'est produit de nombreuses fois. Notre RFC propose une solution disruptive : utiliser délibérément, et au hasard, plein de variantes d'un protocole, de façon à détecter rapidement les programmes écrits avec les pieds. C'est le principe de GREASE (Generate Random Extensions And Sustain Extensibility), la graisse qu'on va mettre dans les rouages de l'Internet pour que ça glisse mieux. Ce RFC 8701 commence par appliquer ce principe à TLS.

Le problème n'est évidemment pas spécifique à TLS, on l'a vu arriver aussi dans BGP lorsqu'on s'est aperçu que la simple annonce d'un attribut BGP inconnu pouvait planter les routeurs Cisco. Là aussi, le « graissage » (tester systématiquement des valeurs non allouées pour les différents paramètres, pour vérifier que cela ne plante rien) aurait bien aidé. D'où le projet « Use it or lose it », décrit dans l'Internet-Draft draft-iab-use-it-or-lose-it dont GREASE est un cas particulier. Le draft draft-iab-use-it-or-lose-it analyse le problème des options non utilisées et recommande de les utiliser systématiquement, pour habituer les logiciels à voir ces options.

Le principe de GREASE (Generate Random Extensions And Sustain Extensibility) est donc de faire en sorte que clients et serveurs TLS (RFC 8446) annoncent, pour différents paramètres de la connexion, des valeurs qui ne correspondent à rien. Ainsi, les middleboxes boguées, installées au milieu de la communication parce que le commercial qui les vendait était convaincant, seront vite détectées, au lieu que le problème demeure dormant pendant des années et soit subitement révélé le jour où on essaie des valeurs légales mais nouvelles, comme dans le cas de l'attribut 99.

Qu'est-ce qui est variable dans TLS ? Beaucoup de choses, comme la liste des algorithmes de cryptographie ou comme les extensions. Dans TLS, le client annonce ce qu'il sait faire, et le serveur sélectionne dans ce choix (RFC 8446, section 4.1.3). Voici un exemple vu par tshark, d'abord le message du client (Client Hello), puis la réponse du serveur (Server Hello) :

Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Handshake Protocol: Client Hello
            Version: TLS 1.2 (0x0303)
            Cipher Suites (28 suites)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                ...
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    ...
            Extension: SessionTicket TLS (len=0)
                Type: SessionTicket TLS (35)
            Extension: encrypt_then_mac (len=0)
                Type: encrypt_then_mac (22)
            Extension: signature_algorithms (len=48)
                Type: signature_algorithms (13)
                Signature Hash Algorithms (23 algorithms)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                        ...

			
Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Server Hello
        Content Type: Handshake (22)
        Version: TLS 1.2 (0x0303)
        Handshake Protocol: Server Hello
            Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
            Compression Method: null (0)
            Extensions Length: 13
            Extension: renegotiation_info (len=1)
                Type: renegotiation_info (65281)
                Length: 1
                Renegotiation Info extension
                    Renegotiation info extension length: 0          
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
            ...
    

Le client propose de nombreux algorithmes de cryptographie, comme TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, et plusieurs extensions comme le format pour les courbes elliptiques (normalisé dans le RFC 8422), les tickets du RFC 5077, le chiffrement avant le MAC du RFC 7366 et des algorithmes de signature. Le serveur choisit l'algorithme de chiffrement TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, accepte l'extension sur le format des courbes elliptiques, et, puisque le client était d'accord (via l'indication d'un algorithme de chiffrement spécial), le serveur utilise l'extension de renégociation.

Les valeurs inconnues (par exemple une nouvelle extension) doivent être ignorées (RFC 8446, section 4.1.2). Si ce n'était pas le cas, si une valeur inconnue plantait la partie située en face, il ne serait pas possible d'introduire de nouveaux algorithmes ou de nouvelles extensions, en raison des déploiements existants. Prenons les algorithmes de cryptographie, enregistrés à l'IANA. Si un nouvel algorithme apparait, et reçoit une valeur, comment vont réagir, non seulement les pairs avec qui on communique en TLS, mais également tous ces boitiers intermédiaires installés souvent sans raison sérieuse, et pour lesquels il n'existe pas de mécanisme pratique de remontée des problèmes ? Si leurs programmeurs avaient lu la norme, ils devraient ignorer ce nouvel algorithme, mais on constate qu'en pratique, ce n'est souvent pas le cas, ce qui rend difficile l'introduction de nouveaux algorithmes. Dans le pire des cas, le boitier intermédiaire jette les paquets portant les valeurs inconnues, sans aucun message, rendant le déboguage très difficile.

D'où les métaphores mécaniques : dans l'Internet d'aujourd'hui, bien des équipements sur le réseau sont rouillés, et il faut les graisser, en faisant travailler les parties qui ne sont normalement pas testées. C'est le principe de GREASE que d'envoyer des valeurs inconnues pour certains paramètres, dans l'espoir de forcer les mises en œuvre de TLS, surtout celles dans les boitiers intermédiaires, à s'adapter. Une méthode darwinienne, en somme.

La section 2 de notre RFC indique les valeurs choisies pour ces annonces. C'est délibérement qu'elles ne sont pas contiguës, pour limiter le risque que des programmeurs paresseux ne testent simplement si une valeur est incluse dans tel intervalle. Il y a un jeu de valeurs pour les algorithmes de cryptographie et les identificateurs ALPN (RFC 7301), un pour les extensions, un pour les versions de TLS, etc. Toutes sont enregistrées à l'IANA, dans le registre respectif. Par exemple, pour les extensions TLS, (cf. leur liste), les valeurs, 2570, 6682, 10794 et plusieurs autres sont réservées pour le graissage. (Il fallait les réserver pour éviter qu'une future extension TLS ne reçoive le même numéro, ce qui aurait cassé la compatibilité avec les logiciels GREASE.)

Une fois ces valeurs réservées par notre RFC, le client TLS peut, au hasard, ajouter ces valeurs dans, par exemple, la liste des algorithmes de cryptographie qu'il gère, ou la liste des extensions qu'il propose. Si jamais le serveur les accepte (dans son ServerHello), le client doit rejeter la connexion ; le but de ces valeurs était de tester les logiciels, elles ne doivent jamais être sélectionnées. Notez que c'est le comportement normal d'un client TLS d'aujourd'hui de refuser proprement les valeurs inconnues. De même, un serveur normal d'aujourd'hui va ignorer ces valeurs inconnues (et donc ne jamais les sélectionner). Si tout le monde suit la norme, l'introduction des valeurs GREASE ne va rien changer. Les règles de la section 3 ne sont qu'un rappel de règles TLS qui ont toujours existé.

La section 4 de notre RFC traite le cas un peu plus difficile où le serveur propose et le client accepte. C'est par exemple ce qui arrive quand le serveur demande au client de s'authentifier, en envoyant un CertificateRequest. Le serveur peut là aussi utiliser GREASE et indiquer des extensions ou des algorithmes de signature inconnus, et le client doit les ignorer (sinon, si le client sélectionne ces valeurs, le serveur doit rejeter un tel choix).

La section 5 du RFC précise dans quels cas utiliser les valeurs GREASE et lesquelles. Le but étant de révéler les problèmes, le RFC recommande de choisir les valeurs aléatoirement. (Si un programme envoyait toujours la même valeur GREASE, il y aurait un risque que des programmes en face ignorent spécifiquement cette valeur, alors qu'il faut ignorer toutes les valeurs inconnues.) Par contre, pour un même partenaire TLS, il vaut mieux un certain déterminisme, sinon les problèmes seront difficiles à déboguer (parfois, ça marche, parfois, ça ne marche pas…)

Enfin, la section 7 du RFC discute des conséquences de l'absence de graissage sur la sécurité. Si certaines mises en œuvre de TLS résistent mal aux options inconnues, cela peut encourager le repli, c'est-à-dire à réessayer sans les options. Ainsi, un attaquant actif pourrait facilement forcer une machine à ne pas utiliser des options qui rendraient des attaques ultérieures plus compliquées. Les attaques par repli étant particulièrement dangereuses, il est important de ne pas se replier, et donc de s'assurer qu'on peut réellement utiliser toutes les possibilités du protocole. Cela veut dire entre autres que, si une machine TLS utilisant GREASE a du mal à se connecter, elle ne devrait pas essayer sans GREASE : cela annnulerait tous les bénéfices qu'on attend du graissage. Le principe de robustesse est mauvais pour la sécurité.

À noter que Chrome a déjà mis en œuvre ce principe, et que ça semble bien fonctionner. L'article « HTTPS : de SSL à TLS 1.3 », surtout consacré à la version 1.3 de TLS, montre à quoi ressemble les options GREASE pour Wireshark (« Unknown »).

À noter qu'un concept équivalent existe dans le futur HTTP/3, Reserved Stream Types et Reserved Frame Types. Pour HTTP/2 (RFC 7540), où les trames de type inconnu devraient être ignorées, l'expérience a déjà prouvé qu'elles ne l'étaient pas toujours.


Téléchargez le RFC 8701


L'article seul

Google inverse les noms de domaines

Première rédaction de cet article le 16 janvier 2020
Dernière mise à jour le 20 janvier 2020


Le 16 janvier au matin, il y avait une bogue amusante (qui a duré quelques jours) dans le moteur de recherche Google. Les noms de domaine étaient dans certains cas inversés, plus exactement mélangés dans l'affichage.

Quand on cherche quelque chose dans ce moteur de recherche (sur une machine de bureau, car c'est différent sur les mobiles), Google affiche pour chaque résultat :

  • L'endroit où a été trouvé le résultat, sous une forme vaguement inspirée des breadcrumbs (Google affichait autrefois un URL, ce qui était plus intelligent mais a sans doute été changé sur demande du marketing car « M. Michu ne comprend rien aux URL » et Google n'aime pas éduquer les utilisateurs),
  • Le titre de la page, qui est un lien hypertexte (en promenant son pointeur dessus, on voit l'URL s'afficher en bas à gauche, ce qui est utile pour savoir où on va avant d'y foncer),
  • La date et un résumé.

On voit ici un exemple : google-recherche-echos.png

L'endroit de la page est fabriqué à partir de l'URL mais n'est pas un URL. Il commence par un nom de domaine et se continue par un chemin dans le site. Mais ce qui est amusant est que cet affichage est bogué. Dans certains cas, le nom de domaine est mélangé. L'exemple précédent est correct mais, si je cherche le département de physique de l'Université de Cambridge : google-recherche-cavendish.png

Le vrai nom de domaine est www.phy.cam.ac.uk mais Google affiche phy.www.cam.ac.uk. Autre exemple, avec le gouverneur de Californie : google-recherche-gouverneur.png

Ici, le vrai nom était www.gov.ca.gov mais Google affiche gov.www.ca.gov. L'URL vers lequel pointe le résultat est néanmoins correct, comme on le voit avec cet autre exemple (Firefox affiche l'URL de destination en bas à gauche) : google-recherche-escargot.png

Pourquoi cette bogue ? La raison fondamentale est sans doute une incompréhension des noms de domaine, notamment du fait que le nombre de composants d'un nom soit quelconque (contrairement à une légende répandue.) Vous noterez que les seuls noms ainsi massacrés sont des noms ayant plus de trois composants. Mais c'est curieux de la part de Google, dont les services ont d'habitude très peu de bogues.

Mais on peut aussi voir dans cette bogue le résultat d'une mentalité très fréquente dans le Web, et particulièrement chez Google, comme quoi les noms de domaine ne sont pas une information pertinente et peuvent être cachés, ou massacrés, sans problème.

Merci à Jean-Philippe Pick pour avoir noté le phénomène. Le problème a été réparé le 19 janvier, sans nouvelles de Google ou sans information publiée.


L'article seul

Fiche de lecture : Unix: A history and a Memoir

Auteur(s) du livre : Brian Kernighan
Éditeur : Kindle Direct Publishing
9781695978553
Publié en 2020
Première rédaction de cet article le 14 janvier 2020


Ce livre est une histoire du système d'exploitation Unix, par une des personnes qui ont suivi l'aventure d'Unix depuis le début, Brian Kernighan.

D'abord, Kernighan écrit très bien, il a un vrai talent pour tout expliquer, y compris les questions informatiques complexes (comme le fameux tube, une des inventions les plus marquantes dans Unix). Ensuite, il a lui-même travaillé au développement d'Unix (il a notamment participé à la création du langage C, dans lequel Unix a été rapidement réécrit, après ses débuts en langage d'assemblage.) Cela lui permet de faire revivre une époque aujourd'hui bien distante.

Il y a fort longtemps, dans un pays lointain, pas du tout dans la Silicon Valley mais à Murray Hill, un gentil roi, la compagnie AT&T avait installé son service de recherche et développement, les Bell Labs. Les Bell Labs (qui existent encore aujourd'hui sous ce nom mais ne sont plus que l'ombre de ce qu'ils étaient) sont devenus une légende de la physique, de la mathématique et de l'informatique, avec pas moins de neuf prix Nobel obtenus (non, l'invention d'Unix n'a pas été récompensée par un prix Nobel.)

C'est dans ce pays merveilleux que deux informaticiens, Ken Thompson et Dennis Ritchie, après le semi-échec du projet Multics, et le retrait des Bell Labs de ce travail, se sont attaqués à une de ces tâches où tous les gens raisonnables vous disent « c'est complèment irréaliste, jeune homme, vous n'êtes pas sérieux ». Ils ont écrit un système d'exploitation et Unix était né, prêt à conquérir le monde. Ce livre est l'histoire d'Unix. Elle est pleine de rebondissements, de crises, de discussions.

Pour rappeler l'importance d'Unix, il faut se souvenir que beaucoup de choses qui nous semblent aujourd'hui évidentes en informatique ne l'étaient pas à l'époque. Par exemple, la grande majorité des systèmes d'exploitation imposaient de fixer une taille maximale à un fichier avant sa création. Si elle était trop faible, on devait re-créer un autre fichier et copier les données. Si cette taille était trop élevée, on gaspillait de l'espace disque. Unix a mis fin à cela et, aujourd'hui, cela va de soi. De même Unix a unifié les différents types de fichiers. Avant Unix, plusieurs systèmes d'exploitation avaient des commandes différentes pour copier un fichier contenant un programme Cobol et un fichier de données !

L'atmosphère très spéciale des Bell Labs, informelle, avec peu de bureaucratie, un accent mis sur les compétences et pas sur les titres (une méritocratie, une vraie) a beaucoup aidé à développer un système d'exploitation à succès. Kernighan raconte beaucoup d'histoires amusantes, mais consacre également du temps à l'analyse des facteurs importants dans le succès des Bell Labs. Il insiste sur les facteurs physiques (« geography is destiny ») : tout le monde sur le même site, et un mélange de bureaux fermés (même les stagiaires avaient leur propre bureau fermé, loin de l'open space bruyant empêchant la concentration) et de pièces communes où on pouvait aller quand on voulait, discuter et interagir avec les autres. Les Bell Labs ont été un cas peut-être unique, où toutes les conditions étaient réunies au même endroit, pour produire une étonnante quantité d'inventions géniales. Le tout était aidé par un financement stable et un management qui laissait les chercheurs tranquilles. Il est curieux (et triste) de noter qu'une entreprise 100 % capitaliste comme AT&T donnait plus de liberté et de stabilité financière à ses chercheurs qu'une université publique d'aujourd'hui, où les chercheurs doivent passer tout leur temps en travail administratif, en évaluation, et en recherche d'argent.

Aux Bell Labs, il était fréquent pour un chercheur de travailler sur plusieurs sujets de front et le livre de Kernighan donne une petite idée de la variété des sujets. Anecdote personnelle : j'ai utilisé (très peu !) le système Ratfor que l'auteur avait écrit, quand je faisais du calcul numérique.

Une particularité d'Unix est en effet la profusion d'outils pour informaticiens qui ont été développés sur ce système. L'auteur consacre de nombreuses pages à ces outils en insistant sur le fait que le goupe Unix des Bell Labs maîtrisait toujours la théorie et la pratique. Chaque membre du groupe pouvait écrire une thèse en informatique théorique, et inventer puis programmer des outils utiles. Mais on oublie souvent que les premiers utilisateurs d'Unix n'étaient pas que des informaticiens. Le premier argument « de vente » d'Unix auprès de la direction des Bell Labs était ses capacités de… traitement de texte. Le service des brevets de Bell Labs déposait beaucoup de brevets, et leur préparation prenait un temps fou. En bons informaticiens, les auteurs d'Unix ont automatisé une grande partie des tâches, et les juristes se sont mis à préparer les demandes de brevets sur Unix…

De nos jours, on associe souvent Unix au logiciel libre, puisque Linux, FreeBSD et bien d'autres héritiers de l'Unix original sont libres. Mais à la grande époque des Bell Labs, ces considérations politiques étaient absentes. Kernighan n'en parle jamais et, au contraire, insiste sur le verrouillage de bien des innovations par des brevets. C'est en raison de la licence restrictive de l'Unix d'AT&T que des systèmes comme Linux ou FreeBSD n'ont plus une seule ligne du code original d'AT&T : il a fallu tout réécrire pour échapper aux avocats.

Kernighan ne fait pas que raconter des anecdotes édifiantes. Il corrige également quelques légendes. Par exemple, le fameux commentaire dans le code source d'Unix « You are not expected to understand this » ne veut pas du tout dire « lecteur, tu es stupide, laisse ce code aux pros » mais « il n'est pas nécessaire de comprendre ce bout de code pour comprendre le reste ».

Vous ne serez pas surpris d'apprendre que le livre a été composé sur Unix, avec groff et Ghostscript.


L'article seul

Rapport de la députée Forteza sur les technologies quantiques

Première rédaction de cet article le 12 janvier 2020


Le 9 janvier 2020, la députée Paula Forteza a rendu le rapport « Quantique : le virage technologique que la France ne ratera pas ». Quelques points sur ce rapport.

Le terme de « quantique » a un fort potentiel de hype pour les années à venir (surtout depuis l'annonce par Google de l'obtention de la suprématie quantique). Dans le contexte de la physique, il désigne quelque chose de clair (mais pas forcément de simple à comprendre !) Appliqué aux technologies, c'est plus compliqué. Et ce rapport couvre toutes les utilisations futures de la quantique, ce qui fait beaucoup. Globalement, le rapport est rigoureux sur la partie scientifique (il y a eu de bons conseillers, et ils ont été bien écoutés, donc des point délicats comme la différence entre qubits physiques et logiques, toujours oubliée par les marketeux, est bien décrite) mais plus contestable sur la partie politique. Je ne vais pas reprendre tous les points (lisez le rapport, vous ne vous ennuierez pas, et vous apprendrez des choses) mais seulement ceux qui me semblent particulièrement discutables.

Le point le plus curieux concerne la distribution quantique de clés (parfois appelée par abus de langage « cryptographique quantique »). La partie technique du rapport note à juste titre les nombreuses limitations (le rapport parle de « verrous ») de cette technique, que ses promoteurs présentent comme la solution magique à tous les problèmes de sécurité de l'Internet (ce qu'elle n'est pas). Mais la partie « propositions » du rapport oublie complètement ces limitations et assène qu'il faut mettre le paquet pour le développement de la QKD. On dirait vraiment que l'analyse de la technologie et les recommandations ont été écrites par des personnes différentes.

Le rapport est plus cohérent sur la question de la cryptographie post-quantique (cf. aussi mon exposé à pas Sage En Seine et le point de vue très différent de Renaud Lifchitz.) Encore que la partie résumée à l'attention des décideurs, comme souvent, présente le problème comme sans doute plus proche qu'il ne l'est (et propose de commencer à déployer les solutions en 2022 !) Le rapport semble pousser au déploiement immédiat d'algorithmes post-quantiques, alors qu'aucun n'est normalisé. (Et, puisqu'il s'agit d'un rapport officiel, on peut noter que le RGS, et notamment son annexe cryptographique, ne sont pas mentionnés.) Si vous voulez en savoir plus sur la cryptographie post-quantique, je vous recommande l'exposé de Magali Bardet lors de la JCSA de juillet 2019.

Ensuite, ce rapport reprend malheureusement le style de tant de rapports officiels précédents : pas d'autre proposition que de donner beaucoup d'argent à Atos ou Thales dans l'espoir que cela fera avancer les choses, meccano institutionnel (créer un comité machin), discours sur la grandeur de la France et sa maitrise de toutes les technologies et toutes les sciences, référence à la startup magique, croyance que la recherche fondamentale se pilote d'en haut (on annonce bien haut que la quantique est une priorité et paf, cela suffit à ce que les résultats arrivent), et surtout, aucune remise en cause des obstacles que rencontre actuellement la recherche. Par exemple, le rapport propose d'« encourager » (ça ne coûte rien…) les chercheurs à candidater à des programmes de financement européens mais sans se demander pourquoi il n'y a pas davantage de telles candidatures. (C'est en partie parce que les chercheurs passent déjà plus de temps dans la paperasserie et dans la chasse aux subventions que dans la recherche. Mais on ne pouvait pas attendre d'une députée du parti du gouvernement qu'elle critique l'organisation actuelle de la recherche.)

Le rapport propose de fournir un calculateur quantique accessible en ligne (pardon, le rapport dit « cloud », c'est plus poétique) pour faire du QCaaS (Quantum Computing as a Service). C'est déjà proposé par IBM et AliBaba. Cela ne veut pas dire qu'il soit inutile d'en créer d'autres, meilleurs et/ou différents mais cela ne montre pas une énorme ambition.

D'autre part, certaines propositions auraient mérité d'être développées, notamment sur les moyens à mettre en œuvre. Ainsi, la proposition de créer des enseignements d'algorithmique quantique dans vingt cycles d'enseignement supérieur est une très bonne idée mais pas un mot n'est dit sur le recrutement d'enseignants, alors que justement les compétences en ce domaine ne sont pas largement répandues.

Le rapport, je l'ai dit, est globalement rigoureux, mais dérape quand même parfois par exemple quand, à propos de programmation, il pointe l'importance de développer des langages de programmation adaptés, de haut niveau (ce qui est une très bonne idée) mais cite ensuite comme exemple Q#, qui est justement un langage de très bas niveau, où on manipule les portes logiques directement. Vous imaginez programmer un ordinateur classique ainsi ? Seule la syntaxe de Q# est « de haut niveau », les concepts manipulés ne le sont pas. Au passage, si vous êtes prorgrammeur ou programmeuse, le site de questions/réponses StackExchange a une déclinaison sur le calcul quantique.

Un point que j'ai apprécié, par contre, est l'insistance sur les « technologies habilitantes ». Il s'agit de toutes les techniques qui permettent de réaliser des dispositifs quantiques, notamment la cryogénie. C'est à juste titre que le rapport rappelle qu'un ordinateur quantique n'est pas seulement composé de qubits, c'est d'abord un gros réfrigérateur.

Sur la forme, je note l'abus de termes en anglais, qui n'aide pas à la compréhension.

Notez que l'IETF a un travail en cours sur la cryptographie post-quantique et un groupe de recherche sur les réseaux quantiques, qui a produit plusieurs documents intéressants (je vous recommande draft-irtf-qirg-principles, qui explique bien la quantique, avant d'expliquer ce que pourrait être un réseau quantique. Le RIPE-NCC a déjà organisé un hackathon sur ce sujet.)


L'article seul

Un système anti-censure qui évolue en autonomie : Geneva

Première rédaction de cet article le 10 janvier 2020


La lutte technique de la liberté d'expression contre la censure sur l'Internet n'est pas près de s'arrêter. Chaque fois que les censeurs conçoivent de nouvelles techniques, les défenseurs de la liberté mettent au point de meilleurs méthodes pour leur échapper, les censeurs améliorent alors leurs techniques, et ainsi de suite. La partie est donc difficile pour ceux et celles qui réalisent des dispositifs anti-censure, car il faut en permanence suivre et s'adapter. D'où l'idée d'un système qui évolue « tout seul ». Le génial Geneva utilise le concept des algorithmes génétiques, pour s'adapter à la censure et évoluer automatiquement en même temps qu'elle.

Geneva traite le cas des systèmes de censure Internet de type Homme du Côté. Dans ces systèmes (il en existe beaucoup d'autres ; les censeurs ont de l'imagination, et beaucoup plus d'argent et d'hommes que les défenseurs de la liberté), le censeur peut observer les paquets IP qui passent, et générer ses propres paquets, mais il ne peut pas modifier les paquets envoyés. (Dans les systèmes d'Homme du Milieu, par exemple le pare-feu d'une entreprise, l'attaquant peut modifier ou jeter les paquets, ces systèmes sont donc plus efficaces mais aussi plus coûteux, et parfois plus difficiles à intégrer dans l'infrastructure. Ils sont donc moins employés à l'échelle d'un pays, où le trafic est important. Mais rappelez-vous toujours que les censeurs utilisent plusieurs techniques, et souvent une combinaison de techniques, ajoutant par exemple les résolveurs DNS menteurs.) Un exemple d'attaque de l'Homme du Côté est un système qui observe le SNI dans les requêtes TLS (par exemple HTTPS) et, s'il voit un nom de domaine interdit (ou même simplement un mot censuré, par exemple Falun Gong en Chine), il génère un paquet TCP RST (ReSeT, RFC 793, section 3.1) vers l'émetteur ou le destinataire, coupant ainsi la connexion. TLS ne protège pas contre ces attaques, puisque, contrairement à QUIC, TLS ne chiffre pas la couche Transport. (Rappelez-vous également que l'Homme du Côté voit tous les paquets, il a donc la partie bien plus facile que l'attaquant aveugle des RFC 5927 ou RFC 5961.)

Contre de telles techniques de censure, la solution habituelle (et de nombreuses ont été développées) est de semer la confusion chez l'Homme du Côté, en envoyant des paquets qui seront interprétés différemment par le censeur et par le vrai destinataire. Par exemple, on envoie un paquet TCP RST avec un TTL qui lui permet d'atteindre la machine du censeur mais pas celle du destinataire. Le censeur croira alors que la connexion est finie, alors qu'en fait elle continuera. (Le censeur, dans le cas d'un État, a des moyens importants mais pas illimités. Il a donc intérêt à libérer de la mémoire en « oubliant » les connexions terminées, ce qui fait que le reste de la communication est ignoré.) L'inconvénient de ces stratégies est qu'il faut recommencer souvent, puisque les techniques de censure évoluent. Chaque fois que la censure se perfectionne, des contournements existants deviennent inefficaces et on est à nouveau censuré jusqu'au développement (lent et laborieux) d'un nouveau contournement. La lutte contre la censure est donc un combat éternel entre l'épée et la cuirasse.

Que peuvent apporter les algorithmes génétiques ici ? Un algorithme génétique est un algorithme qui reprend les grands concepts de la sélection naturelle. On choisit un ensemble de fonctions, on leur donne des règles de mutation, une fonction d'évaluation du résultat (qui joue le rôle de la survie du plus apte) et on laisse ensuite le système évoluer. On peut ainsi explorer un espace de solutions très large en bien moins de temps.

Tout l'art du concepteur d'algorithmes génétiques est dans la liberté plus ou moins grande qu'il ou elle laisse aux mutations. Si on laisse les mutations se faire au hasard, l'écrasante majorité des stratégies produites seront non viables, et l'exploration de l'espace des solutions prendra des siècles. Mais si on contraint fortement les mutations possibles, l'algorithme n'ira jamais bien loin, il restera sur les sentiers battus et ne fera pas de découverte disruptive.

Geneva tourne sur la machine du client, celui ou celle qui veut accéder à des contenus censurés. Geneva définit les solutions contre les attaques de l'Homme du Côté en trois parties : un déclencheur (trigger) qui dit quand lancer la solution, des actions qui disent ce qu'on va faire (par exemple créer un nouveau paquet) et des arbres (action trees) qui coordonnent la succession des actions. Par exemple, la stratégie mentionnée plus haut (un paquet TCP RST avec un TTL conçu pour atteindre le censeur mais pas le destinataire) s'exprimerait, dans le DSL de Geneva :

[TCP:flags:A]-

duplicate(send,
          tamper(TCP:flags:R)(
              tamper(IP:TTL:replace:10)
                  (send)))

-| \/
  

Le terme [TCP:flags:A] est le déclencheur : quand on envoie le TCP ACK (accusé de réception), on duplique ce paquet et on envoie à la fois le vrai et une copie ayant le bit R (RST) et un TTL diminué, pour n'atteindre que le censeur et lui faire croire que la connexion est finie. Un autre exemple corrompt délibérément la somme de contrôle TCP : certains censeurs ignorent cette somme de contrôle, ce qui permet d'envoyer un paquet (par exemple RST) qui ne sera lu que par l'Homme du Côté.

Geneva commence avec un ensemble de solutions faites à la main, les individus sur lesquels va s'exercer l'évolution. Ensuite, les mutations se produisent, portant sur les déclencheurs, sur les actions, et sur les arbres (la succession des actions). Geneva teste ensuite les résultats des mutations en cherchant à se connecter à un site Web censuré. Le critère de sélection est donc la réussite dans le contournement de la censure. (Les règles exactes sont plus complexes, car il faut éviter de se laisser pièger dans des minima locaux ; ce n'est pas parce qu'une solution marche qu'elle est la meilleure. Et puis certains systèmes de censure ne sont pas déterministes ; soit suite à une bogue, soit délibérement pour compliquer l'analyse, ils ne bloquent pas toujours.)

Geneva a été mis en œuvre en Python, utilisant évidemment Scapy, et le NFqueue de Netfilter sur Linux pour accéder au réseau. Notons que certaines opérations nécessitent d'être root (modifier les en-têtes IP) mais pas toutes (changer le découpage des données en segments TCP), ce qui permet dans certains cas de faire tourner Geneva, ou du moins le script (la stratégie) sélectionné, sans être root. Le code pour exécuter les scripts (mais pas encore celui avec l'algorithme génétique) est disponible en ligne.

Quels sont les résultats ? Eh bien, Geneva fonctionne, et même très bien d'après ses auteurs. En seulement quelques heures, il trouve une stratégie de contournement de la censure. Geneva a été testé dans le laboratoire, face à des solutions de censure connues, mais aussi en vrai sur le terrain, en Chine face au GFW, en Inde et au Kazakhstan. Disons-le tout de suite, en matière de censure, le GFW est le seul système intéressant, les autres sont vraiment primitifs. Geneva n'a eu aucun problème à trouver une stratégie pour échapper aux censures indienne et kazakhstanaise (simplement mettre le SNI dans deux segments TCP différents suffit, au Kazakhstan) mais le GFW lui a donné plus de fil à retordre. Le script :

[TCP:flags:PA]-fragment{tcp:8:True}(send,send)-|
[TCP:flags:A]-tamper{TCP:seq:corrupt}(send)-| \/
  

a réussi à passer. J'ai également bien aimé la stratégie FRAPUN (ainsi nommée en raison des bits de l'en-tête TCP qu'elle met à 1.)

Un des avantages des algorithmes génétiques est qu'ils peuvent trouver des solutions auxquelles leurs auteurs n'ont pas pensé (mais qu'ils peuvent expliquer a posteriori). Plus drôle, Geneva a aussi trouvé une solution que les auteurs du programme n'ont pas pu expliquer, mais qui marche face au GFW :

[TCP:flags:PA]-
fragment{tcp:8:True}(send,
fragment{tcp:4:True}(send, send))-| \/

Ce très bon article se termine par une discussion sur l'avenir de la lutte anti-censure. Geneva ne va évidemment pas mettre un point final à la question, il est certain que les censeurs s'y adapteront (c'est un problème classique en sécurité informatique : les logiciels distribués publiquement peuvent être utilisés par les bons comme par les méchants.)

J'ai aussi apprécié que l'article n'utilise pas de buzzwords comme IA ou machine learning. Aujourd'hui, où les chercheurs doivent passer davantage de temps à chercher des subventions et de l'impact médiatique (l'un n'allant pas sans l'autre) plutôt qu'à chercher, c'est appréciable. Mais, hélas, le dépôt git du projet, lui, le fait.

Notez que l'article mentionne des considérations éthiques. Lancer Geneva sur une machine en Chine peut vous attirer des ennuis. (L'Inde est moins dangereuse, de ce point de vue.) Certes, Geneva n'est pas trop bavard en octets mais son comportement si particulier pourrait être remarqué par les systèmes de surveillance que déploient la plupart des pays. C'est un problème fréquent quand on étudie la censure. Il faut donc bien prévenir les utilisateurs (ce que rappelle bien la section Disclaimer dans la documentation d'installation du logiciel.)


L'article seul

Historique dans RDAP

Première rédaction de cet article le 9 janvier 2020


Le protocole RDAP permet d'obtenir des informations sur une ressource enregistrée dans un registre, par exemple un RIR. Une extension permet d'avoir accès à l'histoire d'une ressource.

RDAP est normalisé dans les RFC 7480, RFC 7481 et RFC 7482. L'extension n'a jamais été normalisée, mais elle est déployée à l'APNIC. Voici un exemple d'utilisation, pour avoir l'histoire de l'adresse IP 2001:dc0:2001:11::194 :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194
...
  

Bon, d'accord, le résultat est confus. C'est du JSON donc on utilise jq pour le formatter plus joliment :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | jq .
...
      "applicableFrom": "2019-02-14T05:37:22Z",
      "applicableUntil": "2019-07-29T03:31:05Z",
      "content": {
        "country": "AU",
        "name": "APNIC-AP-V6-BNE",
        "type": "ASSIGNED PORTABLE",
        "startAddress": "2001:dc0:2000::",
        "ipVersion": "v6",
        "endAddress": "2001:dc0:3fff:ffff:ffff:ffff:ffff:ffff",
        "objectClassName": "ip network",
        "handle": "2001:0DC0:2000::/35",
...
  

On récupère un tableau d'enregistrements, chaque enregistrement étant valable de applicableFrom à applicableUntil. Pour voir combien de changements a vu ce préfixe IP, on va utiliser les fonctions de sélection de jq :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq ".records|.[].applicableFrom"
...
  

Ça fait 48 changements, comme on pourrait le compter avec jq :

% curl -s http://rdap.apnic.net/history/ip/2001:dc0:2001:11::194 | \
    jq "[ .records|.[].applicableFrom ] | length"
49
  

Il avait été prévu à un moment de normaliser cette extension RDAP à l'IETF (Internet-Draft draft-ellacott-historical-rdap). Mais ça n'a pas suscité suffisamment d'intérêt. D'ailleurs, l'extension n'est même pas dans le registre des extensions RDAP. Une telle extension serait pratique pour l'investigation, mais pose aussi des problèmes de vie privée (plus de droit à l'oubli).


L'article seul

50 ans

Première rédaction de cet article le 1 janvier 2020


Non, ce n'est pas mon âge. Mais, aujourd'hui, l'« epoch » d'Unix et de l'Internet a cinquante ans.

J'ai toujours été fasciné par les calendriers. C'est un intérêt courant chez les informaticiens, d'autant plus que la quasi-totalité des logiciels qui manipulent des dates sont bogués, en partie en raison de la complexité du problème.

Tous les calendriers commencent par une date spéciale. Cela peut-être la naissance d'un prophète, le début de sa prédication, une insurrection, une proclamation, un serment, une grande bataille, ou un autre événement important, réel ou imaginé. Il y a avant et puis après. Ainsi, le calendrier légal en France, comme dans la plupart des pays du monde, est fondé sur la date de naissance (supposée…) de Jésus-Christ. Pour le laïciser un peu, on parle désormais d'« ère commune » et nous sommes donc le 1 janvier 2020 de l'ère commune (en anglais, CE, pour « common era ».)

Cette date spéciale se nomme en anglais « epoch » et nous allons parler ici d'une « epoch » intéressante, le premier janvier 1970.

Car le choix de la date spéciale est crucial. Elle sépare l'histoire en deux, avant, âge de ténèbres, d'ignorance et d'oppression, et après, âge du bonheur et de la lumière. D'où le choix d'événements grandioses pour distinguer l'avant et l'après.

Mais les ordinateurs ne sont pas romantiques. Ils se moquent des grands sentiments et des passions humaines, ils sont gérés par la pure rationalité. Quand on a besoin de définir une « epoch », pour les ordinateurs, il n'est pas nécessaire d'utiliser une date émouvante. Et, comme on a rarement besoin, sauf si l'ordinateur est utilisé par un historien, de manipuler dans un programme informatique des dates très anciennes, autant prendre une « epoch » récente. Le premier janvier 1970, certains lecteurs et lectrices de ce texte étaient déjà nés, ainsi que l'auteur de ces lignes (mais je n'avais pas encore mon bac).

C'est ainsi que le système d'exploitation (logiciel de base de la machine) le plus utilisé dans le monde, Unix, utilise comme « epoch », comme date spéciale, le 1 janvier 1970, il y a juste cinquante ans. Cette date a été choisie simplement parce qu'elle était, au moment du choix, située dans un passé récent et qu'elle était facile à mémoriser.

Unix compte tous les temps en secondes écoulées depuis le 1 janvier 1970 à 0h0mn, temps universel. Évidemment, ce n'est que la représentation interne, dans la mémoire du système. Les applications destinées aux utilisateurs affichent la date d'une manière plus habituelle. La très forte prévalence d'Unix dans l'Internet (la quasi-totalité des serveurs, et la grande majorité des clients) fait que cette epoch est également, de facto, celle de l'Internet, qui a commencé à peu près au même moment. (Jérôme Mainaud, merci à lui, me fait remarquer que le protocole de synchronisation d'horloges NTP, très répandu sur l'Internet, a une autre epoch, le 1 janvier 1900.)

Si vous êtes en ce moment sur une machine Unix dotée d'un « shell », d'un interpréteur de commandes, et que vous avez le programme « GNU date » (sur des systèmes comme Ubuntu ou Mint, c'est le programme date par défaut), vous pouvez afficher le nombre de secondes écoulées depuis l'« epoch » en tapant :

date +%s

Le premier janvier 2020, à 0h0mn en temps universel, il affiche 1 577 836 800.

Une lecture recommandée : « Calendrical calculations », d'Edward Reingold et Nachum Dershowitz (Cambridge University Press).

Merci à Hervé Le Crosnier (C&F Éditions) pour l'inspiration pour cet article.


L'article seul

Articles des différentes années : 2020  2019  2018  2017  2016  2015  2014  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.