Mon blog

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

Une petite précision politique d'abord : le RFC précise bien qu'il s'agit d'un compte-rendu et que l'IAB n'approuve pas forcément tout ce qui a été dit à ce colloque (section 1.2 du RFC). Je rajoute que j'ai aussi des opinions sur le sujet, donc je mettrais [entre crochets] ce qui est mon opinion, et ne vient pas du RFC. Le reste n'est donc pas de moi, j'en rends compte, c'est tout, ne me tapez pas.

Ce colloque fait partie de la série de colloques qu'organise régulièrement l'IAB pour explorer des tendances à plus ou moins long terme, sans les obligations de l'IETF de produire normes et documents.

Donc, les LLM (qui ne sont qu'une partie des techniques qu'on regroupe sous le terme marketing d'« IA ») fonctionnent en deux phases : on entraine le modèle en lui faisant ingérer une grande quantité de contenu (textes, images ou autres), puis il va pouvoir inférer du contenu à partir de ce qu'il a digéré pendant la phase d'entrainement, et d'une demande (dite prompt). Le contenu inféré n'est jamais tout à fait identique à celui utilisé pour l'entrainement (autrement, cela serait du plagiat, potentiellement illégal). Les LLM ne marchant bien, à l'heure actuelle, que si le corpus d'entrainement était énorme, ils sont très gourmands en données et une source évidente de contenu en grande quantité est le Web. Des bots ou crawlers parcourent donc le Web, ramassant du contenu. Voici par exemple un extrait du journal du serveur qui héberge ce blog, montrant le bot de Perplexity récoltant du contenu :

18.210.92.235:64884 - - [09/Jan/2026:07:26:15 +0000] "GET /images/TCP_state_diagram.jpg HTTP/1.1" 200 96551 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" www.bortzmeyer.org TLS
18.97.9.103:64398 - - [09/Jan/2026:08:31:39 +0000] "GET /bitcoin-metamorphoses.html HTTP/1.1" 200 8982 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" www.bortzmeyer.org TLS
18.97.9.101:57493 - - [09/Jan/2026:08:31:39 +0000] "GET /robots.txt HTTP/1.1" 404 3250 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" www.bortzmeyer.org TLS
18.97.9.103:48122 - - [09/Jan/2026:08:47:36 +0000] "GET /nist-pq.pdf HTTP/1.1" 200 84543 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" www.bortzmeyer.org TLS
18.97.9.96:25157 - - [09/Jan/2026:08:51:37 +0000] "GET /files/capitole-libre-2019-quic-pour-impression.pdf HTTP/1.1" 200 212507 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)" www.bortzmeyer.org TLS

Une des questions soulevées par cette récolte de données est qu'elle n'était pas prévue à l'origine. Certains webmestres qui mettent du contenu en ligne estiment donc qu'un nouvel usage (l'entrainement des LLM) justifie de nouvelles règles et de nouvelles possibilités de contrôle par le serveur Web. C'est par exemple ce que prévoit l'AI Act européen.

Le colloque (ou atelier) de l'IAB s'est tenu les 19 et 20 septembre 2024 (oui, le RFC met trop longtemps à sortir) et prévoyait de travailler sur tous les aspects liés à cette récolte de données (cf. l'appel à participation). Le colloque regroupait des personnes de divers horizons, experts techniques, entreprises d'IA, fournisseurs de contenu, décideurs politiques, etc. La liste figure dans l'annexe A.2. La règle suivie était celle de Chatham House (tout ce qui se dit est public mais sans le lier à un·e participant·e particulier·ère). D'ailleurs, le RFC note qu'au moins un participant n'a pas voulu que son identité soit dévoilée, juste qu'il était un représentant officiel d'un gouvernement. Et, comme déjà dit, le RFC rend compte des discussions, cela ne signifie pas que l'IAB approuve tout ce qui a été dit.

La section 2 du RFC résume les discussions (la totalité des soumissions sont en ligne). Aujourd'hui, les fournisseurs de contenu, les webmestres, peuvent exprimer leurs choix quant à la récolte de données par divers moyens. Il y a par exemple une solution technique existante, c'est le robots.txt, qui est décrit dans le RFC 9309. Notez que, en l'absence du fichier robots.txt, les bots peuvent tout récolter. C'est donc une solution opt-out. Il y a aussi des solutions non-techniques par exemple les conditions d'utilisation (ainsi, ce blog est sous licence GFDL et les contenus peuvent donc être réutilisés, à la condition que les destinataires jouissent des mêmes droits de réutilisation). Tiens, par contre, il n'y a pas de licence CC-BY-NoAI ? Pour revenir à la technique, le webmestres peuvent aussi bloquer les crawlers par leur adresse IP, ou leur User-Agent (RFC 9110, section 10.1.5), ou carrément tout mettre derrière un paywall.

Comme indiqué plus haut, ces solutions sont en général opt-out, donc par défaut, la récolte est autorisée. (Sur ce blog, et c'est apparemment le cas de la plupart des serveurs HTTP, plus de la moitié des requêtes sont faites par des bots, mais pas forcément liés à l'IA, c'était déjà le cas avant les LLM.) On constate (cf. l'exposé « Consent in Crisis: The Rapid Decline of the AI Data Commons ») une tendance à la fermeture : la récolte devient de plus en plus difficile car de nombreux serveurs bloquent les accès qu'ils pensent dûs à un bot. Le Web tend donc à se fermer.

[Le RFC n'est pas clair sur ce point mais, pour moi, il est important de faire la différence entre les problèmes techniques et opérationnels posés par certains bots qui, qu'ils travaillent pour l'IA ou pas, « matraquent » avec excès les serveurs, et les problèmes politiques et financiers liés à l'utilisation qui est faite des données récoltées. Les problèmes techniques et opérationnels causés par des « bots fous » existaient bien avant les LLM. Par contre, les problèmes politiques (légitimité à réutiliser le contenu) et financiers (perte de revenus pour les ayant-droits, comme mentionné dans le RFC) sont plus spécifiques de l'IA. Le RFC ne parle pas vraiment des problèmes opérationnels posés par l'agressivité de certains bots - pas forcément liés à l'IA, d'ailleurs - mais la réunion IETF 123 à Madrid avait vu de très intéressants exposés à ce sujet.]

À l'heure actuelle, il est difficile de savoir ce qui est permis, au delà des simples consignes du robots.txt. Les gérants des serveurs n'ont pas de moyen standard et automatiquement analysable de faire connaitre leurs conditions d'utilisation, et les bots n'ont donc pas non plus de moyen de savoir ce qui est permis. [Il va de soi qu'il y a des bots qui, de toute façon, s'en foutent. Le travail de normalisation à l'IETF ne pourra concerner que les bots honnêtes et ne dispensera pas de mesurs de sécurité contre les malhonnêtes.]

Le RFC creuse certain aspects de la question. Par exemple, en section 2.1, le problème de la différence entre le moment du ramassage des données et celui de leur utilisation. Les consignes du serveur (comme le robots.txt) sont lues au moment du ramassage mais certains responsables de contenu voudraient exprimer des choix concernant l'utilisation, or celle-ci se fait à un autre moment, décorrélé du premier. Certaines récoltes, comme celle faite par Common Crawl, peuvent servir à de multiples usages et des consignes concernant le ramassage ne sont donc pas appropriées. Autre exemple que Common Crawl, on peut avoir une organisation qui gère un moteur de recherche du Web et développe un LLM, et qui utilise le même crawler pour les deux usages. Certains webmestres estiment que la première utilisation ne pose pas de problème (au bout du compte, cela ramènera du trafic sur leur site Web) mais s'opposent à la seconde car elle n'apportera pas de trafic, le LLM donnant des réponses qui suffiront à l'utilisateur.

Du point de vue technique, il faut aussi noter que le principe d'entrainement d'un LLM fait qu'on utilise toutes les données et, qu'une fois le modèle créé, il n'y a pas d'étiquetage spécifique de la source de telle ou telle réponse du LLM. (C'est pour cela que les LLM ont du mal à indiquer leurs sources.) Un webmestre qui souhaiterait dire « d'accord pour servir à l'entrainement des IA mais pas pour que ces IA aient un usage militaire, ou bien pas un usage commercial » ne le peut pas, en raison de cette limite technique. Et même si ce moyen existait, le gérant du LLM serat obligé de faire N modèles, pour toutes les permutations des différents critères (ou tout simplement d'exclure tous les contenus ayant une licence restrictive, ce qui limiterait la représentativité du corpus d'entrainement du modèle).

Enfin, les préférences changent dans le temps et celles exprimées au moment de la récolte des données peuvent ne pas être à jour lorsque les données seront utilisées pour l'entrainement d'un LLM.

Le problème est déjà compliqué si on suppose que tous les acteurs sont de bonne foi et respectent les règles. Mais, évidemment, la confiance ne règne pas, et pour de bonnes raisons. [Les entreprises capitalistes trichent, que ce soit celles qui entrainent les LLM ou bien celles des ayant-droits.] Il n'y a pas de moyen facile de vérifier le respect des préférences exprimées par les gérants du contenu. Et c'est d'autant plus inquiétant que les entreprises de l'IA n'ont pas vraiment de motivation pour respecter les règles : aucun risque de sanction [surtout compte-tenu des déclarations de Trump contre tout projet de régulation de l'IA]. Cette absence de confiance entraine l'utilisation importante de moyens techniques de blocage, comme de bloquer les adresses IP des bots connus. Il y a même un bot qui suggère cette solution :

119.28.89.249:58834 - - [21/Jan/2026:15:32:02 +0000] "GET /5153.xml HTTP/1.1" 200 6891 "-" "Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)" www.bortzmeyer.org TLS
  

L'atelier de l'IAB a passé du temps sur la question de l'attachement des préférences au contenu (section 2.3). Le robots.txt (RFC 9309) est très bien, très déployé et largement reconnu. Mais il manque de souplesse pour les gros sites qui souhaitent un système plus granulaire. Par exemple, si un site de vidéos souhaitait restreindre l'accès à certaines vidéos, la seule solution est de les placer dans un espace particulier (par exemple un répertoire distinct), et donc de devoir changer l'URL si la classification change. Et, comme le robots.txt est à la racine du site Web, il n'est pas sous le contrôle des créateurs de contenu qui ont accès à un espace dédié mais pas à la totalité du site. Si le CMS que vous utilisez permet des créations de contenu et des mises à jour décentralisées, où certaines personnes peuvent modifier une partie du site, regardez s'il permet à ces personnes d'influencer le robots.txt. Je suis preneur d'exemples.

Une autre solution (qui ne serait pas forcément exclusive du robots.txt mais complémentaire) serait d'inclure les préférences d'utilisation dans le contenu lui-même. C'est ce que permet l'élément HTML <meta> ou le format XMP pour les images. Des formats comme XML ou JSON permettraient certainement d'ajouter ces préférences d'utilisation, qui ont l'avantage de forcément voyager avec le contenu, contrairement au robots.txt. Évidemment, cela ne marchera pas si ces méta-données sont retirées par le programme de collecte (pas forcément pour des raisons malveillantes, cela peut être pour diminuer la taille des données). Et certains formats ne se prêtent pas à cette inclusion des préférences d'utilisation, comme le texte brut, ou comme les contenus qui ont plusieurs auteurs (pensez à un fil de discussion sur les réseaux sociaux).

Une autre solution serait de placer les préférences d'utilisation dans un registre, extérieur aux œuvres, comme cela se fait souvent pour, par exemple, la musique ou les photographies. C'est plus robuste que l'inclusion de métadonnées mais ça passe mal à l'échelle de l'Internet (les registres existants avaient été conçus pour des écosystèmes plus petits et relativement fermés).

Enfin, parmi les difficultés, il faut noter qu'exprimer préférences et conditions d'utilisation un peu fines nécessite de disposer d'un vocabulaire (par exemple pour décrire les différentes techniques qui sont regroupées sous le terme marketing et flou d'« IA ») et qu'il n'existe pas de vocabulaire standard. Ce serait un tâche difficile que d'en établir un (un travail est en cours, dans draft-ietf-aipref-vocab). Je me souviens d'une réunion IETF où il y avait eu un long débat sur la question de savoir si la traduction rentrait dans la catégorie « IA générative » (après tout, elle génère des textes…).

La section 3 du RFC, en conclusion, essaie de synthétiser et d'identifier les points sur lesquels l'IETF pourrait travailler. L'atelier avait un relatif consensus sur le fait que la situation actuelle est mauvaise et que le principal outil technique disponible, robots.txt, ne convient pas. Les pistes de travail discutées ont été :

• Améliorer robots.txt ou bien développer un meilleur système d'attachement aux sites Web,
• Définir des attachements pour les protocoles IETF (par exemple dans l'en-tête HTTP, HTML ou XML dépendant d'un autre organisme),
• Définition d'un vocabulaire commun (le groupe de travail IETF aipref y travaille),
• Description de comment les différentes techniques (attachées au site Web ou bien attachées au contenu) se combinent.

Par contre, le consensus était que les points suivants n'étaient pas du ressort de l'IETF ou ne pouvaient pas, pour l'instant, faire l'objet d'un travail concret :

• Faire respecter les directives données aux récoltants (les licences du logiciel libre ont un problème analogue),
• Développer des mécanismes de transparence de la récolte,
• Créer des registres des contenus,
• Identifier et authentifier les bots (à noter que Cloudflare a lancé cette idée, ce qui a donné naissance aux brouillons draft-meunier-web-bot-auth-architecture et draft-meunier-web-bot-auth-glossary).

Notez qu'un résumé de l'atelier avait été publié juste après. Et, sinon, vous pouvez regarder l'intéressant site Web « Dealing With Bots » et, sur les projets de contrôle de l'accès aux ressources et leurs risques, l'excellent article « No One Should Control the Internet After AI: Freedom to Build Cleopatra GPT ».

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.

Il y a au moins deux raisons de demander ces rapports :

• Comprendre pourquoi certains des messages qu'on envoie sont classés comme invalides alors qu'ils ne devraient pas l'être. On va donc analyser des rapports concernant des messages qu'on a réellement envoyés.
• Détecter les tentatives d'usurpation du domaine. On va donc analyser des rapports concernant des messages qu'on ne connaissait pas, et qu'un méchant a envoyés.

Notez qu'il existe aussi des rapports agrégés (RFC 9990, avec un format très différent, fondé sur XML) et qu'on demande parfois des rapports individuels parce qu'on note dans les rapports agrégés qu'il y a beaucoup d'erreurs et qu'on voudrait comprendre leur origine.

Le format normalisé ici dérive du format ARF (Abuse Reporting Format, RFC 6591), qui décrivait les rapports pour les problèmes SPF et DKIM. L'option ruf dans l'enregistrement DMARC (RFC 9989, section 4.7) indique à quelle adresse de courrier le rapport doit être envoyé. Voici par exemple l'enregistrement DMARC de afnic.fr :

dig +short _dmarc.afnic.fr TXT
"v=DMARC1; p=quarantine; pct=100; ruf=mailto:dmarc-feedback@afnic.fr; rua=mailto:dmarc-feedback@afnic.fr; fo=1"

Vous voyez le ruf ? Il indique que les rapports doivent être envoyés à dmarc-feedback@afnic.fr. Attention, j'ai écrit « doivent » mais, évidemment, les récepteurs de courrier ne sont pas obligés d'envoyer ces rapports, qui peuvent leur coûter des ressources et poser des problèmes de vie privée.

Pour DMARC, notre RFC ajoute au format du RFC 6591 les champs (section 4, ils sont listés dans un registre IANA) :

• Identity-Alignment:, qui liste les mécanismes d'authentification où il n'y a pas d'alignement avec l'expéditeur,
• Delivery-Result:,
• DKIM-Domain:, et quelques autres au sujet de DKIM,
• SPF-DNS:.

Il y a un autre piège avec les rapports, c'est la possibilité d'indiquer dans ruf l'adresse de quelqu'un d'autre, pour l'embêter avec beaucoup de rapports qui ne le concernent pas. La section 4 du RFC 9990 explique les précautions que devrait prendre un receveur de courrier avant d'envoyer un rapport vers une adresse qui n'est pas dans le domaine concerné, comme de tester le sous-domaine _report._dmarc. (Dans l'exemple afnic.fr plus haut, il n'y avait pas de problème, le destinataire des rapports est dans le domaine concerné.)

J'ai mentionné un peu plus haut la question de la vie privée. Les rapports détaillés, contrairement à leurs copains agrégés du RFC 9990, peuvent être très indiscrets, notamment parce qu'ils contiennent souvent des données personnelles, par exemple dans les champs indiquant l'expéditeur et le destinataire. Et il ne suffit pas de se dire « Bon, de toute façon, le gestionnaire du système envoyeur avait accès au message quand il est parti de son système » car le message a pu être transmis et re-transmis et le rapport donnera des informations sur des destinataires finaux. Une section 7, trés détaillée, couvre donc ce problème. Elle note par exemple que beaucoup de gros receveurs de courrier n'envoient pas du tout de rapport individuel, seulement des rapports agrégés. Et elle recommande que, même si on envoie les rapports, on en supprime les éléments les plus sensibles (voir le RFC 6590).

Enfin, à envoyer un rapport par message, on noiera l'expéditeur supposé sous des rapports qui concerneront des spams envoyés en nombre. Donc, prudence.

Un point amusant, que je vois pour la première fois dans un RFC : ce RFC 9991 recommande de modifier les URL présents dans les rapports en remplaçant http par hxxp. Cette convention est assez courante dans le monde de la sécurité Internet, pour éviter qu'un humain ne clique trop vite sur un lien malveillant.

L'annexe A du RFC donne un exemple de rapport, je ne montre ici que la partie MIME qui concerne le rapport proprement dit¸:

   --=_mime_boundary_
   Content-Type: message/feedback-report
   Content-Transfer-Encoding: 7bit

   Feedback-Type: auth-failure
   Version: 1
   User-Agent: DMARC-Filter/1.2.3
   Auth-Failure: dmarc
   Authentication-Results: gen.example;
     dmarc=fail header.from=consumer.example
   Identity-Alignment: dkim
   DKIM-Domain: consumer.example
   DKIM-Identity: @consumer.example
   DKIM-Selector: epsilon
   Original-Envelope-Id: 65E1A3F0A0
   Original-Mail-From: author=gen.example@forwarder.example
   Source-IP: 192.0.2.2
   Source-Port: 12345
   Reported-Domain: consumer.example
  

Le message prétend venir de consumer.example mais aucune signature DKIM n'est valide, sans doute suite à des modifications chez forwarder.example ou bien parce que la clé DKIM n'a pu être récupérée dans le DNS.

Apparemment, OpenDKIM est capable de générer ces rapports, mais je n'ai pas testé.

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é).

Revenons sur les problèmes de sécurité du courrier électronique. Un message typique, tel que normalisé par le RFC 5322, comprend dans son en-tête ce genre d'informations :

Date: Wed, 18 Mar 2026 17:28:36 +0800
From: Jiankang Yao <yaojk@cnnic.cn>
To: 125attendees@ietf.org
Subject: [125attendees] Wednesday 8:00 pm, Shenzhen light show for IETF 125
X-Mailer: iPhone Mail (21D61)
[et bien d'autres]    

  

Une qui nous intéresse particulièrement est l'expéditeur. Cette notion est plus compliquée qu'il n'y parait (il y a plusieurs définitions possibles de « expéditeur ») mais pour DMARC, c'est simple : le champ qui nous intéresse est uniquement le From: (section 3.6.2 du RFC 5322). C'est en effet celui qui est typiquement affiché par les MUA, et c'est celui que DMARC va protéger. On l'appelle souvent RFC5322-From pour le distinguer de celui qui apparait dans l'enveloppe du courrier, le RFC5321-From (et qui n'est pas montré dans mon exemple).

Les techniques d'authentification existantes avant DMARC, SPF (RFC 7208) et DKIM (RFC 6376), n'authentifient pas ce champ mais d'autres (le RFC5321-From pour SPF et le domaine indiqué dans la signature pour DKIM), qui ne sont pas en général affichés à l'utilisateurice final·e. DMARC va permettre d'utiliser ces deux techniques, SPF et DKIM, pour les appliquer à l'expéditeur (RFC5322-From). Un test DMARC réussi signifie que SPF ou DKIM a réussi mais aussi que le domaine authentifié par SPF ou DKIM est le même que celui présent dans le From: ; on parle d'alignement du nom de domaine. Cela ne va pas de soi car il y a de nombreux usages légitimes du courrier où ces domaines ne sont pas alignés, et DMARC casse donc ces usages.

Dans les exemples de messages reçus après traitement par DMARC, on va regarder les champs Authentication-Results. Normalisés dans le RFC 8601, ils sont ajoutés par le récepteur et indiquent le résultat d'une technique d'authentification. Ici, un exemple où SPF et DKIM ont marché (tous les exemples ici sont réels, issus de mes boites aux lettres):

Authentication-Results: mail.bortzmeyer.org; dmarc=pass (p=quarantine dis=none) header.from=afnic.fr
Authentication-Results: mail.bortzmeyer.org;
        dkim=pass (2048-bit key; secure) header.d=afnic.fr header.i=@afnic.fr header.a=rsa-sha256 header.s=afnic-20240601
        header.b=bdGM6W8o;
        dkim-atps=neutral
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=afnic.fr
        (client-ip=2001:67c:2218:10::51:1; helo=mx1.nic.fr; envelope-from=quelqu.un@afnic.fr; receiver=bortzmeyer.org)

Le domaine afnic.fr a bien été authentifié, à la fois par SPF et par DKIM, et DMARC passe donc (le champ From: n'est pas montré ici mais il indiquait bien une adresse @afnic.fr).

Il est également important de se souvenir que DMARC ne fait qu'authentifier le domaine, il ne garantit pas que le message soit sincère, sûr, utile ou quoi que ce soit d'autre. Si on reçoit un message de Trump, on peut prouver qu'il vient bien de whitehouse.gov mais il sera quand même certainement mensonger. C'est pour cela qu'il est absurde, comme on le lit dans certains forums, de dire « je ne comprends pas, j'ai bien mis un enregistrement DMARC et mes messages finissent quand même dans la boite Spam » : les spammeurs font du DMARC, eux-aussi.

L'inverse est vrai aussi, un message légitime et désiré peut parfaitement échouer au test DMARC, d'autant plus, que, comme indiqué plus haut, DMARC casse plusieurs usages légitimes du courrier. Il vaut donc mieux ne pas refuser un message uniquement sur la base d'un échec DMARC mais traiter cet échec comme une indication parmi d'autres. Ce RFC 9989 insiste sur ce point (notamment sa section 7), en mentionnant également le RFC 7960, qui détaille les problèmes venant de l'utilisation de DMARC.

La section 2 du RFC détaille le cahier des charges de DMARC. Comme avec toutes les solutions de sécurité, il faut garder en tête ce cahier des charges lorsqu'on évalue DMARC. Aucune solution de sécurité n'est parfaite : elles collent simplement plus ou moins bien à leur cahier des charges. Celui-ci, en résumé, est :

• Permettre aux gérants de noms de domaine d'annoncer leur politique d'authentification du courrier et leurs souhaits quant au traitement du courrier qui ne passerait pas cette authentification.
• Fonctionner dans le contexte de l'Internet (donc, sans autorité centrale).
• Traiter uniquement les cas où le message malveillant copie exactement un nom de domaine qu'on gère. En d'autres termes, les usurpations utilisant des noms qui ressemblent (goog1e.com au lieu de google.com) sont hors-sujet.
• Authentifier uniquement le nom de domaine qui est dans l'adresse (RFC 5322, section 3.4). En d'autres termes, dans un From: « Emmanuel Macron <emmanuel5561@gmail.com>, DMARC ne se préoccupe que du gmail.com, pas du emmanuel5561.
• Authentifier uniquement l'adresse, pas le nom affiché (« Emmanuel Macron » dans l'exemple ci-dessus). La section 11.4 rappelle ce point très important.

Un bon cahier des charges a une autre section très importante : celle des non-objectifs, des choses qu'on n'essaie pas de faire. (Regardez les documents commerciaux : ils n'ont jamais l'honnêteté de lister ce qu'ils ne font pas.) Pour DMARC :

• Il ne dit évidemment rien sur les domaines qui ont choisi de ne pas avoir d'enregistrement DMARC dans le DNS. Dit autrement, DMARC est opt-in.
• Il n'essaie pas de s'occuper des autres informations présentes dans l'en-tête (comme Reply-To: ou Date:).
• Il ne s'occupe pas des tricheries sur le nom affiché, comme dans l'exemple « Emmanuel Macron » plus haut (ou bien, tiré de ma boite Spam From: "amendes.gouv.fr" <amendes-gouv-nepasrepondre.C9717A5D-EA39-D865-765A6C98B4A0BB03@therugest.com>). Tant pis pour ceux et celles qui s'obstinent à utiliser un logiciel qui, par défaut, n'affiche que ce nom (Outlook fait encore ça). Relisez la section 11.4 du RFC.
• Et naturellement, DMARC ne s'occupe pas du contenu du message, qu'il soit mensonger (« je suis l'ex-ministre des finances du Nigéria ») ou malveillant (logiciel qui va tenter d'exploiter une faille de sécurité pour prendre le contrôle de votre ordinateur).

Par exemple, voici un spam, prétendant venir de l'ANTAI mais qui passe tous les tests (le nom de domaine dans l'adresse n'a rien à voir avec l'ANTAI mais beaucoup d'utilisateurs n'y feront pas attention, et ce nom avait bien un enregistrement DMARC) :

Authentication-Results: mail.bortzmeyer.org; dmarc=pass (p=quarantine dis=none) header.from=rtm.gov.my
Authentication-Results: mail.bortzmeyer.org;
        dkim=pass (2048-bit key; secure) header.d=rtm.gov.my header.i=@rtm.gov.my header.a=rsa-sha256 header.s=rtm
        header.b=MaKApt+s;
        dkim-atps=neutral
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=rtm.gov.my; s=rtm; t=1775231898; x=1775836698; darn=bortzmeyer.org;
        h=content-transfer-encoding:mime-version:subject:message-id:to:from
        :date:from:to:cc:subject:date:message-id:reply-to;
        bh=L6c3f6fDBrQyBjkO1RiiF3vHHNmYjLDd4A1urn+cNJg=;
        b=MaKApt+s0vgkVsgh3VoFE0/MgCt8ilWkghyQKUbj2NnhgInADkR8G3aW0UbklkuDDV
	…
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=rtm.gov.my
        (client-ip=2607:f8b0:4864:20::f64; helo=mail-qv1-xf64.google.com; envelope-from=antai.gouv.fr@rtm.gov.my;
        receiver=bortzmeyer.org)
Subject: ACTION REQUISE SOUS 24H
From: "Antai.gouv.fr" <Antai.gouv.fr@rtm.gov.my>

La section 3 du RFC décrit les termes utilisés par DMARC, entre autres :

• Domaine de l'auteur : ce qui est après l'arobase dans l'adresse indiquée par le champ From: de l'en-tête (rappel : pas celui de l'enveloppe).
• Domaine DKIM : celui indiqué par le paramètre d= dans la signature DKIM (rappel : le domaine DKIM peut n'avoir aucun rapport avec l'adresse de l'en-tête ou avec celle de l'enveloppe).
• Domaine SPF : ce qui est après l'arobase dans l'adresse indiquée par le champ From de l'enveloppe (rappel : pas celui de l'en-tête). Dans le contexte de DMARC, ce terme ne s'applique pas au domaine indiqué dans la commande EHLO (ou HELO) de SMTP.
• Titulaire du domaine : la personne physique ou morale qui décidé d'enregistrer un nom de domaine et qui le gère ensuite.
• Domaine organisationnel : le domaine au sommet du sous-arbre qui a la même administration (le RFC 5598 est une bonne lecture ici). Ainsi, bortzmeyer.org est le domaine organisationnel de mail.bortzmeyer.org. En pratique, c'est souvent le domaine enregistré du RFC 9499, domaine qui a été enregistré auprès d'un registre.
• Suffixe public : domaine où le public peut enregistrer un sous-domaine, par exemple .fr ou eu.org. Ainsi, dans mail.foobar.eu.org, foobar.eu.org est le domaine organisationnel et eu.org le suffixe public, ou domaine d'enregistrement.

Armé de cela (mais il y a d'autres termes, que je présenterai au fur et à mesure), on peut passer à la section 4, qui explique les concepts importants.

DMARC permet à un titulaire de domaine d'annoncer sa politique d'authentification d'un domaine de l'auteur d'un courrier. On n'authentifie donc que le domaine, pas toute l'adresse (je l'ai déjà dit mais c'est important). Et DMARC ne s'intéresse qu'à ce qu'il appelle le domaine de l'auteur, donc le From: dans l'en-tête (également appelé « RFC5322.From »). DMARC annonce juste une politique, l'authentification est faite avec SPF (RFC 7208) ou DKIM (RFC 6376).

Un concept essentiel dans DMARC est celui d'alignement. Il y a alignement quand le domaine authentifié par SPF (celui de l'enveloppe, le « RFC5321.From ») ou par DKIM (celui indiqué dans le d= de la signature) coïncide avec le domaine de l'auteur (celui du From: de l'en-tête). Plus précisément, il peut y avoir un alignement strict (les deux noms de domaine sont identiques) ou relâché (les deux noms sont dans le même domaine organisationnel). Le choix se fait dans l'enregistrement DMARC publié.

Justement, on le publie où ? Via le DNS, dans un enregistrement de type TXT, publié dans le sous-domaine _dmarc, par exemple :

% dig +short _dmarc.proton.me TXT
"v=DMARC1; p=quarantine; fo=1; aspf=s; adkim=s;"
  

On bénéficie ainsi de toute l'infrastructure, très fiable et éprouvée, du DNS. Ce sous-domaine _dmarc figure dans le registre IANA des noms commençant par un trait bas, créé par le RFC 8552.

Au passage, si vous voulez voir (ou enregistrer), sur un serveur DNS faisant autorité, uniquement les requêtes DNS pour le sous-domaine _dmarc, dnscap permet de le faire facilement :

% dnscap -g -x _dmarc   
  

(Je triche un peu, le -x attrape en effet davantage que cela mais ça suffit en première approximation.)

Le format exact de l'enregistrement DMARC utilise des doublets clé=valeur, comme celui de DKIM. (Sa description formelle, en ABNF - RFC 5234 - est dans la section 4.8.) Les clés possibles figurent dans un registre IANA. Les plus courantes sont :

• v : c'est obligatoirement le premier doublet clé=valeur et il indique la version de DMARC, actuellement DMARC1.
• p : c'est la clé la plus importante, celle qui indique la politique à appliquer aux messages qui ne passent pas la validation DMARC. Une valeur reject indique que le titulaire du domaine recommande le rejet des messages invalides (cela ne peut être qu'une recommandation, car le récepteur du courrier reste évidemment libre de sa politique). quarantine recommande une mise en attente quelque part (un dossier « peut-etre-spam » par exemple). Enfin, none indique qu'on recommande de ne rien faire. Cela peut être utilisé quand on craint les conséquences de DMARC sur certains usages (cf. RFC 7960) mais qu'on pense que certains récepteurs vont mal traiter les messages des domaines sans DMARC. Ou bien cela peut être utile dans certains audits « de sécurité » qui demandent un enregistrement DMARC, n'importe lequel. Enfin, un p=none peut être utilisé lors d'un déploiement progressif de DMARC, quand on veut juste tester, avant de publier une politique plus fasciste. Comme DMARC permet de solliciter l'envoi de rapports d'erreur, un p=none peut être accompagné d'une telle sollicitation.
• sp : comme p mais pour les sous-domaines du domaine qui a l'enregistrement DMARC. Les valeurs possibles sont les mêmes que pour p.
• np : nouveauté, initialement décrite dans le RFC 9091. C'est le traitement à appliquer aux sous-domaines non-existants du domaine pour lequel une politique DMARC est publiée. Les valeurs possibles sont les mêmes que pour p.
• ruf : c'est ainsi qu'on sollicite l'envoi de rapports d'erreur. On indique les URI où envoyer ces rapports (souvent des URI de plan mailto:, pour demander des rapports par courrier). Le format des rapports est spécifié dans les RFC 9991, RFC 6651 et RFC 6552. ruf demande un rapport par message invalide, rua permet de demander des rapports agrégés. Leur format figure dans le RFC 9990.
• psd : nouveauté de notre RFC, s'il a la valeur y, il indique que le domaine est un suffixe public (PSD : Public Suffix Domain), c'est-à-dire un domaine dont les sous-domaines peuvent être délégués à d'autres entités (comme c'est le cas de .re ou eu.org).
• fo : diverses options pour la génération de rapports d'erreur.
• adkim et adpf : tous les deux peuvent prendre la valeur s (strict) ou r (relâché, ou laxiste). Ils indiquent si l'alignement avec l'identificateur authentifié par DKIM ou SPF doit être strict (les deux identificateurs sont rigoureusement identiques) ou relâché (l'identificateur authentifié peut se contenter d'être dans le même domaine enregistré que celui qui a un enregistrement DMARC). Par défaut, DMARC est laxiste. Notez que cela permet à quelqu'un qui peut utiliser un sous-domaine de se faire authentifier comme étant dans l'apex (section 11.8 du RFC). Demander un alignement strict résout ce problème (mais impose que vous controliez bien les sous-domaines).

Les clés inconnues doivent être ignorées, ce qui permet d'en ajouter de nouvelles sans tout casser. La politique pour un éventuel ajout est « Spécification nécessaire » (RFC 8126).

On a parlé du domaine organisationnel, l'apex du domaine testé par DMARC. C'est en fait une notion administrative, pas technique, ce qui fait que ce domaine organisationnel n'est pas évident à identifier dans le DNS. Pour le trouver, l'ancien RFC, le RFC 7489, suggérait de faire appel à une liste de suffixes publics, comme la PSL (rappel : il n'existe pas de liste officielle). Notre nouveau RFC suggère une autre méthode, en remontant l'arbre des noms de domaine. On commence par le domaine qu'on veut authentifier, et, si on n'y trouve pas de politique DMARC, on essaie son domaine parent et ainsi de suite, jusqu'à ce qu'on trouve un enregistrement DMARC. Ainsi, pour truc.machin.example.com, on essaiera successivement _dmarc.truc.machin.example.com, _dmarc.machin.example.com, _dmarc.example.com et enfin _dmarc.com. La dernière requête permet donc au registre de .com de définir une politique DMARC qui s'appliquera à tous les domaines sans politique DMARC. C'est très dangereux, pour les raisons expliquées dans le RFC 1535 mais cela permet de se passer de liste de suffixes publics, et c'est plus souple pour le cas des grosses organisations, qui peuvent avoir des politiques DMARC dans des sous-domaines qui ne sont pas délégués.

Notez que l'éventuelle présence de la clé psd va compliquer les choses mais je n'ai pas vraiment le courage de détailler ici l'algorithme complet.

Maintenant, voyons quels sont les acteurs d'un déploiement de DMARC. D'abord, le titulaire du domaine qui envoie des messages. Il doit publier un enregistrement SPF à l'apex du domaine. Il doit signer les courriers sortants avec DKIM (ce qui implique de publier les clés publiques DKIM dans le DNS). Notez que DMARC n'a pas besoin de SPF et de DKIM, un seul des deux suffit mais, bon, autant tout faire. Il a intérêt à créer une boite dédiée pour recevoir les rapports sur les messages invalides. Le titulaire doit enfin publier dans le DNS l'enregistrement DMARC (celui qui commence par _dmarc). Au début, on utilise typiquement une politique indulgente (p=none). Puis on teste.

Comment teste t-on ? En lisant les rapports indiquant des messages invalides (RFC 9990 et RFC 9991). Les rapports agrégés sont du XML, assez lisibles par un humain mais, en pratique, on préférera typiquement utiliser un programme qui les synthétisera dans une forme plus lisible. (Je n'utilise pas actuellement un tel programme, car je n'en ai pas trouvé. Il faut qu'il tourne en local - pas question de confier les rapports à un tiers - et ne nécessite pas d'installer toute une batterie de cuisine PHP et MariaDB.) Une fois qu'on a trouvé les problèmes (une application oubliée dans un coin qui envoie des courriers sans passer par les serveurs centraux…) et qu'on les a corrigés, on peut durcir la politique (p=quarantine, par exemple). Il est raisonnable d'attendre plusieurs semaines, voire mois, pour être sûr d'avoir vu tous les problèmes.

(Et si vous êtes gérant d'un suffixe public - - un domaine sous lequel d'autres entités peuvent enregistrer des noms, demandez-vous si vous devez publier du DMARC avec psd=y. Ce n'est pas obligatoire, cf. section 5.2.)

Et le récepteur du courrier, que doit-il faire ? Il extrait du message le domaine de l'auteur. Il cherche s'il y a un enregistrement DMARC. Il exécute les tests SPF et DKIM. S'il récupère un ou plusieurs domaines authentifiés, il vérifie l'alignement (strict ou relâché). Si au moins un domaine authentifié est aligné avec le domaine de l'auteur, le test DMARC est un succès. Sinon, c'est un échec. Notez bien qu'il n'est pas nécessaire que SPF et DKIM réussissent tous les deux. Si le test DMARC se termine en échec, on applique un traitement, qui dépend de la politique suggérée dans l'enregistrement DMARC, et de la politique propre du receveur. Voici un exemple où DMARC dit que tout s'est bien passé :

From: "Projet Arcadie" <admin@projetarcadie.com>
Authentication-Results: mail.bortzmeyer.org; dmarc=pass (p=none dis=none) header.from=projetarcadie.com
Authentication-Results: mail.bortzmeyer.org;
        dkim=pass (2048-bit key; unprotected) header.d=projetarcadie.com header.i=@projetarcadie.com header.a=rsa-sha256 header.s=alternc
        header.b=plrnZlsJ;
        dkim=pass (2048-bit key) header.d=projetarcadie.com header.i=@projetarcadie.com header.a=rsa-sha256 header.s=alternc
        header.b=m84VgM5U;
        dkim-atps=neutral
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=projetarcadie.com (client-ip=91.194.60.11;
        helo=arcadieweb01.octopuce.fr; envelope-from=admin@projetarcadie.com; receiver=bortzmeyer.org)

  

Ici, il y avait un enregistrement SPF (qui autorise l'émetteur SMTP donc cela suffit), deux signatures DKIM, toutes les deux corrects, il y a alignement strict, et donc DMARC passe, il n'y a aucun doute que le domaine émetteur était bien projetarcadie.com. (La politique DMARC était p=none donc un éventuel échec n'aurait sans doute pas eu beaucoup de conséquences.)

Ici, DKIM a échoué (pourquoi ? mystère mais c'est peut-être la faute de SpamAssassin qui a modifié le sujet, il faudrait que je vérifie ma configuration) mais SPF réussit (le message vient bien de Gmail) donc DMARC est content (il s'agissait bien d'un spam, tentative d'escroquerie financière) :

Authentication-Results: mail.bortzmeyer.org;
        dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com
        header.a=rsa-sha256 header.s=20230601 header.b=K6F+sj7y;
        dkim-atps=neutral
Authentication-Results: mail.bortzmeyer.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com
        (client-ip=2a00:1450:4864:20::133; helo=mail-lf1-x133.google.com; envelope-from=mrsbalex@gmail.com;
        receiver=sources.org)
From: "Mr. Mike Christopher" <mrsbalex@gmail.com>

Et ici, un échec, SPF est correct, il n'y a pas de signature DKIM et il n'y a pas d'alignement des domaines, la tentative du spammeur pour se faire passer pour saison.co.jp échoue :

From: 株式会社クレディセゾン <admin@saison.co.jp>
Authentication-Results: mail.bortzmeyer.org; dmarc=fail (p=none dis=none) header.from=saison.co.jp
Authentication-Results: mail.bortzmeyer.org; spf=pass (sender SPF authorized) smtp.mailfrom=zh-cht-jjb.com (client-ip=34.130.185.194;
        helo=zh-cht-jjb.com; envelope-from=admin@zh-cht-jjb.com; receiver=bortzmeyer.org)

  

Et ici, l'émetteur tente de faire croire qu'il vient de Gmail mais l'enregistrement SPF de Gmail se termine par un ~all, son adresse IP n'y est pas listée et il n'y a pas de signature DKIM dans le message. Même pas besoin de tester l'alignement puisqu'il n'y a pas de domaine authentifié du tout :

From: Axel.Bouvier <mailrmicro+Axel.Bouvier@gmail.com>
Authentication-Results: mail.internatif.org; dmarc=fail (p=none dis=none) header.from=gmail.com
Authentication-Results: mail.internatif.org; spf=softfail (domain owner discourages use of this host)
        smtp.mailfrom=gmail.com (client-ip=78.246.109.210; helo=gmail225.com;
        envelope-from=mailrmicro+axel.bouvier@gmail.com; receiver=internatif.org)

  

De nombreux autres exemples, avec succès ou échec, figurent dans l'annexe B du RFC.

C'est pas mal si le récepteur de courrier qui fait tourner DMARC en profite pour générer les rapports (RFC 9991), s'ils sont demandés (par un ruf ou un rua dans l'enregistrement DMARC de l'envoyeur). Néanmoins, le RFC note qu'il peut ne pas le faire, s'il craint pour la vie privée (cf. section 10) ou tout simplement si ça lui consomme trop de ressources.

D'ailleurs, le RFC insiste bien sur un point que j'avais déjà mentionné : la décision finale (de livrer le message, ou de le mettre dans le dossier Spam ou de le jeter) revient toujours au destinataire (section 5.4). Celui-ci applique la politique qu'il veut. Il serait ridicule de croire que, parce qu'on a SPF, DKIM et DMARC bien configurés, nos messages seraient systématiquement livrés. Après tout, un spammeur peut en faire autant.

À l'inverse, un récepteur peut parfaitement décider d'acheminer jusqu'à ses utilisateurices un message qui échoue aux testes DMARC, par exemple parce qu'il a lu le RFC 7960 (et la section 7.4 de notre RFC) et qu'il sait que DMARC échoue dans des cas d'usage pourtant légitimes, notamment les listes de diffusion. DMARC fournit de la traçabilité et de la responsabilité, il n'est pas un oracle tout-puissant sur l'authenticité du message.

La section 7 du RFC est surtout intéressante pour les historien·nes et pour les technicien·nes qui veulent comprendre les choix faits par DMARC. C'est un pot-pourri de diverses discussions.

D'abord, SPF. SPF a été conçu pour être utilisable pendant la session SMTP, parfois avant même que l'en-tête du message ait été transmis. Une politique SPF « dure » (se terminant en -all) peut amener au rejet du message avant que DMARC n'ait été évalué. Ainsi, si un message échoue en SPF mais réussit en DKIM, normalement, DMARC réussirait. Mais, si le test SPF mène à un rejet dès la session SMTP, le message n'arrivera pas. Attention donc en configurant vos enregistrements SPF. (Relisez les « M3AAWG Best Practices for Managing SPF Records » et « M3AAWG Email Authentication Recommended Best Practices ».)

Et à propos de rejet précoce (dans le cours de la session SMTP, avant d'avoir accepté le message) : le RFC recommande cette méthode car elle évite la génération d'un avis de non-remise (RFC 3464), avis qui irait sans doute à un innocent si l'adresse était usurpée. Deux façons de mettre en œuvre ce rejet précoce, en renvoyant un code d'erreur (commençant par 5 RFC 5321, section 4.2.5) au client SMTP, qui saura ainsi que son message a été refusé, ou, plus méchamment, en prétendant que le message a bien été reçu (code commençant par 2) mais en le jetant silencieusement. La deuxième solution est évidemment horrible (le serveur SMTP ment, l'émetteur ne sait pas ce qui s'est passé, le déboguage devient très difficile) mais elle est parfois nécessaire pour éviter le backscatter, l'envoi de messages d'erreur à un innocent, une des plaies du spam qui usurpe votre adresse. Et elle évite de donner des informations à quelqu'un qu'on estime être un usurpateur.

Contrairement à ce qu'on voit dans certains articles pro-DMARC imprudents qui promeuvent DMARC sans insister sur ses limites et ses faiblesses, notre RFC précise bien qu'il y a des cas où DMARC pose problème (sections 7.3 et 7.4). Par exemple, citant le RFC 7960, il rappelle que DMARC peut casser des cas d'usage légitimes comme les adresses d'anciens élèves que certaines universités fournissent (en faisant suivre automatiquement le courrier à l'adresse actuelle), comme des alias où le courrier vers une même adresse est distribuée à plusieurs personnes, qui ne sont pas forcément dans le même domaine, ou comme les listes de diffusion. Pour les deux premiers cas, des solutions relativement simples existent (réécrire l'enveloppe pour ne pas casser SPF, ce qui est de toute façon une bonne pratique car l'envoyeur du message ne saurait pas quoi faire si la vraie adresse finale ne marcherait pas) et ne pas du tout toucher au message, pour éviter de casser DKIM), pour les listes de diffusion, c'est plus délicat. En pratique, plusieurs gestionnaires de liste adoptent la solution très intrusive de réécrire le champ From: comme ici dans ce message envoyé à une liste de l'OARC (le vrai From: a été reporté en Reply-To:) :

Authentication-Results: nic.fr;
        spf=pass smtp.mailfrom=dns-operations-bounces@dns-oarc.net;
        dmarc=pass header.from=dns-oarc.net
Reply-To: Walter Russo <walter@secureme.it>
From: Walter Russo via dns-operations <dns-operations@dns-oarc.net>

Le problème est évidemment particulièrement sérieux si on a une politique DMARC restrictive (p=reject) et le RFC conseille fortement dans ce cas de systématiquement signer avec DKIM, pour éviter de compter sur le seul SPF (qui sera cassé par les serveurs qui font suivre un message sans réécrire l'enveloppe). Et il rappelle aux récepteurs de courrier qu'il est très imprudent de rejeter un message sur la seule base de DMARC. Ces consignes, qui ne sont pas toujours respectées par les serveurs actuels, sont cruciales pour le bon fonctionnement du courrier. Le RFC note bien ce problème de filtrage excessif et explique que c'est ce qui a mené plusieurs gestionnaires de liste à tripoter le champ From:, par exemple en changeant le vrai champ bob@example.com en un bob=example.com@user.somelist.example, où on peut toujours retrouver la vraie adresse. (On ajoute également parfois un Reply-To: indiquant la vraie adresse de l'expéditeur, comme dans l'exemple ci-dessus.) Le RFC n'approuve pas cette modification mais note qu'elle est répandue et qu'il faut faire avec. Il existe des solutions techniquement plus propres comme le ARC du RFC 8617 mais que presque personne n'utilise.

En résumé, pour faire du DMARC complet, l'émetteur du courrier devrait idéalement :

• Produire des messages qui auront un identificateur SPF aligné avec le domaine de l'auteur (une exigence qui me parait très excessive),
• produire des messages avec une signature DKIM valide et alignée,
• configurer une boite aux lettres qui recevra les rapports,
• publier l'enregistrement DMARC (je rajoute : après avoir soigneusement testé les trois points précédents),
• ne pas compter sur le seul SPF.

Et le receveur devrait idéalement :

• Tester s'il y a un enregistrement DMARC pour le domaine de l'auteur,
• tester s'il y a des identificateurs authentifiés par SPF ou DKIM,
• tester si au moins l'un d'entre eux est aligné avec le domaine de l'auteur,
• déterminer ainsi si le résultat final est pass ou fail,
• envoyer des rapports, si demandé,
• ne pas rejeter des messages juste parce qu'il y a eu un échec DMARC, même si la politique de l'émetteur est p=reject.

La section 11 du RFC creuse les questions de sécurité. Que faut-il savoir pour utiliser DMARC de manière sûre ? D'abord, DMARC est évidemment dépendant des mécanismes d'authentification utilisés, SPF et DKIM (le groupe de travail IETF avait même envisagé de supprimer SPF, considéré comme trop permissif). Si vous publiez votre clé privée DKIM, DMARC ne pourra rien pour vous. Et SPF, DKIM et DMARC dépendent tous les trois du DNS donc il est crucial de gérer ses serveurs DNS sérieusement. Malheureusement, les RFC sur ces trois techniques n'imposent pas DNSSEC (RFC 9364) mais ils devraient : sans DNSSEC, l'envoi de fausses informations dans le DNS est plus facile. Compter sur SPF, DKIM et DMARC sans avoir DNSSEC me semble peu sérieux mais, bon, le vrai but de la cybersécurité est de réussir l'audit de conformité, pas d'améliorer la sécurité concrète. D'autre part, l'examen du trafic DNS (qui n'est pas limité aux deux parties qui s'envoient du courrier) donne des informations sur le trafic. Utiliser DoT (RFC 7858) ou DoH (RFC 8484) peut donc être une bonne idée.

Comme toujours en ingéniérie, d'autres solutions techniques auraient été possibles. L'annexe A de notre RFC examine certaines de ces alternatives et explique pourquoi elles n'ont pas été retenues. Ainsi, on aurait pu utiliser S/MIME (RFC 8551) pour signer le message, ajoutant cette technique à SPF et DKIM. Mais S/MIME a un cahier des charges différent de celui de DMARC, il vise plutôt à une authentification de bout en bout du message entier. Et puis il faut bien constater qu'en dehors de quelques environnements bureaucratiques fermés, personne n'utilise S/MIME. C'est en partie dû à la nécessité d'une PKI, dont le RFC note qu'elle a été souvent promise mais ne s'est jamais matérialisée. (Curieusement, le RFC ne cite pas OpenPGP - RFC 9580 - qui est pourtant nettement plus utilisé que S/MIME.)

Une autre décision de conception cruciale de DMARC est le fait d'accepter n'importe quelle technique d'authentification ; SPF ou DKIM, c'est pareil pour lui. Il a pourtant été souvent proposé de permettre au titulaire du domaine de spécifier, dans l'enregistrement DMARC, de préciser qu'on ne veut que SPF, ou que DKIM. Mais DMARC est assez compliqué comme cela et la décision a finalement été de permettre l'une ou l'autre des méthodes d'authentification. Débrouillez-vous pour qu'au moins une (et de préférence les deux) fonctionne.

Un point essentiel de DMARC est qu'il authentifie l'expéditeur (plus exactement son alignement) en considérant que l'expéditeur est indiqué par le champ From: de l'en-tête. Cela casse bien des usages légitimes (comme les listes de diffusion). Ne serait-il pas préférable d'authentifier un champ plus technique comme Sender: (RFC 5322, section 3.6.2) ? Cela avait même été spécifié dans le RFC 4870, puis retiré. Finalement, le choix a été de se concentrer sur From: puisqu'il est le seul à être toujours montré à l'utilisateur. (SPF, comme DKIM, peuvent authentifier un identificateur que l'utilisateur ordinaire ne voit pas.)

Notre RFC 9989 introduit une nouvelle clé, np, qui spécifie la politique à appliquer aux sous-domaines non-existants du domaine authentifié. Cela soulève le problème de la définition de non-existant. Le RFC dit que cela inclut les réponses NXDOMAIN (No Such Domain), évidemment, mais pas forcément les réponses NOERROR où la section Réponses est vide, car le nom existe mais ne contient ni enregistrement MX, ni enregistrement d'adresse (A ou AAAA). Ce test de la présence de certains types d'enrgeistrement est déjà couramment utilisé en pratique (il n'y a aucune raison d'accepter du courrier d'un domaine qui ne permettrait pas les réponses) mais le RFC ne l'impose pas. Et, sinon, le RFC rappelle que, si une requête pour un domaine renvoie NXDOMAIN, tous ses sous-domaines n'existent pas non plus (RFC 8020).

Évidemment, un débat ancien et récurrent pour DMARC est celui des frontières organisationnelles. Comment sait-on si cis.cnrs.fr dépend de la même autorité que cnrs.fr (ou bien pick.eu.org et eu.org). Il n'y a pas de réel moyen de trouver cette information dans le DNS. (On peut trouver les frontières techniques en demandant l'enregistrement de type SOA. Mais cela ne donne pas les frontières administratives. gouv.fr n'est pas géré par la même organisation que fr, même s'ils sont dans la même zone.) Des efforts ont été faits à l'IETF pour résoudre ce problème mais sans résultat. L'ancien RFC DMARC, le RFC 7489 suggérait d'utiliser une liste de suffixes d'enregistrement mais notre RFC 9989 a finalement préféré une autre méthode, la « montée à l'arbre » (on grimpe l'arbre des noms de domaine, cherchant des enregistrements DMARC).

Passons à la pratique, maintenant. OpenDMARC est aujourd'hui très répandu, aussi bien côté envoyeur que côté récepteur, et apparait souvent dans les articles de marketing « comment s'assurer que votre spam pardon votre newsletter sera bien livrée partout ». Sur mon serveur de messagerie personnel, j'annonce une politique DMARC et, pour valider les messages entrants, j'utilise OpenDMARC (notez que son développement semble bien avoir stoppé et qu'il y a donc peu de chances qu'il prenne en compte les nouveautés de ce RFC). Ma configuration est très proche de celle par défaut :

Socket inet:54321
# Les autres ont leur valeur par défaut	 

  

Et Postfix le lance ainsi, juste après DKIM :

smtpd_milters = unix:run/opendkim.sock, inet:localhost:54321
  

Et c'est ainsi que sont produits les champs Authenticated-Results: que vous avez vus.

Pour apprendre DMARC, je recommande l'excellent et interactif https://www.learndmarc.com/. Pour tester votre configuration, comme d'habitude, il existe de nombreux services.

Le chemin vers ce RFC a été très long (plusieurs années). L'annexe C du RFC résume les changements depuis le précédent RFC, le RFC 7489. Les principaux sont :

• Nouvel algorithme (« montée dans l'arbre » pour trouver le domaine organisationnel, au lieu de l'utilisation d'une liste de suffixes publics). C'est la suite du RFC 9091.
• Introduction de nouveaux concepts comme le PSD (Public Suffix Domain) et le PSO (Public Suffix Operator).
• Le RFC n'est plus seulement « Pour information », il passe sur le chemin des normes.
• Plusieurs nouvelles clés sont possibles dans l'enregistrement DMARC : np, psd et t.
• Mise à l'écart de certaines clés comme pct (partiellement remplacé par t).
• Résolution des erreurs du précédent RFC.

Les articles suivants sont de bonnes lectures pour les nouveautés de DMARC :

• « Understanding DMARCbis ».
• « DMARCbis is coming: New DNS tree walk algorithm and more  ».
• « What is DMARCbis: A guide by Red Sift ».

Faisons un peu un tour dans le passé avec ce vieil RFC, que j'ai lu pour préparer une intervention consacrée à l'Arpanet. Il normalise le protocole de connexion à distance qui est l'ancêtre de telnet.

La seule utilisation prévue de l'Arpanet, à ses débuts, était la connexion à un ordinateur distant, avec éventuellement un peu de transfert de fichiers. On pensait même que l'avenir était aux ordinateurs ultra-spécialisés, chaque université en hébergeant un, et Arpanet permettant un accès facile depuis les autres campus. Arpanet étant prévu dès le début pour des ordinateurs hétérogènes, il fallait un protocole standard pour cette connexion. En cinq pages (les RFC étaient courts, à l'époque), c'était fait.

Comme tout les RFC de l'époque, il peut être difficile à lire car la terminologie a changé. Un subsystem est tout simplement un programme généraliste, distinct des programmes « métiers » écrits par l'utilisateur. C'est le cas de telnet. Et un teletype est un terminal pas intelligent. Quant au time sharing, c'est du multi-tâches, auquel on est tellement habitués aujourd'hui qu'on ne pense plus à lui donner un nom. Et en ce temps, le RFC ne spécifiait pas seulement le protocole mais aussi le mode d'emploi du programme (telnet) qui le mettait en œuvre. Et encore, ici, le protocole n'est défini que par un exemple, où un programme tournant sur un PDP-10 se connecte sur un SDS 940. Il utilise les fonctions de base définies par le RFC 11 (ouvrir une connexion principale, une connexion auxiliaire, envoyer des données, etc). Le protocole n'a quasiment aucune des fonctions du futur « vrai » telnet (annoncé en conclusion du RFC et qui sera normalisé dans le RFC 764, bien des années après). Il se contente de faire passer des données entre les deux machines. Ici, les deux premières commandes sont des commandes locales au PDP-10, et la dernière une commande locale au 940. Les commandes préfixées par un astérisque sont celles de telnet :

.LOGIN
.R TELNET

*ESCAPE CHARACTER IS #
*CONNECT TO SRI

@LOGIN CARR.

Notez que notre RFC 15 inclut même un mécanisme de transfert de fichiers (FTP n'existait pas à l'époque), profitant du fait que le protocole de base de l'Arpanet (celui décrit dans le RFC 11) permettait d'ouvrir, en plus de la connexion principale, une connexion auxiliaire.

J'aurais bien aimé lire le code source de programmes mettant en œuvre ce RFC 15 mais je n'ai pas trouvé (j'ai très peu cherché donc, si vous avez une idée…).

Traditionnellement, les protocoles de transport comme QUIC ou TCP partaient de zéro à chaque connexion. On se connecte, on démarre prudemment (ne pas envoyer trop de données pour éviter de congestionner le réseau), puis on augmente le débit petit à petit. Mais c'est dommage de ne pas tenir compte des connexions précédentes, où on avait déjà suivi ce processus. Ne pourrait-on pas se souvenir des mesures précédentes pour aller plus vite la prochaine fois ? C'est justement ce que propose ce RFC.

Évidemment, si l'idée est simple, la réalisation soulève plein de problèmes, d'autant plus qu'on touche ici à une activité dangereuse : si on se trompe, on risque d'aggraver la congestion. Le RFC détaille donc plus précisément comment réutiliser ces mesures passées, pour ne pas faire s'écrouler le réseau. Tout protocole de transport doit utiliser un algorithme de contrôle de la congestion (RFC 2914) ou bien s'auto-modérer (RFC 8085). Mais concevoir un bon algorithme de contrôle de la congestion n'est pas trivial et, par exemple, le RFC 5783 notait que les algorithmes existants marchaient mal pour les liaisons avec un BDP élevé et/ou très variable, comme les liaisons satellite.

Pour comprendre pourquoi, revenons un peu au fonctionnement typique d'un algorithme de contrôle de la congestion. Il a typiquement deux phases. D'abord, au début de la connexion, on envoie moins de données que ce qu'on pourrait, afin de ne pas congestionner le réseau. Puis on augmente le débit, jusqu'au moment où des indicateurs comme la perte de paquets ou le rythme des accusés de réception (RFC 9406) signalent qu'on a atteint la capacité maximale pour ce flux de données. La dépasser (overshoot) congestionnerait le réseau ou, si les autres flux qui se partagent le réseau sont mieux élevés, entrainerait des diminutions de ressources pour ces autres, voire un écroulement du réseau sous la charge. Voilà pourquoi il faut démarrer lentement.

Au passage, le RFC note que, bien sûr, la connexion TCP ou QUIC qui réutiliserait les mesures d'une précédente connexion doit s'assurer qu'on compare ce qui est comparable : mêmes adresses IP source et destination, et peut-être même DSCP (Differentiated Services Code Point, cf. RFC 2474). On verra plus loin que ce n'est pas suffisant (les choses peuvent changer, le passé peut ne pas être un bon indicateur du présent), mais patientez encore un peu.

La méthode de notre RFC se nomme « reprise prudente » (careful resume) ou, en plus joli « partage temporel » (temporal sharing), puisqu'on reprend des mesures passées (mesures de la capacité, du RTT, etc). Ces mesures pouvant ne plus être d'actualité (trop vieilles et/ou le chemin suivi a changé), il faut en effet être prudent (cf. RFC 9000 et RFC 9040).

Dans quels cas cette reprise (prudente) de données d'une connexion précédente peut être utile ? La section 1.4 du RFC liste un certain nombre de cas d'usages. Entre autres, il y a le cas d'une application qui utilise plusieurs connexions, les connexions peuvent alors utiliser les données récupérées par la première d'entre elles. Ou bien lorsqu'une connexion a été violemment interrompue et repart tout de suite après. Et il y a aussi une autre utilisation, lorsque la latence du chemin utilisé est bien plus importante que dans une liaison Internet typique, ce qui est le cas des satellites lorsqu'ils ne sont pas en orbite basse. L'article « Google QUIC performance over a public SATCOM access  » note ainsi que sur une liaison via un satellite géostationnaire, avec l'algorithme classique, transférer 5,3 Mo prendra 9 secondes alors que le partage temporel, si on peut réutiliser les mesures d'une connexion précédente, prendra 4 secondes. (Si les 9 secondes vous semblent trop, compte-tenu de la capacité du lien, rappelez-vous que la capacité n'est pas le seul facteur limitant ; TCP, surtout au démarrage, n'utilise pas toute la capacité, et il met longtemps à converger si la latence est élevée.) Une autre présentation, à l'IETF « Feedback from using QUIC's 0- RTT-BDP extension over SATCOM public access », calcule une réduction du temps de transfert de 62 % pour faire voyager 1 Mo. Enfin, le RFC recommande la lecture de la synthèse « Careful Resumption of Internet Congestion Control from Retained Path State ».

Le récepteur des données peut avoir des informations que l'envoyeur n'a pas, et cela peut le pousser à vouloir désactiver la reprise que l'envoyeur croit prudente. Par exemple, le récepteur sait peut-être quelle quantité de données va être envoyée, ou bien il sait que le chemin sur le réseau a changé.

Toujours pour compliquer les choses, il faut aussi se souvenir que d'autres facteurs peuvent limiter la quantité de données qu'on envoie, par exemple le contrôle de flux, donc les fenêtres de TCP (RFC 9293, section 3.8.6) ou le système de crédit de QUIC (RFC 9000, section 4).

Prenant en compte tout cela, la section 1.5 du RFC résume les principes de la « reprise prudente » :

• D'abord, s'assurer que les conditions n'ont pas changé depuis la dernière connexion ; le chemin est-il le même ? (La mesure du RTT donne une première bonne idée.) À l'issue de cette phase de reconnaissance, si les conditions ont changé, on utilise la méthode classique, on ne tient pas compte des mesures qui ont été sauvegardées.
• Ensuite, OK, on va plus vite qu'avec la méthode classique mais pas aussi vite que ne l'indiquent les mesures sauvegardées. Après tout, la reconnaissance ne permet pas toujours d'identifier un changement dans les conditions.
• Enfin, on se prépare à faire marche arrière, et à revenir à la méthode classique, si on s'aperçoit qu'on est en train de créer de la congestion. (Le RFC note qu'il faut la détecter rapidement, avant que les autres flots de données n'aient détecté la congestion et réduit leur débit.)

Un peu de terminologie avant de continuer (section 2) : le partenaire distant (remote endpoint) est l'ensemble des informations qui identifie à qui on envoie des données, typiquement l'identificateur d'une interface réseau locale couplé à l'adresse IP de la machine avec qui on parle et peut-être (c'est une décision locale, et forcément très dépendante du système d'exploitation utilisé) des informations comme DSCP. Si le partenaire distant change, on en déduit que le chemin a changé (l'inverse n'est pas vrai : le chemin peut changer alors que le partenaire distant est le même). Si on a une indication que le chemin a changé, on revient au mécanisme traditionnel, on n'utilise pas les paramètres gardés des précédentes connexions.

Le mécanisme de notre RFC a donc plusieurs phases (section 3, mais regardez aussi le joli tableau de l'annexe A, qui est peut-être plus clair) : celle de reconnaissance, où on cherche si les caractéristiques du chemin correspondent à un chemin connu, puis , selon son résultat, on passe à la phase dite normale, si on a reconnu un chemin déjà vu, ou bien à la phase non validée (chemin inconnu, on démarre prudemment), puis à la phase de validation (y a t-il un indicateur de congestion ou bien tout est-il beau et propre ?), ou bien à celle de retraite (on jette les informations enregistrées, la situation a changé, on retourne en mode traditionnel), avant de passer à la phase normale. (Des exemples détaillés figurent dans l'annexe B.)

La section 4 du RFC fournit des détails sur la mise en œuvre des principes de ce RFC. Par exemple, la détermination pratique d'un changement du chemin. Un bon indicateur est le RTT. Cette section conseille aussi, même en l'absence d'indications que le chemin a changé, de ne pas garder les paramètres sauvegardés trop longtemps : comme la détection d'un éventuel changement n'est pas parfaite, il vaut mieux avoir une durée de vie maximale pour les paramètres enregistrés. Le RFC suggère quelques heures, voire moins si on sait que le chemin est très dynamique.

Enfin, l'annexe B détaille à l'octet près des exemples de fonctionnement de l'algorithme de reprise prudente, pour différents cas.

Vous pouvez aussi avoir une introduction aux principes de ce RFC dans l'exposé d'un des auteurs à la Journée du Conseil Scientifique de l'Afnic en 2021 (avec les supports).

Merci à Nicolas Kuhn pour sa relecture.

Dans ce court mais très percutant essai, Leïla Slimani commence par se demander pourquoi elle ne parle pas arabe, puis s'attaque aux politiques identitaires et défend la pluralité et l'égalité des langues (ainsi que la liberté de leurs locuteurs et locutrices).

Petite, l'auteure, dans son Maroc natal, parlait darija. Mais à la maison (famille assez riche et éduquée), c'était le français. Et les cours d'arabe classique, donnés par des enseignants rétrogrades et ennuyeux, n'attiraient pas. Résultat, aujourd'hui (elle vit en France), elle ne peut plus parler arabe et le regrette.

Slimani dénonce donc la hiérarchisation des langues, le fait que certaines langues étaient vues comme inférieures, moins intéressantes et donc pas ou mal enseignées. Et elle en profite pour défendre l'idée de langues vivantes, qui changent et ne sont pas tenues aux oukases (tiens, est-ce un mot français ?) d'institutions réactionnaires. C'est ainsi qu'elle défend les textes d'Aya Nakamura ou, plus exactement, le droit de la chanteuse à écrire comme elle le souhaite.

Mais surtout, l'auteure lance un « assaut contre la frontière » en dénonçant les politiques identitaires ou l'assignation à une identité unique, et en prônant l'universalité, que permet le pluralisme des langues. « Combien de fois m'a-t-on demandé si je me sentais plus arabe ou plus française. »

PS : la question de l'enseignement de l'arabe en France est un vieux sujet et je retrouve un article que j'avais fait en 2020.

Le titre original « Amour et sexe dans la Rome antique » résume mieux ce livre que la ridicule traduction française. Mais ne lisant pas l'italien, j'ai dû passer par cette traduction. Donc, ce livre est un récit de plusieurs aspects de la sexualité dans la Rome de l'Antiquité.

Comme dans les précédents livres de cet excellent vulgarisateur qu'est Alberto Angela, le récit est très vivant, les personnages attachants et, vu le sujet choisi (amour et sexe…), le livre a certainement de quoi capter l'attention. Comment embrassait-on à Rome ? Comment draguait-on ? Quelles étaient les positions utilisées ? D'un côté, il y avait une certaine liberté des mœurs (davantage qu'avec le christianisme ultérieur), de l'autre, c'était quand même une société très machiste (et violente)… D'autant plus qu'on la connait surtout par des textes d'auteurs masculins. Mais, bon, j'en profite pour placer une image récupérée sur Wikimedia Commons car il n'y a pas assez d'images érotiques sur ce blog :

Mais je suis un peu resté sur ma faim : plusieurs des éléments des précédents livres de cet auteur ont été réutilisés, et il n'y a pas assez de nouveautés pour moi. Je conseillerai aux lecteurices potentiel·les, qui s'intéressent aux différents aspects de la vie des Romains de l'Antiquité, de lire d'abord « Empire » (son meilleur livre) ou « Une journée dans la Rome antique ».

Un curieux roman policier suédois mais qui ne ressemble pas aux « polars scandinaves » habituels. D'abord, ça se passe au XIXe siècle, ensuite le héros n'est pas alcoolique (et même tout le contraire).

Le livre est inspiré d'un personnage réel, Lars Levi Læstadius, un pasteur intégriste qui faisait également de la botanique et, mais dans le roman seulement, de l'enquête policière. Dans une partie de la Finlande dominée par la Suède, où règne une stricte hiérarchie des langues (d'abord le suédois, puis le finnois, puis tout en bas le same), dans une région secouée par le mouvement de l'Éveil (ce qui perturbe pas mal l'enquête), le héros doit trouver le coupable d'une série de meurtres que certains attribuent à un ours. Le quatrième de couverture de l'édition français cite évidemment Le nom de la rose, pour le personnage du religieux-enquêteur mais Læstadius est bien plus rigide religieusement que Guillaume.

Croyez-moi, vous allez probablement être accroché rapidement si vous aimez les enquêtes policières. L'enquêteur ne traine pas sa dépression tout au long du livre, au contraire, il a une énergie débordante, qui contraste avec le calme de son assistant.

Il y en a des livres, qui parlent d'Internet et, dans le lot, certains parlent de politique. Mais la plupart se limitent aux services visibles (YouTube, TikTok, ce que connait l'auteur) alors que ce livre de Francesca Musiani parle bien de l'Internet : en quoi son infrastructure est-elle politique ?

Ce livre est tiré de son HDR et, donc, si vous avez déjà lu ses autres articles, vous n'aurez pas de révélations radicales. Mais même dans ce cas, il est agréable de pouvoir lire un livre qui, en français, rassemble de manière cohérente et bien intégrée, des années de recherche. L'auteure explique bien la façon dont l'Internet est géré (ou pas géré, justement), et en quoi il est à la fois un outil et un enjeu de pouvoir.

Cinq passionnantes études de cas forment l'essentiel du livre : la « gouvernance de l'Internet » (sujet battu et rebattu, oui, mais ici traité de façon sérieuse), le DNS, Bitcoin, Signal et le cas de la Russie. Même si vous connaissez bien l'Internet, vous apprendrez certainement quelque chose. Et cela vous donnera peut-être envie d'agir pour que le futur de l'Internet soit celui que nous voulons.

Le protocole CoAP est un protocole léger, conçu pour les objets connectés. Ce RFC décrit comment faire du DNS au-dessus de CoAP. Si votre brosse à dents a besoin de faire du DNS, c'est ce RFC qu'il faut lire.

CoAP, normalisé dans le RFC 7252, ressemble à HTTP mais en plus simple. Il vise le marché des objets contraints (en mémoire, énergie, en capacité réseau, en puissance de calcul…, voir le RFC 7228). CoAP permet à un client d'envoyer des requêtes à un serveur, et notre tout neuf RFC 9953 explique comment utiliser CoAP pour faire des requêtes DNS et recevoir des réponses DNS. Comme CoAP peut être vu, de manière simplifiée, comme une variante légère de HTTP, ce DNS sur CoAP, alias DoC (DNS over CoAP), est très proche dans ses principes de DoH (RFC 8484). Les contraintes de l'Internet des objets empêchent votre tournevis ou votre ampoule électrique de faire du DoH (qui implique HTTPS), d'où ce DoC. Bien sûr, il y avait toujours la possibilité de faire du DNS sur DTLS, comme le décrit le RFC 8094, mais CoAP a plein de fonctions sympas pour les objets contraints (transferts par blocs - RFC 7959, qui résout les problèmes de MTU, relais CoAP, etc).

L'architecture générale de DoC est très proche de celle de DoH : le client DoC interroge un serveur DoC qui est lui-même un client DNS, parlant typiquement à un résolveur DNS. La communication entre le client DoC et le serveur DoC utilise CoAP, celle entre le serveur DoC et le résolveur utilise le DNS normal, sur UDP, TCP, TLS, etc.

Le serveur DoC sera a priori désigné par le chemin /. Le but est que les messages soient plus courts (DoH utilise souvent le chemin /dns-query). Au fait, comment le client DoC trouve-t-il le serveur (section 3 du RFC) ? Plusieurs méthodes sont admises, de la configuration manuelle (« le serveur DoC est en coaps://doc.foobar.example/ ») aux répertoires CORE (RFC 9176) en passant par les classiques DHCP ou RA ou bien par la découverte de résolveurs du RFC 9462. Ces différentes solutions sont plus ou moins sûres, et plus ou moins pratiques pour l'administrateur/utilisateur (et en général les plus pratiques sont les moins sûres).

Mais ce n'est pas tout : le serveur DoC peut aussi être trouvé via le DNS, avec un enregistrement SVCB (RFC 9460 et RFC 9461), si l'objet contraint a déjà un moyen d'interroger le DNS (la clé SVCB est docpath, numéro 10).

Une fois qu'on connait le serveur, on peut lui parler. La section 4 décrit les messages CoAP échangés. Ils sont étiquetés avec le type application/dns-message (valeur numérique 553).

La méthode CoAP utilisée est FETCH (RFC 8132), qui n'a pas d'équivalent HTTP, contrairement à la plupart des méthodes CoAP. DoC utilise le principe REST (RFC 6690). Le RFC recommande de ne pas oublier le champ Accept: pour indiquer le type de données accepté. Le type recommandé est application/dns-message. Dans la requête, le Query ID DNS devrait être à 0, CoAP se charge de mettre en correspondance requêtes et réponses donc cet identificateur n'est pas utile (c'est pareil pour DoH).

Et les réponses ? Là encore, comme pour DoH, les codes de retour CoAP indiquent si le serveur DoC a pu être joint et a pu faire son travail, pas si la requête DNS a eu une réponse satisfaisante. Autrement dit, tant que le serveur DoC fonctionne bien, il renvoie le code 2.05 (RFC 7252, section 5.9.1.5.) et c'est dans le message DNS qu'on saura si la résolution DNS a renvoyé NOERROR, SERVFAIL, NXDOMAIN, etc.

La mémorisation des réponses joue un rôle plus grand en CoAP qu'en HTTP (rappelez-vous que CoAP sert à des objets contraints). Le RFC demande donc que les TTL dans la réponse DNS soient constants, afin que l'ETag (RFC 7252, section 5.10.6), s'il est calculé via un condensat, ne change pas. Le serveur DoC doit par contre mettre un champ Max-Age: dans sa réponse (section 4.3.2).

Voici, tiré du RFC, un exemple de réponse CoAP, formaté en texte :

2.05 Content
Content-Format: 553 (application/dns-message)
Max-Age: 58719
Payload (human-readable):
    ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
    ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;example.org.                 IN      AAAA
    ;; ANSWER SECTION:
    ;example.org.         79689   IN      AAAA    2001:db8:1:0:1:2:3:4

  

Et la sécurité ? Le RFC recommande de sécuriser la communication avec le système OSCORE du RFC 8613 (ou, sinon, le DTLS du RFC 9147, ce qui donne du CoAPS). Le RFC note que cela assure la sécurité de la communication entre le client DoC et le serveur DoC mais que, après, on ne sait pas ce que fait le serveur (la section 8 recommande évidemment que le serveur DoC valide avec DNSSEC).

Questions mises en œuvre de DoC, on trouve (mais je ne les ai pas testées, je ne fais pas d'Internet des Objets), par les auteurs du RFC, dans RIOT, un client en C (source sur Github) et un serveur en Python.

Si vous voulez allez plus loin que ce résumé sommaire, une bonne lecture est le papier de 2023 des auteurs, « Securing Name Resolution in the IoT: DNS over CoAP ».

Ce RFC spécifie comment mettre des clés ML-KEM dans un certificat X.509. Vous allez me dire « Mais ML-KEM est un algorithme d'échange de clés, pas de signature, que fait-il dans un certificat ? » Et je vous répondrai que vous avez raison, d'ailleurs le RFC restreint sérieusement ce qu'on peut faire avec cet algorithme.

ML-KEM a l'intéressante propriété d'être résistant aux calculateurs quantiques. Il est normalisé dans FIPS 203. Ce RFC permet de l'utiliser dans les certificats normalisés dans le RFC 5280, et il décrit trois variantes, ML-KEM-512, ML-KEM-768 et ML-KEM-1024.

Comme indiqué plus haut, autant il était normal de permettre ML-DSA dans les certificats (RFC 9881), autant cela peut sembler surprenant pour ML-KEM. La section 1.1 de notre RFC explique les usages (limités) d'un algorithme d'échange de clés dans un certificat. C'est par exemple utile pour un protocole où vous avez besoin d'une clé publique, que vous allez tirer du certificat. Mais vous ne pourrez pas utiliser les certificats de ce RFC pour faire du TLS sur l'Internet public, aucune AC ne vous en produira, même si TLS le permet un jour. Pour la même raison, vous n'en trouverez pas dans les journaux Certificate Transparency.

Les trois algorithmes sont identifiés en suivant le RFC 5912, par un OID via le NIST ; Ce sont id-alg-ml-kem-512 (2.16.840.1.101.3.4.4.1), id-alg-ml-kem-768 (2.16.840.1.101.3.4.4.2) et id-alg-ml-kem-1024 (2.16.840.1.101.3.4.4.3).

La section 5 du RFC précise que les bits indiquant les utilisations possibles de ces certificats (RFC 5280, section 4.2.1.3) doivent indiquer uniquement le chiffrement d'une clé (et pas l'authentification, comme avec les certificats habituels).

Le module ASN.1 figure dans l'annexe A, si vous voulez implémenter ce RFC (il faut aussi importer les modules des RFC 5912 et RFC 9629). Le module est identifié par id-mod-x509-ml-kem-2025 et a l'OID 1.3.6.1.5.5.7.0.121. Le gros du RFC est constitué d'exemples de clés et de certificats ML-KEM (annexe C), dans l'encodage en texte du RFC 7468.

Allez, un peu de pratique avec OpenSSL 3.5 :

% openssl genpkey -algorithm ML-KEM-512 -out ml-kem-key.pem -outform PEM

% cat ml-kem-key.pem
-----BEGIN PRIVATE KEY-----
MIIGvgIBADALBglghkgBZQMEBAEEggaqMIIGpgRAOwWCnP71SklfOIuwiLrIddsm
Up4AlOMwvwjqCy4PHr8fSq5jRjFoP6XYXnl8IQCR9HhzSRVffI09hBezOUrmxgSC
…

# Analysons cette clé :
% openssl pkey -text -in ml-kem-key.pem 

# Demandons une signature du certificat :
% openssl req -new -key ml-kem-key.pem  -provider default -out req.csr 
…
40E7CEC0027F0000:error:03000096:digital envelope routines:do_sigver_init:operation not supported for this keytype:../crypto/evp/m_sigver.c:305:

Ah, là, c'est raté, et c'est logique. OpenSSL n'accepte pas de fabriquer un CSR pour ces clés « operation not supported for this keytype » puisque ML-KEM ne permet pas de signer. La solution :

# Extraire la clé publique :
% openssl pkey -in ml-kem-key.pem -pubout   -out mlkem.pub

# Fabriquer une clé ECDSA pour signer :
% openssl ecparam -out ec_key.pem -name secp256r1 -genkey 

# Signer :
% openssl x509 -new \
  -subj "/CN=test-mlkem" \
  -force_pubkey mlkem.pub \
  -signkey ec_key.pem \
  -days 365 \
    -out mlkem-cert.pem
Warning: Signature key and public key of cert do not match

L'avertissement est normal, puisqu'on a effectivement utilisé une autre clé, d'un autre algorithme, pour signer le certificat contenant notre clé publique ML-KEM. Mais tout s'est bien passé :

% openssl x509 -text -in mlkem-cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            69:33:f9:1e:e5:34:64:84:d9:f4:b2:15:3b:50:ec:36:db:0b:71:5c
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=test-mlkem
        Validity
            Not Before: Feb 16 15:30:02 2026 GMT
            Not After : Feb 16 15:30:02 2027 GMT
        Subject: CN=test-mlkem
        Subject Public Key Info:
            Public Key Algorithm: ML-KEM-512
                ML-KEM-512 Public-Key:
                ek:
                    d8:d2:6c:c4:9b:96:48:23:0d:ce:f7:0d:b3:0b:85:
                    …
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                E7:B2:03:92:37:EC:C6:35:E4:F0:2E:AC:4E:1C:F2:81:67:F7:95:29
            X509v3 Authority Key Identifier: 
                15:E5:2A:5E:B1:C3:50:69:7E:E4:48:EA:0F:DD:3C:5C:90:4B:7C:CC
    Signature Algorithm: ecdsa-with-SHA256