From bc1d70343807104ccf64b6bde9b2db54270203ff Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 10 Mar 2017 11:58:22 +0100 Subject: Initiale release --- ..._Conformance_DMARC_and_Indirect_Email_Flows.txt | 255 +++++++++++++++++++++ 1 file changed, 255 insertions(+) create mode 100644 RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt (limited to 'RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt') diff --git a/RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt b/RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt new file mode 100644 index 0000000..28427f5 --- /dev/null +++ b/RFC_7960_Interoperability_Issues_between_Domainbased_Message_Authentication_Reporting_and_Conformance_DMARC_and_Indirect_Email_Flows.txt @@ -0,0 +1,255 @@ +Titre: RFC 7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows +Auteur: +Date: Tue 11 Oct 2016 02:00:00 +0200 +Lien: https://www.bortzmeyer.org/7960.html + +Le mécanisme DMARC permet d'indiquer dans le DNS la politique d'un domaine +concernant l'authentification du courrier. Si je reçois un message prétendant +venir de ma-banque.example, et qu'il n'est pas authentifié (ni SPF, ni DKIM, ni +autre chose), comment savoir si c'est parce que ma banque est nulle en sécurité +du courrier, ou bien parce que le message est un faux ? DMARC (normalisé dans +le RFC 7489) permet de répondre à cette question en publiant un enregistrement +qui indique si le courrier est censé être authentifié ou pas. Comme toutes les +techniques de sécurité, ce mécanisme est imparfait et il pose notamment des +problèmes avec les messages indirects. Par exemple, si vous avez une adresse à +votre ancienne université, alice@univ.example et que le courrier qui lui est +adressé est automatiquement transmis à votre adresse professionnelle, +alice@evilcorp.example, comment DMARC va-t-il réagir avec cette indirection ? +C'est ce qu'explore ce RFC. + +Voici la politique DMARC de Gmail. Elle est tolérante (p=none, accepter les +messages non authentifiés) : + + +% dig TXT _dmarc.gmail.com +... +;; ->>HEADER<><>- opcode: QUERY, status: NOERROR, id: 59294 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 +... +;; ANSWER SECTION: +_dmarc.gmail.com. 600 IN TXT "v=DMARC1; p=none; rua=mailto:mailauth-reports@google.com" +... +Paypal est plus violent, demandant qu'un récepteur rejette les messages +prétendant venir de Paypal mais pas authentifiés : + +_dmarc.paypal.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:d@rua.agari.com; ruf=mailto:dk@bounce.paypal.com,mailto:d@ruf.agari.com" + +La question de départ de l'administrateur système est « si je mets une +politique DMARC restrictive (genre p=reject), vais-je perdre des courriers +légitimes, à cause d'indirections comme les listes de diffusion ? » (section 1 +du RFC). Il est d'autant plus difficile de répondre à cette question que +l'architecture du courrier électronique est complexe et mal spécifiée (RFC +5598). Bien des logiciels ne suivent pas les règles, d'autant plus que beaucoup +de ces règles n'ont pas été explicites dès le début. (Un bon exemple : avec un +.forward, le serveur de courrier doit-il garder l'expéditeur indiqué dans l' +enveloppe du message ? Essayez de trouver un RFC qui spécifie cela !) + +La section 2 de notre RFC décrit les causes des problèmes DMARC. Si un message +est légitime (le destinataire veut le recevoir), et qu'il est en outre +techniquement correct, un problème, au sens de ce RFC, est quand la politique +de DMARC (qui peut être de rejet) est appliquée à ce message, parce qu'il a été +transmis indirectement. C'est injuste. Évidemment, si la politique DMARC est +p=none (ne rien faire), ce n'est pas un vrai problème. Mais un p=reject peut +être très ennuyeux. + +Première cause de problèmes, des différences entre les identificateurs +utilisés. DMARC n'authentifie pas directement, il dépend de SPF (RFC 7208) et +DKIM (RFC 6376) pour cela. Ce qui intéresse l'utilisateur, évidemment, c'est le +nom dans le champ From: (RFC 5322) du message. Pour lui, c'est ça l'expéditeur. +Mais DKIM, et surtout SPF, n'ont pas la même conception : ils peuvent utiliser +d'autres identificateurs. DMARC considère que l'accord (alignment, cf. RFC +7489, section 3.1) entre les identificateurs authentifiés par SPF et DKIM, et +le champ From: du message peut être strict ou laxiste. « Strict » indique une +correspondance parfaite, laxiste se limite à vérifier que le nom de domaine est +le même. + +Le principal identificateur utilisé par SPF est celui donné par la commande +MAIL FROM dans la session SMTP (RFC 5321). C'est la principale cause de +désaccord : si SPF authentifie cet identificateur et qu'il est différent de +l'adresse utilisée dans le champ From: de l'en-tête du message, que faire ? + +Deuxième cause de problème, le relayage d'un message. Si Bob bob@isp.example +écrit à alice@univ.example, et qu'elle (ou son administrateur système) a +demandé un relayage automatique vers alice@evilcorp.example, les serveurs de +courrier de evilcorp.example verront un message prétendant être de isp.example, +mais transmis par les serveurs de univ.example... SPF sera content ou pas, +selon la façon exacte dont a été fait le relayage (en préservant le MAIL FROM +ou pas). DMARC ne sera jamais content car, si le MAIL FROM a été changé +(reflétant le relais), SPF authentifiera mais il n'y aura plus d'accord entre +les identificateurs. + +Évidemment, si le message est modifié en cours de route, c'est encore pire. SPF +ne protège pas l'intégrité du message, mais DKIM le fait. Mais qui diantre se +permet de modifier les messages ? Hélas, pas mal de gestionnaires de listes de +diffusion le font. DKIM a une option (déconseillée... voir la section 8.2 du +RFC 6376) pour ne signer que le début du message, évitant ainsi que la +signature soit invalidée par l'ajout, par exemple, d'un paragraphe final. Cela +ne couvre que le cas des messages simples, sans MIME, où la modification est un +simple ajout à la fin. Autre possibilité de DKIM pour éviter d'invalider les +signatures en cas de modification du message, le mode relaxed de +canonicalisation du contenu, qui permet de supporter des modifications +triviales comme la transformation de N espaces consécutifs en un seul. + +Reprenant le vocabulaire du RFC 5598 (relisez-le d'abord !), la section 3 de +notre RFC liste les différents composants de la messagerie qui peuvent jouer un +rôle dans les transmissions indirectes, et les problèmes qu'elles posent. +D'abord, le MSA (Message Submission Agent.) C'est la première ligne de +vérification : il fait respecter les règles d'une organisation (ADMD, +ADministrative Management Domain). S'il accepte un message où le champ From: du +RFC 5322 n'est pas dans un domaine contrôlé par l'ADMD, il y a des chances que +DMARC râle par la suite. Le RFC cite plusieurs cas d'usage où cela se produit : +la fonction « envoyer cet article à un ami » de certains sites Web, par +exemple, puisque le message va partir avec le domaine du lecteur de l'article, +pas avec celui du site Web. On peut trouver de nombreux autres exemples, comme +un service de gestion d'agenda qui envoie des courriers de rappel, en utilisant +comme expéditeur l'adresse de l'utilisateur, ce qui est plutôt une bonne chose +(pour des messages du genre « l'heure de la réunion a changé ») mais peut gêner +DMARC. (Mon exemple préféré est le cas où on a une adresse de courrier mais pas +de moyen de soumettre du courrier via cette organisation, ce qui est fréquent +avec les adresses de fonction. Par exemple, on est membre d'une organisation +qui fournit des adresses à ses membres et/ou responsables, ce qui permet de +recevoir du courrier, mais on n'a pas de MSA pour en envoyer, on doit donc +utiliser celui d'une autre organisation.) + +Et les MTA, eux, quel est leur rôle dans les problèmes DKIM ? S'il change +l'encodage (par exemple en passant du « 8 bits » à l'abominable +Quoted-Printable), il va invalider les signatures DKIM (la canonicalisation de +DKIM ne prévoit pas des transformations aussi radicales, même si elles ne +modifient pas le message final). Idem si le MTA corrige les en-têtes du message +pour les rendre conformes (une tâche qui relève plutôt du MSA, le MTA devant +lui, transmettre fidèlement les messages qu'il a choisi d'accepter) : cela sort +également du champ de la canonicalisation DKIM et cela invalide donc les +éventuelles signatures. Enfin, le changement ou la suppression de certaines +parties MIME (par exemple l'élision d'un document ZIP attaché, pour des raisons +de protection contre les logiciels malveillants transmis par courrier) va +évidemment également rendre les signatures invalides. + +Et le MDA ? Peut-il casser des choses, également ? Oui, s'il passe les messages +par Sieve (RFC 5228), qui a la possibilité d'ajouter ou de retirer des +en-têtes, voire de modifier le corps (extension Sieve du RFC 5703). Si les +tests DMARC sont faits après le passage de Sieve, ou bien si le message est +ensuite réinjecté dans le système de courrier, des problèmes peuvent se +produire. + +Reste le cas des intermédiaires (mediators). Ce sont les entités qui prennent +un message, puis le ré-expédient (parfois après modification). Un exemple est +l'alias. Via une entrée dans /etc/aliases ou bien via un .forward, ou bien via +le redirect de Sieve, ou encore via encore une autre méthode, un message +initialement destiné à une adresse est finalement transmis à une autre. C'est +par exemple courant pour les adresses « ancien élève », que fournissent +certaines universités, et qui permettent de garder à vie une adresse dans le +domaine de l'établissement où on a fait ses études. Un certain nombre +d'associations professionnelles fournissent un service équivalent. En général, +ces intermédiaires ne cassent pas DKIM (ils ne modifient pas le message) mais, +selon la façon dont ils redirigent, peuvent invalider l'autorisation SPF. + +Un autre exemple d'intermédiaire classique est le gestionnaire de listes de +diffusion. En plus de rediriger un message (ce qui fait que le message écrit +par alice@univ.example n'est pas émis par les serveurs de courrier de +l'université), ces logiciels changent souvent le message, par exemple en +ajoutant une inutile étiquette [Ma jolie liste] aux sujets des messages, en +ajoutant un texte à la fin (instructions de désabonnement, pourtant déjà +possibles avec l'en-tête List-Unsubscribe:), en retirant des pièces jointes, ou +bien (surtout dans les théocraties comme les États-Unis) en remplaçant des gros +mots par des termes plus acceptables. + +Toutes ces modifications vont probablement invalider les signatures DKIM (cf. +RFC 6377) et faire que les messages envoyés par certains participants à la +liste (ceux qui ont une politique DMARC p=reject) ne seront pas reçus par les +destinataires qui testent cette politique. (Si un avis de non-remise est +transmis, le logiciel de gestion de la liste peut en déduire que l'adresse +n'existe pas, et désabonner d'autorité le destinataire.) + +Et les filtres ? Certaines organisations insèrent dans le réseau des +dispositifs qui vont analyser le courrier, par exemple à la recherche de +logiciel malveillant. Souvent, ils vont modifier les messages, afin de +supprimer ces contenus indésirables. Ces modifications vont évidemment +invalider les signatures. Idem si on change ou supprime des URL contenus dans +le message et considérés « dangereux ». Même chose avec un système anti-spam +qui ajouterait un [SPAM] dans le sujet. + +En revanche, le courrier reçu d'un serveur secondaire (MX de secours), qui a +pris le relais pendant une panne du primaire, puis expédié le courrier quand le +primaire remarche, ne pose pas de problèmes. Bien sûr, les tests SPF échoueront +mais, normalement, on ne fait pas ces tests sur le courrier qui vient de son +propre serveur secondaire. + +Bon, voici le tour d'horizon complet de tout ce qui peut marcher mal. Mais que +faire ? La section 4 du RFC s'attaque aux solutions. Elles sont nombreuses et +très différentes. Mais attention : DMARC est là pour rejeter des messages +considérés comme invalides. On peut arranger les choses pour que certains de +ces messages « passent » mais cela va contre le but de DMARC. Si les messages +sont de grande valeur (transactions financières, par exemple), il vaut mieux ne +pas chercher de solutions, et simplement se contenter de messages transmis +directement, ne subissant pas de traitements qui vont invalider SPF ou DKIM. + +C'est d'autant plus vrai que l'écosystème du courrier électronique est très +complexe. On trouve un zillion de logiciels différents, plus ou moins bien +écrits. Par exemple, des gens utilisent encore Qmail, qui n'a plus eu une seule +mise à jour depuis 1998. Certaines des mesures ou contre-mesures utilisées pour +la sécurité du courrier sont parfaitement légales, mais vont casser tel ou tel +logiciel qui est utilisé à certains endroits. + +Assez d'avertissements, les solutions. D'abord, du côté de l'expéditeur. +Celui-ci (ou son premier MTA) peut faire des efforts pour améliorer l'accord +entre les identificateurs. Un logiciel sur info.example qui envoie du courrier +pour le compte de bob@univ.example peut ainsi décider d'utiliser un en-tête +From: qui ne posera pas de problème, celui du vrai envoyeur, et de mettre +l'adresse de Bob dans un Reply-To:. Comme la plupart des solutions présentées +dans cette section 4, elle est imparfaite (le destinataire peut se demander qui +est cet envoyeur qu'il ne connait pas). Le RFC fournit de nombreux autres +exemples de désaccord entre identités, qui peuvent être réparés en changeant un +peu le processus d'envoi du message. Comme le disait ma grand-mère, « il y a +toujours une solution, pour peu que chacun y mette du sien ». + +Les envoyeurs peuvent aussi limiter le risque de modifications invalidantes, en +ne signant pas trop d'en-têtes avec DKIM, ou en envoyant des messages +parfaitement formés (pour éviter aux serveurs ultérieurs la tentation de les +« réparer »). + +Les receveurs peuvent aussi agir mais leurs possibilités sont plus limitées, +note le RFC. + +Entre les expéditeurs et les receveurs, il y a tous les intermédiaires qui +prennent un message et le ré-expédient. Ce sont souvent eux qui causent le +problème, et ils sont donc souvent en position de le réparer. Par exemple, ils +peuvent changer le From: du message pour mettre le leur, ce qui permettrait à +peu près n'importe quelle modification, et serait plus « franc » (puisque le +message n'est plus tout à fait l'original, autant changer l'auteur...) +Évidemment, dans ce cas, assez violent, il faut au minimum garder l'information +sur l'émetteur originel, avec l'en-tête Original-From: (RFC 5703). Le problème +est que le récepteur humain sera sans doute déconcerté par cet expéditeur +(d'autant plus qu'Original-From: est peu ou pas affiché). + +Comme les modifications invalident les signatures, les ré-expéditeurs +pourraient les éviter, par exemple en ajoutant des en-têtes au lieu de modifier +les existants, lorsqu'ils veulent ajouter un contenu (du genre « ceci est un +spam »). Il serait peut-être préférable, dans certains cas, de rejeter les +messages plutôt que de les modifier, ce qui cassera la vérification de +signatures plus loin. + +Et, en parlant des ré-expéditeurs, les listes de diffusion, pas vraiment +prévues par DKIM, que faire pour elles ? Le RFC 6377 a déjà traité leur cas. +Une technique courante est de modifier le champ From: pour mettre l'adresse de +la liste, réduisant l'auteur original à un commentaire dans cet en-tête (avis +personnel : je déteste ça). Comme cela rend difficile de répondre en privé au +vrai auteur d'un message, l'ajout d'un Reply-To: peut aider. Une autre solution +est d'emballer le message original dans une partie MIME message/rfc822. Cette +partie resterait intact et le message emballant aurait comme expéditeur la +liste. Mais peu de MUA savent afficher proprement ce genre de messages +(spécialement dans le monde des mobiles). + +Encore plus fasciste, le gestionnaire de liste pourrait interdire l'abonnement +des gens utilisant une adresse où il y a une politique DMARC autre que p=none. +(Le RFC oublie de parler du cas où une politique p=reject n'existait pas au +moment de l'abonnement mais a été rajoutée après.) + +Enfin, il existe aussi des solutions qui sont encore en cours de discussion à +l'IETF, et dont le RFC décourage l'usage dans un environnement de production. +Ce sont entre autres des extensions au modèle du RFC 7601 pour créer une chaîne +d'authentification où chaque acteur important signerait le message en route. +Ou, plus radical, des mécanismes stockant l'état initial d'un message avant +transformation, pour pouvoir retrouver cet état original et vérifier la +signature. + +Bref, le problème n'est pas résolu... -- cgit v1.2.1