Vue lecture

Cryptographie par la pratique avec Python et OpenSSL

Vous le savez tous et toutes, la cryptographie est une composante essentielle de la sécurité de l'Internet. Si tout le monde ne va pas devenir expert·e en cryptographie, en revanche, il est utile de connaitre les principes de base. Ce livre (https://www.dunod.com/sciences-techniques/cryptographie-par-pratique-avec-python-et-openssl-cours-et-applications), destiné à des étudiant·es plutôt qu'au grand public, est une approche très concrète de la cryptographie, avec des exemples pratiques. J'ai beaucoup apprécié cette approche terre-à-terre.
  •  

La robustesse de la connectivité Internet, l'exemple du Pakistan

Si vous êtes en vacances dans les prochains jours, cela peut être l'occasion de lire des articles scientifiques riches. Par exemple, si vous voulez en apprendre davantage sur la robustesse des connexions Internet face aux coupures de câbles, regardez le cas du Pakistan dans cet article (https://dl.acm.org/doi/10.1145/3674213.3674220) (en anglais).
  •  

RFC 9300: The Locator/ID Separation Protocol (LISP)

Le protocole LISP (qui n'a rien à voir avec le langage de programmation du même nom), vise à résoudre un problème documenté dans le RFC 4984 : les difficultés que rencontre le système de routage de l'Internet devant les pressions imposées par la croissance du réseau et par le désir des utilisateurs de ne pas être lié à un unique fournisseur d'accès. Actuellement, tout changement de routage sur n'importe quel site se propage à tous les autres routeurs de la DFZ. Un tel système ne passe pas réellement à l'échelle (il ne peut pas croitre indéfiniment). LISP propose une solution, dans un ensemble de RFC dont ce RFC 9300 (qui succède au RFC 6830) est le principal. LISP n'est désormais plus considéré comme expérimental et ce nouveau RFC est sur le chemin des normes (Standards Track) mais, en pratique, le projet LISP semble plutôt en panne.
  •  

L'avenir d'Internet - unité ou fragmentation ?

La fragmentation d'Internet est un sujet complexe, et souvent mal traité. Ce court livre (https://www.editionsbdl.com/produit/lavenir-dinternet-unite-ou-fragmentation/) fait le point sur les différentes questions que soulève ce débat et d'abord « qu'est-ce que c'est que la fragmentation ? » J'en recommande la lecture.
  •  

RFC 9669: BPF Instruction Set Architecture (ISA)

On a souvent envie de faire tourner des programmes à soi dans le noyau du système d'exploitation, par exemple à des fins de débogage ou d'observation du système. Cela soulève plein de problèmes (programmer dans le noyau est délicat) et la technique eBPF permet, depuis de nombreuses années, de le faire avec moins de risques. Ce RFC spécifie le jeu d'instructions eBPF. Programmeureuses en langage d'assemblage, ce RFC est pour vous.
  •  

RFC 9636: The Time Zone Information Format (TZif)

Ce nouveau RFC documente un format déjà ancien et largement déployé, TZif, un format de description des fuseaux horaires. Il définit également des types MIME pour ce format, "application/tzif" et "application/tzif-leap". Il remplace le premier RFC de normalisation de ce format, le RFC 8536, mais il y a très peu de changements. Bienvenue donc à la version 4 du format, spécifiée dans ce RFC.
  •  

RFC 9673: IPv6 Hop-by-Hop Options Processing Procedures

Parmi les différentes options qui peuvent être placées dans un en-tête d'un paquet IPv6, certaines sont à traiter par chaque routeur situé sur le trajet. On les appelle les options « par saut » (hop-by-hop). Elles sont très peu utilisées en pratique, entre autres parce que leur traitement, tel que spécifié dans le RFC 8200, est trop contraignant pour les routeurs. Ce nouveau RFC change donc les règles, dans le sens d'un plus grand pragmatisme.
  •  

RFC 9311: Running an IETF Hackathon

L'IETF, l'organisation qui normalise les protocoles de l'Internet a toujours prôné le pragmatisme et le réalisme : ce n'est pas tout d'écrire des normes, il faut encore qu'elles fonctionnent en vrai. Un des outils pour cela est le hackathon qui se déroule traditionnellement le week-end avant les réunions physiques de l'IETF. Ce RFC, écrit par le responsable de ces hackathons, décrit l'organisation de ces événements.
  •  

RFC 9680: Antitrust Guidelines for IETF Participants

Les normes publiées par l'IETF ne sont pas que des documents techniques à seule destination des techniciens. L'Internet et, de manière plus générale, les protocoles TCP/IP sont aussi une grosse industrie qui brasse beaucoup d'argent. Il y a donc un risque que des acteurs de cette industrie essaient d'influencer les normes à leur profit, par exemple en formant des alliances qui, dans certains pays, seraient illégales au regard des lois antitrust. Ce court RFC administratif explique aux participant·es IETF ce que sont ces lois et comment éviter de les violer.
  •  

Online virality - Spread and Influence

Dans le contexte du Web, la viralité est un terme emprunté, évidemment, à l'épidémiologie, pour désigner une propagation rapide, de proche en proche, d'une information. En tant que phénomène social, elle peut être étudiée et c'est ce que fait ce livre collectif (https://www.degruyter.com/document/doi/10.1515/9783111311371/html) sur la viralité.
  •  

Quand les travailleurs sabotaient

Aujourd'hui, le terme de « sabotage » renvoie uniquement à des activités sournoises et clandestines, non revendiquées officiellement. Mais, à une époque, le terme était ouvertement discuté dans certaines organisations ouvrières, et considéré par certains comme un moyen de lutte parmi d'autres. Ce livre (https://agone.org/livre/quand-les-travailleurs-sabotaient/ ) revient sur l'histoire du concept de sabotage, notamment à propos des débats qu'il avait suscité dans le mouvement ouvrier.
  •  

RFC 9558: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC

Ce RFC marque l'arrivée d'un nouvel algorithme de signature dans les enregistrements DNSSEC, algorithme portant le numéro 23. Bienvenue au GOST R 34.10-2012 (alias ECC-GOST12), algorithme russe, spécifié en anglais dans le RFC 7091, une légère mise à jour de GOST R 34.10-2001.
  •  
❌