#rfc

RFC 8752 : Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)

Ce #RFC est le compte-rendu d’un atelier de l’IAB qui s’est tenu en juillet 2019 au sujet du #WebPackaging, une proposition technique permettant de regrouper un ensemble de pages Web en un seul fichier, pouvant être distribué par des moyens non-Web, tout en étant authentifié. Cela pose des questions nombreuses sur le copyright, l’authentification, la gouvernance, le rôle des intermédiaires (WebPackaging peut changer le rapport de force entre créateurs de contenu et GAFA) , etc. Un concentré d’enjeux et défis actuels.

https://www.bortzmeyer.org/8752.html

Bien que pas mal de gens ici font du Web, je n’ai pas trouvé d’article sur le WebPackaging sur SeenThis, qui, en tant qu’intermédiaire, pourrait être intéressé. Alors je mets d’autres liens :

La page de l’atelier, avec les textes soumis : https://www.iab.org/activities/workshops/escape-workshop

La page du projet WebPackaging : https://github.com/WICG/webpackage

Le groupe de travail IETF : https://datatracker.ietf.org/wg/wpack/documents

#WebPackage

RFC 8700: Fifty Years of RFCs | Blog @stephane Bortzmeyer
▻https://www.bortzmeyer.org/8700.html

Ce nouveau #RFC marque le cinquantième anniversaire des RFC. Le RFC 1 avait en effet été publié le 7 avril 1969. Ce RFC 8700, publié avec un certain retard, revient sur l’histoire de cette exceptionnelle série de documents.

Il y avait déjà eu des RFC faisant le bilan de la série, à l’occasion d’anniversaires, comme le RFC 2555 pour le trentième RFC, et le RFC 5540 pour le quarantième. La série a évidemment commencé avec le RFC 1, cinquante ans auparavant, et donc dans un monde très différent. À l’époque, les RFC méritaient leur nom, ils étaient été en effet des « appels à commentaires », prévus non pas comme des références stables, mais comme des étapes dans la discussion. En cinquante ans, les choses ont évidemment bien changé, et les RFC sont devenus des documents stables, intangibles, et archivés soigneusement. Logiquement, le processus de création des RFC a également évolué, notamment vers un plus grand formalisme (on peut même dire « bureaucratie »).

Plus de 8 500 RFC ont été publiés (il existe quelques trous dans la numérotation ; ainsi, le RFC 26 n’a jamais existé…) Les plus connus sont les normes techniques de l’Internet. La description précise de HTTP, BGP ou IP est dans un RFC. Mais d’autres RFC ne normalisent rien (c’est le cas du RFC 8700, sujet de cet article), ils documentent, expliquent, suggèrent… Tous les RFC ont en commun d’être publiés puis soigneusement gardés par le RFC Editor, une fonction assurée par plusieurs personnes, et aujourd’hui animée par Heather Flanagan, auteure de ce RFC 8700, mais qui a annoncé son départ.

Cette fonction a elle aussi une histoire : le premier RFC Editor était Jon Postel. À l’époque c’était une fonction informelle, tellement informelle que plus personne ne sait à partir de quand on a commencé à parler du (ou de la) RFC Editor (mais la première mention explicite est dans le RFC 902). Postel assurait cette fonction en plus de ses nombreuses autres tâches, sans que cela n’apparaisse sur aucune fiche de poste. Petit à petit, cette fonction s’est formalisée.

Les changements ont affecté bien des aspects de la série des RFC, pendant ces cinquante ans. Les premiers RFC étaient distribués par la poste ! Au fur et à mesure que le réseau (qui ne s’appelait pas encore Internet) se développait, ce mécanisme de distribution a été remplacé par le courrier électronique et le FTP anonyme. Autre changement, les instructions aux auteurs, données de manière purement orales, ont fini par être rédigées. Et l’équipe s’est étoffée : d’une personne au début, Postel seul, le RFC Editor a fini par être une tâche assurée par cinq à sept personnes. Autrefois, la fonction de RFC Editor était liée à celle de registre des noms et numéros, puis elle a été séparée (le registre étant désormais PTI). Puis la fonction de RFC Editor a été structurée, dans le RFC 4844, puis RFC 5620, enfin dans le RFC 6635. Et l’évolution continue, par exemple en ce moment avec le changement vers le nouveau format des documents (voir RFC 7990). Dans le futur, il y aura certainement d’autres changements, mais le RFC Editor affirme son engagement à toujours prioriser la stabilité de la formidable archive que représentent les RFC, et sa disponibilité sur le long terme (RFC 8153).

#histoire

RFC 8546 : The Wire Image of a Network Protocol

Ce #RFC de l’#IAB décrit l’important concept de vue depuis le réseau (wire image), une abstraction servant à modéliser ce que voit une entité qui ne participe pas à un protocole, mais peut en observer les effets. Cela peut être un routeur, un boitier de surveillance, etc. Le concept n’était pas nécessaire autrefois, où tout le trafic était en clair. Maintenant qu’une grande partie est (heureusement) chiffrée, il est important d’étudier ce qui reste visible à ces entités extérieures.

▻https://www.bortzmeyer.org/8546.html

#neutralité_réseau #vie_privée #protocoles_de_communication

RFC 8552 : Scoped Interpretation of DNS Resource Records through « Underscored » Naming of Attribute Leaves

Une convention répandue pour les #noms_de_domaine est de préfixer les services par un tiret bas, par exemple _xmpp-client._tcp.jabber.ietf.org. Cette pratique n’avait jamais été documentée mais c’est désormais fait. Et il existe désormais un registre #IANA des noms ainsi préfixés.

▻https://www.bortzmeyer.org/8552.html
▻https://www.bortzmeyer.org/8553.html

#RFC #DNS

Ces deux #RFC décrivent une extension au protocole d’avitaillement #EPP, permettant d’avoir des objets « organisation » (bureau d’enregistrement, revendeur, hébergeur #DNS…) et de les associer aux domaines, serveurs de noms et contacts.

▻https://www.bortzmeyer.org/8543.html
▻https://www.bortzmeyer.org/8544.html

Une grande partie de la sécurité du Web, et d’ailleurs de plein d’autres chose sur l’Internet, repose sur des certificats où une #Autorité_de_Certification (AC) garantit que vous êtes bien ce que vous prétendez être. Traditionnellement, l’émission d’un certificat se faisait selon un processus manuel, lent et coûteux, à part dans quelques AC automatisées et gratuites comme CAcert. Mais il n’existait pas de mécanisme standard pour cette automatisation. Un tel mécanisme standard existe désormais, avec le protocole #ACME, normalisé dans ce #RFC. Son utilisateur le plus connu est l’AC #Let_s_Encrypt, qui fournit, parmi des millions d’autres sites Web, le certificat de SeenThis.

▻https://www.bortzmeyer.org/8555.html

RFC 8490 : DNS Stateful Operations

Autrefois, le #DNS était toujours cité comme exemple d’un protocole sans état. On envoie une requête, on reçoit une réponse, et le client et le serveur oublient aussitôt qu’ils ont échangé, ils ne gardent pas de trace de cette communication. Mais, dans certains cas, maintenir un état sur une durée plus longue qu’un simple échange requête/réponse peut être utile. Ce nouveau #RFC propose un mécanisme pour des sessions DNS, le mécanisme DSO (DNS Stateful Operations). Il introduit donc une nouvelle notion dans le DNS, la persistance des sessions.

▻https://www.bortzmeyer.org/8490.html

RFC 8492 : Secure Password Ciphersuites for Transport Layer Security (TLS)

Ce nouveau #RFC décrit un mécanisme permettant une authentification lors de l’utilisation de #TLS sans utiliser de cryptographie à clé publique, mais avec un #mot_de_passe.

Au passage, l’auteur réhabilite la notion de mot de passe, souvent considérée comme une méthode d’authentification dépassée. Il estime que « un mot de passe est plus naturel qu’un certificat » car « depuis l’enfance, nous avons appris la sémantique d’un secret partagé ».

Experts en sécurité, ne jetez pas tout de suite ce RFC à la poubelle. Rassurez-vous, le mot de passe n’est pas utilisé tel quel, mais via un protocole nommé TLS-PWD, dont la principale partie s’appelle #Dragonfly.

▻https://www.bortzmeyer.org/8492.html

RFC 8482 : Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY

Lorsqu’un client #DNS envoie une requête à un serveur DNS, le client indique le type de données souhaité. Contrairement à ce qu’on lit souvent, le DNS ne sert pas à « traduire des noms de domaine en adresses IP ». Le DNS est une base de données généraliste, qui sert pour de nombreux types de données. Outre les types (AAAA pour les adresses IP, SRV pour les noms de serveurs assurant un service donné, SSHFP ou TLSA pour les clés cryptographiques, etc), le DNS permet de demander tous les types connus du serveur pour un nom de domaine donné ; c’est ce qu’on appelle une requête ANY. Pour différentes raisons, l’opérateur du serveur DNS peut ne pas souhaiter répondre à ces requêtes ANY. Ce nouveau #RFC spécifie ce qu’il faut faire dans ce cas.

▻https://www.bortzmeyer.org/8482.html

En 2019, un auteur écrira chaque jour un article sur un vieux #RFC :

▻https://write.as/365-rfcs/365-ietf-rfcs-a-50th-anniversary-dive

Il a commencé hier, avec le RFC 1 :

▻https://write.as/365-rfcs/rfc-1

Pour les suivants, pour suivre les textes :

▻https://write.as/365-rfcs

#histoire_Internet

RFC 8483 : Yeti DNS Testbed

Ce #RFC décrit une expérience, celle qui, de mai 2015 à décembre 2018, a consisté à faire tourner une racine #DNS alternative nommée #Yeti. Contrairement aux racines alternatives commerciales qui ne sont typiquement que des escroqueries visant à vendre à des gogos des TLD reconnus par personne, Yeti était une expérience technique ; il s’agissait de tester un certain nombre de techniques qu’on ne pouvait pas se permettre de tester sur la « vraie » racine.

▻https://www.bortzmeyer.org/8483.html

Ce que peut faire votre Fournisseur d’Accès à l’Internet
►https://framablog.org/2018/11/29/ce-que-peut-faire-votre-fournisseur-dacces-a-linternet

Nous sommes ravis et honorés d’accueillir Stéphane Bortzmeyer qui allie une compétence de haut niveau sur des questions assez techniques et une intéressante capacité à rendre assez claires des choses complexes. Nous le remercions de nous expliquer dans cet article … Lire la suite­­

#Claviers_invités #G.A.F.A.M. #Internet_et_société #Chiffrement #FAI #FFDN #GAFA #https #Internet #neutralité #Réseau #RFC #Snowden #Surveillance

RFC 8404 : Effects of Pervasive Encryption on Operators

La #vie_privée sur l’Internet fait aujourd’hui l’objet d’innombrables attaques et l’une des techniques de défense les plus efficaces contre ces attaques est le #chiffrement des données. Il protège également contre une autre menace, la modification des données en transit, comme le font certaines FAI (par exemple Orange Tunisie). Il y a de nombreuses campagnes de sensibilisation pour promouvoir le chiffrement, avec des bons résultats. Évidemment, ce chiffrement gène ceux qui voudraient espionner et modifier le trafic, et il fallait donc s’attendre à voir une réaction. Ce #RFC est l’expression de cette réaction, du côté de certains opérateurs réseaux, qui regrettent que le chiffrement empêche leurs mauvaises pratiques.

▻https://www.bortzmeyer.org/8404.html

RFC 8484 : DNS Queries over HTTPS (DoH)

Voici un nouveau moyen d’envoyer des requêtes #DNS, #DoH (DNS over #HTTPS). Requêtes et réponses, au lieu de voyager directement sur UDP ou TCP sont encapsulées dans HTTP, plus exactement HTTPS. Le but ? Il s’agit essentiellement de contourner la #censure, en fournissant un canal sécurisé avec un serveur supposé digne de confiance. Et le chiffrement sert également à préserver la vie privée du client. Toutes ces fonctions pourraient être assurées en mettant le DNS sur #TLS (RFC 7858) mais DoH augmente les chances de succès puisque le trafic HTTPS est rarement bloqué par les pare-feux, alors que le port 853 utilisé par DNS-sur-TLS peut être inaccessible, vu le nombre de violations de la neutralité du réseau. DoH marque donc une nouvelle étape dans la transition vers un Internet « port 443 seulement ».

#RFC

RFC 8446 : The Transport Layer Security (TLS) Protocol Version 1.3

Après un très long processus, et d’innombrables polémiques, la nouvelle version du protocole de #cryptographie #TLS, la 1.3, est enfin publiée. Les changements sont nombreux et, à bien des égards, il s’agit d’un nouveau protocole (l’ancien était décrit dans le RFC 5246, que notre nouveau #RFC remplace).

▻http://www.bortzmeyer.org/8446.html

#HTTPS

Allez, un peu de gouvernance cet après-midi.

Ce nouveau #RFC a l’air compliqué comme cela, mais en fait il ne fait qu’une chose : remplacer, dans le protocole Homenet/HNCP (Home Networking Control Protocol), le nom de domaine .home (qui avait été utilisé par erreur, sans passer par les procédures normales, par home.arpa.

▻http://www.bortzmeyer.org/8375.html

Il y avait trois candidatures pour le TLD .home, mais l’ICANN a finalement annoncé qu’ils ne le délégueraient pas.

#DNS #Homenet

RFC 8352 : Energy-Efficient Features of Internet of Things Protocols

Les objets contraints, engins connectés ayant peu de capacités (un capteur de température dans la nature, par exemple), ont en général une réserve d’énergie électrique très limitée, fournie par des piles ou batteries à la capacité réduite. L’usage des protocoles de communication traditionnels, souvent très bavards, épuiserait rapidement ces réserves. Ce #RFC étudie les mécanismes utilisables pour limiter la consommation électrique, et faire ainsi durer ces objets plus longtemps.

La plupart des protocoles de couche 2 utilisés pour ces « objets contraints » disposent de fonctions pour diminuer la consommation électrique. Notre RFC décrit ces fonctions, et explique comment les protocoles de couches supérieures, comme IP peuvent en tirer profit. Le but des techniques présentées dans ce RFC est bien de faire durer plus longtemps la batterie, ce n’est pas un but écologique. Si l’objet est alimenté en permanence (une télévision connectée, ou bien un grille-pain connecté), il n’y a pas de problème.

▻http://www.bortzmeyer.org/8352.html

#batterie #consommation_électrique #Internet_des_objets #6lowpan

RFC 8310 : Usage Profiles for DNS over TLS and DNS over DTLS

Afin de mieux protéger la #vie_privée des utilisateurs du #DNS, le RFC 7858 ▻https://seenthis.net/messages/490496 normalise comment faire du DNS sur #TLS, le chiffrement empêchant la lecture des requêtes et réponses DNS. Mais le chiffrement sans authentification n’a qu’un intérêt limité. Notamment, il ne protège pas contre un attaquant actif, qui joue les hommes du milieu. Le RFC 7858 ne proposait qu’un seul mécanisme d’authentification, peu pratique, les clés publiques configurées statiquement dans le client DNS. Ce nouveau #RFC décrit d’autres mécanismes d’authentification, classés selon deux profils, un Strict (sécurité maximum) et un Opportuniste (disponibilité maximum).

▻http://www.bortzmeyer.org/8310.html

#DPRIVE

RFC 8334 : Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)

Les registres de noms de domaine ont parfois des périodes d’enregistrement spéciales, par exemple lors de la phase de lancement d’un nouveau domaine d’enregistrement, ou bien lorsque les règles d’enregistrement changent. Pendant ces périodes, les conditions d’enregistrement ne sont pas les mêmes que pendant les périodes « standards ». Les registres qui utilisent le protocole #EPP pour l’enregistrement peuvent alors utiliser les extensions EPP de ce nouveau #RFC pour gérer ces périodes spéciales.

▻http://www.bortzmeyer.org/8334.html

#nom_de_domaine

RFC 8324 : DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure : Time for Another Look ?

Le #DNS est une infrastructure essentielle de l’Internet. S’il est en
panne, rien ne marche. S’il est lent, tout rame. Comme le DNS,
heureusement, marche très bien, et s’est montré efficace, fiable et
rapide, il souffre aujourd’hui de la malédiction des techniques à
succès : on essaie de charger la barque, de lui faire faire plein de
choses pour lesquelles il n’était pas prévu. D’un côté, c’est un signe
de succès. De l’autre, c’est parfois fragilisant. Dans ce #RFC
individuel, John Klensin, qui ne participe plus activement au
développement du DNS depuis des années, revient sur certaines de ces
choses qu’on essaie de faire faire au DNS et se demande si ce n’est
pas trop, et à partir de quel point il faudrait arrêter de
« perfectionner » le DNS et plutôt passer à « autre chose ». Une bonne
lecture pour celleszetceux qui ne veulent pas seulement faire marcher
le DNS mais aussi se demander « pourquoi c’est comme ça ? » et
« est-ce que ça pourrait être différent ? »

▻http://www.bortzmeyer.org/8324.html

RFC 8280 : Research into Human Rights Protocol Considerations

Ce #RFC très politique est le premier du groupe de recherche #IRTF #HRPC, dont le nom veut dire « Human Rights and Protocol Considerations ». À première vue, il n’y a pas de rapport entre les #droits_humains et les protocoles réseau. Les premiers relèvent de la politique, les seconds de la pure technique, non ? Mais, justement, le groupe HRPC a été créé sur la base de l’idée qu’il y a de la politique dans le travail de l’#IETF, que les protocoles ne sont pas complètement neutres, et qu’il était nécessaire de creuser cette relation complexe entre protocoles et droits humains. Le premier RFC analyse le problème de base : « #TCP/IP est-il politique ? »

▻http://www.bortzmeyer.org/8280.html

#droits_de_l_homme #DUDH

RFC 8288 : Web Linking

Le #lien est à la base du #Web. Mais c’est seulement récemment, avec le RFC 5988 que notre #RFC remplace, que certains manques ont été comblés :

– Un registre des types de lien ▻https://www.iana.org/assignments/link-relations/link-relations.xml

– Un mécanisme standard pour indiquer un lien dans une réponse HTTP

▻http://www.bortzmeyer.org/8288.html

RFC 8244 : Special-Use Domain Names Problem Statement

Le #RFC 6761 créait un registre de « #noms_de_domaines d’usage spécial », où l’#IETF enregistrait des noms qui pouvaient nécessiter un traitement spécial par une des entités de la chaîne d’avitaillement et de résolution des noms de domaines. Un exemple est celui des noms de domaine qui n’utilisaient pas le #DNS, comme le .onion de #Tor ou le .bit de #Namecoin. Certaines personnes ont émis des réserves sur ce registre, par exemple parce qu’il marchait sur une pelouse que l’#ICANN considère comme sienne. Ce nouveau RFC, très controversé, fait la liste de tous les reproches qui ont été faits au RFC 6761 et à son registre des noms spéciaux.

▻http://www.bortzmeyer.org/8244.html

#gouvernance_Internet

RFC 8255 : Multiple Language Content Type

La norme #MIME permet d’étiqueter un message en indiquant la langue, avec l’en-tête Content-Language : (RFC 4021). Mais comment faire si on veut envoyer le même message en plusieurs #langues, pour s’adapter à une audience variée, ou bien si on n’est pas sûr des langues parlées par le destinataire ? C’est ce que permet le nouveau type de message multipart/multilingual qui permet d’étiqueter les messages multilingues.

▻http://www.bortzmeyer.org/8255.html

#multilinguisme #internationalisation #RFC

RFC 8240 : Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016

La mode des #objets_connectés a mené à l’existence de nombreux « objets », qui sont en fait des ordinateurs (avec leurs problèmes, comme le fait que leur logiciel ait des failles de #sécurité), mais qui ne sont pas considérés comme des ordinateurs par leurs propriétaires, et ne sont donc pas gérés (pas d’administrateur système, pas de mises à jour des logiciels). L’attaque contre Dyn du 21 octobre 2016, apparemment menée par ces objets, a bien illustré le risque que cette profusion irresponsable crée. Ce nouveau #RFC est le compte-rendu d’un atelier sur la mise à jour des objets connectés, atelier de réflexion qui s’est tenu à Dublin les 13 et 14 juin 2016. Il fait le point sur la (difficile) question.

▻http://www.bortzmeyer.org/8240.html

#cyberguerre #piraté_par_mon_grille_pain