Type de contenu
Research
Dans la facette Type de contenu, les articles de type Research de BTW.MEDIA sont regroupés selon un même format éditorial, afin de permettre aux lecteurs de comparer briefings, profils, notes de risque, analyses de marché et reportages d'événements sans mélanger différents types de preuves. Cette page explique comment ce type de contenu met en perspective les événements liés à l'infrastructure Internet, les mouvements d'entreprises, les décisions de gouvernance, les signaux opérationnels et les preuves publiques sur l'ensemble du site. Les lecteurs peuvent ainsi identifier les acteurs ou systèmes d'infrastructure les plus fréquents, comprendre comment la qualité des sources modifie l'interprétation et déterminer si le contenu relève d'un profil durable, d'un événement urgent, d'un signal de marché stratégique ou d'une évolution de gouvernance. Le résultat est une page de recherche utile aux opérateurs, investisseurs, clients, analystes et décideurs publics qui doivent comprendre les conséquences, le calendrier et les preuves qui sous-tendent des formats d'articles similaires.
Dossier
Trois attestations exactes ne prouvent pas qu’elles appartiennent à la clé du CSR
Dans une chaîne de certification automatisée, trois voyants verts peuvent cacher une faute d’identité. Une preuve décrit une clé créée dans un HSM, une autre une machine détenue par l’entreprise, une troisième un état jugé sain. Tant que l’autorité n’a pas démontré qu’elles…
Dossier
Un seul minuteur a réglé trois mécanismes IPv6. Les compteurs ont perdu la cause
Le ticket demandait de modifier le rythme de détection d’une adresse dupliquée. La valeur choisie a aussi changé la résolution d’adresse et les sondes de joignabilité. Rien n’était invalide dans la transaction: c’est son périmètre réel qui n’avait pas été comptabilisé.
Dossier
Le réflecteur de routes a diffusé le lien sans jamais l’observer : la frontière probatoire de la RFC 9815
La promesse du peering clairsemé est séduisante: conserver BGP, supprimer une grande partie des sessions du fabric et laisser chaque routeur recalculer le plus court chemin à partir d’une topologie distribuée. La RFC 9815 rend cette architecture possible. Elle oblige aussi à…
Dossier
Le paquet n’avait pas de SRH. Il pouvait tout de même viser un SID SRv6
Le pare-feu frontal cherche un en-tête de routage de type 4, n’en trouve pas et classe le paquet comme IPv6 ordinaire. L’adresse de destination correspond pourtant à une fonction SRv6 locale. L’équipement a bien lu le paquet; c’est la question posée qui était trop étroite.
Dossier
RFC 9814 : le vérificateur a reçu le flux avant de savoir exactement ce qui serait signé
Dans un service de vérification en continu, le contenu peut arriver bien avant le certificat, les attributs et la signature. Le système calcule alors un condensat au fil de l’eau, libère les blocs déjà traités, puis découvre à la fin la petite structure que SLH-DSA doit vérifier.…
Dossier
Derrière une même adresse NAT, l’identité PSK choisit désormais le client RADIUS : RFC 9813
Deux contrôleurs d’accès appartenant à des équipes différentes peuvent sortir par la même adresse publique. Pour le serveur RADIUS, leur provenance réseau est identique, mais leurs droits et leurs secrets ne devraient pas l’être. RFC 9813 introduit l’identité PSK comme clé de…
Dossier
La requête HTTP a répondu 200. La décision sur le certificat restait à l’intérieur : RFC 9811
Une supervision peut voir une requête verte alors que l’autorité de certification a refusé l’opération, l’a modifiée ou attend encore une approbation. La RFC 9811 ne présente pas ce décalage comme une anomalie: elle construit précisément la frontière entre la remise HTTP et la…
IETF
Une signature ne prouve pas la possession de l’autre clé : RFC 9883 et les déclarations de possession de clé privée
Une seconde demande de certificat peut être correctement signée par une clé de signature déjà certifiée, alors que cette signature ne constitue qu’une affirmation — et non une preuve technique — que le demandeur contrôle l’autre clé privée destinée au certificat de négociation de…
Histoire d'Internet
Le paquet sommé de répondre : la réparation « challenge ACK » de TCP
Pendant longtemps, un segment de réinitialisation placé quelque part dans la fenêtre de réception pouvait suffire à détruire une connexion TCP. La RFC 5961 a déplacé la frontière de confiance: la vraisemblance déclenche désormais une question, tandis que seule une preuve plus…
Histoire d'Internet
L’ACK qui ne pouvait pas dire quel paquet était arrivé : la règle de Karn face à l’ambiguïté des retransmissions
Un accusé de réception peut confirmer l’arrivée des octets sans révéler quelle copie transmise a provoqué sa réponse. La règle de Karn protège alors la mesure: la livraison progresse, mais l’échantillon de délai aller-retour est refusé.
IETF
L’algorithme de signature n’est pas la séquence d’octets signée : RFC 9882 et ML-DSA dans CMS
Deux systèmes CMS choisissent ML-DSA-65 pour le même contenu, mais la vérification échoue lorsque l’un signe une représentation finale au tag implicite et l’autre vérifie la valeur DER complète de SignedAttrs avec son tag explicite SET OF. L’algorithme concorde, pas le domaine…
Histoire d'Internet
Le paquet qui attendait son prédécesseur : la règle des petits segments de Nagle
Une nouvelle écriture d’un octet n’appelait pas un délai universel. Elle appelait une décision fondée sur l’état de la connexion: des données précédentes sont-elles encore sans accusé de réception ?
IETF
Le nom de l’algorithme ne suffit pas à définir le profil de certificat : RFC 9881 et ML-DSA dans PKIX
Le résumé de veille Le nom de l’algorithme ne suffit pas à définir le profil de certificat: RFC 9881 et ML-DSA dans PKIX explique le développement, les preuves publiques disponibles, les organisations concernées, le contexte régional, l’exposition au marché et les conséquences…
AFNOG
AfNOG publie les règles de sa liste, mais pas sa procédure de modération
AfNOG demande que sa liste reste technique, respectueuse et exempte de promotion commerciale flagrante. La règle est publique; la procédure appliquée lorsqu'un message est soupçonné de la franchir ne l'est pas.
IETF
Un TTL de registre décrit une politique, pas l’état instantané du DNS
La RFC 10037 permet à un registre de publier dans RDAP les durées de vie configurées pour certains ensembles d’enregistrements DNS. Derrière cette extension JSON modeste se trouve une séparation essentielle: RDAP expose l’intention enregistrée par le registre, et non le temps…
IETF
Un modèle de données n’est pas un contrat de protocole : RFC 9880 et les limites des liaisons SDF
Deux implémentations peuvent revendiquer le même modèle de Thing tout en divergeant sur le fil: l’une choisit une URL et un contenu JSON, l’autre un identifiant numérique et d’autres règles d’invocation. L’écart apparaît lorsque la liaison de protocole est restée implicite.
Histoire d'Internet
La sonde qui ne pouvait pas déclarer la mort d’un pair inactif : les keep-alives TCP
Une connexion TCP inactive peut rester silencieuse sans être rompue. Le keep-alive cherche à obtenir un indice sur l’état du transport, sans transformer une seule absence de réponse en conclusion définitive.
IETF
Un échange SSH hybride transforme la négociation en frontière de migration
Installer du code postquantique ne prouve pas qu'une session SSH l'a utilisé. La RFC 10042 définit trois méthodes hybrides associant ML-KEM à un échange elliptique éprouvé. La protection n'existe que si les deux pairs proposent la même méthode, si la négociation la retient, si…
Dirigeants
Prasad Vadke et l’horloge d’escalade derrière la messagerie d’entreprise
Une panne de messagerie déclenche deux chronomètres: celui du diagnostic technique et celui des décisions bloquées, des réunions interrompues et de l’incertitude qui coûte. Les textes publics de Prasad Vadke sur les accords de niveau de service prennent tout leur sens lorsqu’on…
IETF
Le contrôle d’intégrité a ses propres paramètres : RFC 9879 et PBMAC1 dans PKCS #12
L’interopérabilité d’un échange PKCS #12 peut échouer au niveau de l’intégrité lorsqu’une implémentation lit des champs hérités conservés pour la compatibilité, tandis qu’une autre suit les paramètres imbriqués de PBMAC1. Les deux parties peuvent alors dériver des clés…