La pandémie de #Covid_19 en 2020 a affecté de nombreux aspects de notre vie. Concernant plus spécifiquement l’#Internet, elle a accru l’utilisation d’outils de communication informatiques. Quels ont été les effets de ces changements sur l’Internet ? Un atelier de l’IAB fait le point sur ces effets et en tire des leçons dans ce #RFC 9075. Je vous le dis tout de suite : contrairement à certains discours sensationnalistes, l’Internet n’a pas subi de conséquences sérieuses.
Les quatre #RFC sur le protocole de transport #QUIC viennent d’être publiés. Ce nouveau protocole de transport, concurrent de #TCP, pourrait bien devenir le transport majoritaire sur l’Internet, notamment via son utilisation dans la nouvelle version de #HTTP, HTTP/3.
Il utilise systématiquement le #chiffrement, et chiffre même des parties du dialogue qui restaient en clair quand on utilisait #TLS sur TCP.
Pour résumer les différences entre QUIC et TCP (rappelez-vous qu’ils assurent à peu près les mêmes fonctions) :
– QUIC est systématiquement chiffré,
– QUIC permet un vrai multiplexage ; la requête lente ne bloque pas la rapide, et la perte d’un paquet ne ralentit pas tous les ruisseaux multiplexés,
– QUIC fusionne transport et chiffrement, ce qui permet notamment de diminuer la latence à l’établissement de la connexion,
– QUIC permet la migration d’une connexion en cas de changement d’adresse IP
résumé en image par Kevin Ottens. :
RFC 8890 : The Internet is for End Users
Excellente question, ça. L’Internet est pour qui ? Qui sont les « parties prenantes » et, parmi elles, quelles sont les plus importantes ? Plus concrètement, la question pour l’#IETF est « pour qui bossons-nous ? » Quels sont les « clients » de notre activité ? Ce #RFC de l’IAB met les pieds dans le plat et affirme bien haut que ce sont les intérêts des utilisateurs finaux qu’il faut considérer avant tout.
Le RFC (en anglais) : ▻https://www.rfc-editor.org/info/rfc8890
Un article (en anglais) de l’auteur : ▻https://www.mnot.net/blog/2020/08/28/for_the_users
Mon résumé (en français) : ▻https://www.bortzmeyer.org/8890.html
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
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).
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.
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
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.
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.
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.
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.
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 :
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.
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.
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).
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.
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).
Merci pour ce post de qualité (comme toujours). Un point sur le DHCP, je suis tout à fait d’accord pour dire qu’il n’est pas sécurisé, cependant, il y a quand même beaucoup de switch et d’antennes WiFi qui permettent de filtrer les rogue DHCP et donc, ça évite que n’importe quel DNS (ou tout autre information) soit envoyé au client. Le client n’a cependant aucune moyen de vérifier cela.
Et même le serveur DHCP légitime peut être méchant et envoyer les clients vers un résolveur DNS qui fait des vilaines choses avec les données.
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.
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 ? »
Quelques typos :
la nom
admiistrateur
la l’automatisation
Et un commentaire :
C’est en partie pour de bonnes raisons (imaginez deux entreprises utilisant ce TLD et fusionnant… Un problème qu’on voit souvent avec le RFC 1918.)
Il n’y a pas besoin que deux entreprises fusionnent pour que le problème se pose avec la RFC 1918. Il suffit qu’elles interagissent et décident d’avoir un lien VPN entre les deux infrastructures.
@claudex Corrigées, merci. (Et cas du RFC 1918 précisé.)
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 ? »
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
