DMARC (RFC 9989) permet de demander l'envoi, par les destinataires des messages, de rapports indiquant les éventuels problèmes notés, afin de diminuer le nombre de faux positifs (messages légitimes incorrectement considérés comme invalides). Cette demande de rapports se fait en ajoutant l'option "ruf" à l'enregistrement DMARC. Ce RFC décrit ces rapports.

DMARC est une technique d'authentification du courrier électronique qui permet à un domaine d'indiquer quelle est sa politique de sécurité vis-à-vis des messages dont l'expéditeur (le champ "From:" de l'en-tête) indique ce domaine. Il donne au gérant du domaine la possibilité d'annoncer sa politique de sécurité « tous les messages de ce domaine sont authentifiés (via SPF ou DKIM) ». Typiquement, DMARC est le couronnement d'une démarche de sécurité du courrier, ce qu'on annonce quand on a bien tout authentifié. Par contre, attention, en authentifiant la donnée visible par les utilisateurs et pas les données techniques, il casse certains usages du courrier. DMARC était à l'origine normalisé dans le RFC 7489, que ce nouveau RFC remplace. Mais rassurez-vous si vous avez déjà déployé DMARC : les changements ne sont pas radicaux. Le principal est le nouvel algorithme pour trouver l'enregistrement DMARC pertinent (celui à l'apex du domaine enregistré).

Ah, l'IA… Vaste sujet, et d'actualité. Une des questions qui reviennent souvent est celle de l'utilisation du contenu qu'on trouve sur le Web pour entrainer les grands modèles, sa légitimité, la charge qu'elle induit pour les serveurs, les moyens de la contrôler, etc. Un colloque avait été organisé (https://www.ietf.org/blog/impressions-ai-control-workshop/) par l'IAB en septembre 2024 sur ces questions et ce RFC en est le compte-rendu. Ce colloque avait lancé le projet IETF aipref (https://datatracker.ietf.org/wg/aipref/).

Continuons avec des vieux RFC. Ce RFC de 1970 se distinguait par une augmentation spectaculaire de la taille des adresses réseau : elles passaient de 5 à 8 bits.

Pour compléter un processus de sécurisation des noms de domaine avec DNSSEC, il faut transmettre au domaine parent votre clé publique. Le faire manuellement via l'interface Web du BE n'est pas pratique donc il existe un moyen d'automatiser cela, les CDS/CDNSKEY, moyen décrit dans le RFC 7344. Mais attention à la sécurité ! Ce moyen n'est sûr que si on suit quelques précautions, décrites dans ce nouveau RFC.

Voici encore un RFC qui normalise quelque chose qui existait depuis longtemps : le protocole Agent de SSH.

Voici la version 2 du format de représentation d'entités (personnes ou organisations) JSContact (RFC 9553). En fait, ce numéro de version est trompeur, il n'y a qu'un seul changement, le membre "uid" qui était obligatoire devient facultatif. Mais ce petit changement, qui casse la compatibilité, oblige à changer de numéro de version.

Ce n'est pas tous les jours qu'on normalise une nouvelle méthode HTTP. Bienvenue, donc, à QUERY, qui rejoint des méthodes bien plus anciennes comme GET et POST. QUERY peut être décrit comme « GET mais avec un corps dans la requête ». Comme GET, elle est idempotente et donc sûre à répéter.

Tout le monde parle (https://www.afnic.fr/observatoire-ressources/papier-expert/en-route-vers-la-journee-du-conseil-scientifique-2025/) des calculateurs quantiques et du risque qu'ils font peser sur la cryptographie traditionnelle. La solution ? Remplacer ces algorithmes par des algorithmes post-quantiques, c'est-à-dire résistant aux calculateurs quantiques. Ces algorithmes existent déjà, plusieurs sont normalisés et beaucoup ont déjà été mis en œuvre dans des programmes. Mais les intégrer dans les protocoles de l'Internet n'est pas trivial. Ce RFC vise à guider les ingénieur·es qui vont appliquer ces algorithmes post-quantiques à des logiciels et des protocoles du monde de l'Internet.

Vous le savez, le jour où des CRQC (Cryptographically Relevant Quantum Computer, un calculateur quantique capable de calculs non triviaux, contrairement aux modèles d'aujourd'hui) seront disponibles, la cryptographie sera sérieusement secouée. Il est donc important de travailler dès maintenant sur des algorithmes pour l'après-quantique, et de les intégrer dans les protocoles et les formats utilisés sur l'Internet. Ce RFC documente l'utilisation des algorithmes normalisés par le NIST dans le format OpenPGP.

Des attaques sur la chaine d'approvisionnement du logiciel, il y en a tout le temps. L'attaquant arrive à glisser du code malveillant dans un logiciel, en amont de son installation par la victime et, quand celle-ci fait tourner le logiciel, le code de l'attaquant est exécuté et paf. Il n'y a pas de solution miracle à ce problème mais on peut au moins essayer de fournir une traçabilité forte des logiciels, qui permet d'être sûr de ce qu'on fait tourner sur ses machines, et, dans le cas d'une enquête postérieure, de mieux comprendre ce qui s'est passé. Ce RFC décrit une architecture (https://scitt.io/), très inspirée du Certificate Transparency du RFC 9162.

Du 18 au 20 juin 2026, à Luxembourg, se tenait une exposition scientifique sur l'histoire du CD-ROM et la conférence Technostalgia (https://www.uni.lu/c2dh-en/events/technostalgia/).

En octobre 2025, l'IAB et le W3C ont organisé un atelier (https://datatracker.ietf.org/group/agews/about/) à Londres sur la restriction d'accès à des services Internet en fonction de l'âge. Ce RFC est le compte-rendu de l'atelier. En tant que compte-rendu, il n'exprime donc pas une position officielle de l'IAB.

Dans les débats sur la conception d'un réseau informatique de grande taille, on entend souvent des références à une discussion « commutation de paquets » vs. « commutation de circuits ». Cela revient souvent, par exemple, quand on parle en France des choix de Transpac par rapport à l'Internet. Mais la discussion est parfois mal informée sur la réalité de ces architectures et elle oublie une autre discussion, « commutation de paquets » vs. « datagramme pur ».

Ce RFC met à jour la norme de la version 1.3 du protocole de cryptographie TLS. Il n'y a pas de grand changement par rapport à son prédécesseur, le RFC 8446.

Vous gérez un AS ou, tout simplement, vous êtes curieux du routage d'un réseau que vous utilisez ? Il existe plusieurs outils d'analyse de la configuration et de la sécurité du routage, aujourd'hui, voyons un des plus récents, Sentinelle (https://sentinelle-routage.fr/).

Si vous utilisez le service de messagerie instantanée Telegram, vous avez sans doute vu aujourd'hui 14 juillet 2026, que des services ne marchaient pas, notamment les liens vers des ressources diverses (images, etc). C'est parce que le registre de noms de domaine du Monténégro l'avait décidé. Voyons les détails.

Vous pouvez toujours utiliser la version 1.2 de TLS mais ne demandez pas des ajouts, des extensions, etc. Elle est désormais gelée, aucune nouvelle fonction ne sera ajoutée, tout le travail se fait désormais sur la meilleure version, la 1.3, normalisée dans le RFC 9846.

L'authentification dans TLS se fait typiquement soit à partir d'un certificat, soit par une clé partagée à l'avance. Ce RFC spécifie une extension de TLS qui permet d'utiliser certificat et clé partagée à l'avance. Il remplace le RFC 8773 mais ne change pas grand'chose, la principale modification étant que ce nouveau RFC a le statut de norme (au lieu d'être considéré comme expérimental).