L'imagination des cryptologues est sans fin, voici une nouvelle famille d'algorithmes de chiffrement, fondés sur le classique AES, la famille AEGIS (qui, au moment d'écrire cet article, n'a pas encore de page Wikipédia). AEGIS permet de réutiliser le jeu d'instructions AES mais est plus rapide qu'AES et fournit du chiffrement intègre.

La norme JSContact décrit un modèle de données et un format pour stocker des informations de contact sur une entité (personne physique ou morale). Elle est riche, avec beaucoup d'informations dont toutes les applications n'ont pas forcément besoin. Ce RFC normalise la notion de profil : un profil est une spécialisation de JSContact, indiquant les éléments obligatoires et les autres. Un nouveau registre IANA stocke les profils existants.

Aujourd'hui, bien des gens croient que la seule façon d'écrire un texte (sans le faire générer par un LLM) est d'utiliser un logiciel de traitement de texte graphique comme Writer. Mais il existe une autre méthode, plus ancienne mais toujours valable, les langages de marquage. C'est pour cela que j'ai acheté ce livre (https://link.springer.com/book/10.1007/979-8-8688-2931-4), qui retrace l'histoire de ces langages de marquage et vise surtout leur utilisation pour l'écriture de textes technique et scientifiques.

Du 30 septembre au 2 octobre, j'ai eu le plaisir de participer à la conférence Histories of Tracking (https://www.uni.lu/c2dh-en/events/histories-of-tracking/) à l'université du Luxembourg. Cette conférence était consacrée à la surveillance exercée sur les utilisateurices, notamment dans le contexte du numérique. Voici quelques notes sommaires.

Vous le savez, en ce moment, c'est la fête des fuites de données personnelles en France. Tout le monde (et son chat) a déjà été victime d'au moins une fuite. Au moins, grâce au RGPD, on est informé qu'il y a eu une fuite (https://bonjourlafuite.eu.org/). Mais que s'est-il passé derrière ? En général, on ne le sait pas. Aucune enquête indépendante publiée et, souvent, rien du tout n'est publié, on doit se fier aux rumeurs propagées par des influenceurs en cybersécurité sur les réseaux sociaux, par des ministres menteurs et par des journalistes ignorants. Mais le piratage de la DGFIP, il est vrai particulièrement scandaleux, fait, lui, l'objet d'une publication assez détaillée (https://cyber.gouv.fr/actualites/lanssi-publie-le-rapport-dincident-sur-les-cyberattaques-ayant-touche-la-dgfip/), par l'ANSSI.

Ce nouveau protocole de synchronisation d'horloges, Roughtime est, officiellement, encore expérimental. Deux de ses buts essentiels sont la possibilité d'une synchronisation sécurisée (avec de la cryptographie, donc), même quand le client n'a aucune idée de l'heure et du jour, et un moyen de signaler les erreurs et problèmes rencontrés. Il concernera notamment les objets connectés qui, souvent, n'ont pas de batterie pour garder l'heure pendant un arrêt.

Hier, l'ICANN a publié la liste des candidatures (https://newgtldprogram-aps.icann.org/) pour obtenir un TLD lors du cycle d'enregistrements actuel. Quelques données.

Du 22 au 27 septembre, un inconnu a piraté trois registres de noms de domaine. L'occasion de rappeler, face à plusieurs commentaires erronés, que si un attaquant prend le contrôle du nom de domaine, il peut tout faire (et, non, TLS ne protège pas).

Aujourd'hui, la racine du DNS, qui était signée avec la clé 20326 a changé, et utilise désormais la clé 38696.

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.

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.