Vue lecture

RFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices

Les objets connectés, vous le savez, sont une source d'ennuis et de risques de sécurité sans fin. Non seulement ils ne sont pas forcément utiles (faut-il vraiment connecter une brosse à dents au réseau ?) mais en outre, comme ils incluent un ordinateur complet, ils peuvent faire des choses auxquelles l'acheteur ne s'attend pas. Pour limiter un peu les risques, le RFC 8250 normalisait MUD (Manufacturer Usage Description), un mécanisme pour que le fournisseur du machin connecté documente sous un format analysable les accès au réseau dont l'objet avait besoin ce qui permet, par exemple, de configurer automatiquement un pare-feu, qui va s'assurer que la brosse à dents ne se connecte pas (https://www.ietf.org/blog/mud/) à Pornhub. Dans un fichier MUD, les services avec lesquels l'objet communique sont typiquement indiqués par un nom de domaine. Mais le DNS a quelques subtilités qui font que l'utilisation de ces noms nécessite quelques précautions, décrites dans ce nouveau RFC.
  •  

RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)

Ces deux nouveaux types d'enregistrement DNS, SVCB et sa variante HTTPS, permettent de donner des informations supplémentaires à un client réseau avant qu'il ne tente de se connecter à un serveur. On peut envoyer ainsi des indications sur les versions des protocoles gérées, des clés cryptographiques ou des noms de serveurs supplémentaires.
  •  

RFC 9724: Randomized and Changing MAC Address State of Affairs

Dans le contexte de la surveillance massive qui s'exerce contre les utilisateurices de l'Internet, tout identifiant un peu stable peut être utilisé pour pister quelqu'un. On en laisse, des traces ! C'est par exemple le cas avec l'adresse MAC. Ce nouveau RFC décrit les mécanismes existants pour diminuer le risque de pistage par l'adresse MAC. Il ne spécifie pas un protocole, il liste les solutions.
  •  

RFC 9694: Guidelines for the Definition of New Top-Level Media Types

Vous savez que les types de médias comportent un type de premier niveau et un sous-type. Dans "image/gif", "image" est le type de premier niveau et "gif" le sous-type. On crée des sous-types tout le temps mais les types, l'identificateur qui est au premier niveau, c'est bien plus rare. La création du type "haptics (https://www.iana.org/assignments/media-types/media-types.xml#haptics)" (données haptiques), qui a été faite dans le RFC 9695, a été l'occasion de formaliser un peu plus le processus de création de types de médias.
  •  

RFC 9743: Specifying New Congestion Control Algorithms

La lutte contre la congestion du réseau est une tâche permanente des algorithmes utilisés dans l'Internet. Si les émetteurs de données envoyaient des octets aussi vite qu'ils le pouvaient, sans jamais réfléchir, l'Internet s'écroulerait vite. Des protocoles comme TCP ou QUIC contiennent donc des algorithmes de contrôle de la congestion. Il y en a plusieurs, certains peuvent être néfastes, et ce RFC, qui remplace le RFC 5033, explique comment de nouveaux algorithmes doivent être évalués avant d'être déployés en vrai. Bref, la prudence est nécessaire.
  •  

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

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.
  •  

RFC 9741: Concise Data Definition Language (CDDL): Additional Control Operators for the Conversion and Processing of Text

Le langage CDDL, qui permet de créer un schéma formel pour des formats comme CBOR, peut s'étendre via l'ajout d'« opérateurs de contrôle ». Ce RFC en spécifie quelques uns, notamment pour agir sur du texte ou convertir d'une forme dans une autre.
  •  

RFC 9707: IAB Barriers to Internet Access of Services (BIAS) Workshop Report

L'Internet est aujourd'hui un service indispensable à toutes les activités humaines. Un accès correct à ce réseau est donc crucial. Mais plusieurs problèmes limitent l'accès à l'Internet ou à plusieurs de ses services. L'IAB avait organisé en janvier 2024 un atelier sur cette question, atelier dont ce RFC est le compte-rendu.
  •  

Si Einstein avait su

Alain Aspect raconte dans ce livre l'histoire des expériences qu'il a menées dans les années 1970-1980 et qui ont prouvé la violation des inégalités de Bell (en termes journalistiques « prouvé qu'Einstein avait tort »). Attention, il faut s'accrocher, mais c'est très bien décrit.
  •  

Fusion thermonucléaire et interprétation des annonces

Le 18 février, le CEA a annoncé avoir battu un record de durée de confinement pour du plasma. Aussitôt, des dizaines de personnes ont écrit des messages techno-béats et anti-écologistes, sans prendre la mesure de ce qui avait été réalisé et de ce qui reste à faire. Petite discussion sur cette réactivité des technosolutionnistes, ces gens qui espèrent résoudre tous les problèmes de l'humanité par une invention technique spectaculaire.
  •  

RFC 9609: Initializing a DNS Resolver with Priming Queries

Un résolveur DNS ne connait au début, rien du contenu du DNS. Rien ? Pas tout à fait, il connait une liste des serveurs de noms faisant autorité pour la racine, car c'est par eux qu'il va commencer le processus de résolution de noms. Cette liste est typiquement en dur dans le code du serveur, ou bien dans un de ses fichiers de configuration. Mais peu d'administrateurs système la maintiennent à jour. Il est donc prudent, au démarrage du résolveur, de chercher une liste vraiment à jour, et c'est le priming (amorçage, comme lorsqu'on amorce une pompe pour qu'elle fonctionne seule ensuite), opération que décrit ce RFC, qui remplace l'ancienne version, le RFC 8109 (les changements sont nombreux mais sont surtout des points de détail).
  •