% $Id: index.tex,v 1.4 2004/09/05 21:51:31 bortzmeyer Exp $ % Mise au point \documentclass[a4,landscape,article]{seminar} % Impression réelle %\documentclass[a4,landscape,slidesonly]{seminar} %%%%%%%%%% \usepackage[latin1]{inputenc} \usepackage{fancybox} \usepackage[french]{babel} \usepackage{bortzmeyer-utils} \newpagestyle{MH}% {AFNIC\hfil\thepage} {LMAP\hfil} \slidepagestyle{MH} \include{slides} \articlemag{1} \slidesmag{6} %\twoup \pagestyle{empty} \title{Les protocoles LMAP : authentifier le courrier via le DNS} \author{Stéphane Bortzmeyer\\ \url{} } \date{7 septembre 2004} \begin{document} \begin{slide} \maketitle \addtocounter{slide}{-1} \slidepagestyle{empty} \end{slide} \begin{slide} \addtocounter{slide}{-1} Ce document est distribué sous les termes de la GNU Free Documentation License \url{http://www.gnu.org/licenses/licenses.html#FDL}. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. \end{slide} \begin{slide} \heading{Rappel sur le courrier} Le courrier est transmis de MTA (Message Transfer Agent) en MTA. Le protocole principal est SMTP (mais voir RFC 2476). Typiquement aucune authentification. \end{slide} RFC 2476 décrit un protocole proche de SMTP pour soumettre le message original. L'idée est de réserver SMTP aux communications MTA-MTA et d'utiliser RFC 2476 pour les communications MUA-MTA. \begin{slide} \ifpdf \includegraphics[scale=0.38]{email.pdf} \else \includegraphics[scale=0.48]{email.eps} \fi \end{slide} Certaines techniques authentifient le message : PGP (RFC 2440) ou DomainKeys, donc couvrent tout le voyage. D'autres authentifient seulement un canal : c'est le rôle des protocoles LMAP. Tout le monde est d'accord pour dire qu'authentifier le message est mieux. Mais c'est plus compliqué et coûteux (PKI, par exemple). D'où l'idée d'une authentification plus faible, celle du canal, qui pourrait approcher les 100 \% de déploiement. \begin{slide} \heading{Une session typique} \begin{info} S: 220 company.com ESMTP server ready C: EHLO almamater.edu S: 250-company.com S: 250 SIZE C: MAIL FROM: S: 250 sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 okay, send message C: Resent-From: bob@almamater.edu C: (message body goes here) \end{info} \end{slide} \begin{slide} \heading{Rappel : sécuriser SMTP} Soumettre seulement : RFC 2476 ``Message Submission''. Extensions SMTP pour le relayage sûr : RFC 2554 ``SMTP Service Extension for Authentication'' et 3207 ``SMTP Service Extension for Secure SMTP over Transport Layer Security''. \end{slide} \begin{slide} \heading{Tout peut être faux} Le principe de LMAP (Lightweight MTA Authentication Protocols) : publier dans le DNS la liste des serveurs SMTP autorisés \emph{pour un domaine}. \end{slide} Rappelons que, sans LMAP ni PGP, déterminer l'authenticité d'un message nécessite une analyse soignée des en-têtes par un expert. Le but de LMAP est de rendre cette analyse automatique. Donc, but de LMAP : authentifier le canal SMTP. On en attend : \begin{itemize} \item Un meilleur fonctionnement des listes blanches \item Une meilleure lutte contre le \foreign{phising} \item Une meilleure lutte contre le \foreign{spam} \end{itemize} \begin{slide} \ifpdf \includegraphics[scale=0.32]{lmap.pdf} \else \includegraphics[scale=0.49]{lmap.eps} \fi \end{slide} Maintenant, que veut dire ``je représente'' ? D'où vient l'adresse \url{smith@example.com} ? \begin{slide} \heading{Petit rappel sur les addresses} Enveloppe : RFC 2821 MAIL FROM (ne change pas en cas de \foreign{forwarding} (\computer{.forward}) mais change en cas de \foreign{remailing} (procmail)). En-têtes : RFC 2822 PRA (Purported Responsible Address) extraite des en-têtes 2822 (typiquement Resent-From puis Sender puis From) \end{slide} L'algorithme PRA tente d'extraire des en-têtes RFC 2822 une adresse unique qui est ``responsable pour la dernière introduction dans le système de courrier''. \begin{slide} \heading{Les choix pour un protocole LMAP} \begin{enumerate} \item identification : que vérifier, 2821 MAIL FROM ou 2822-From: ou PRA \item authentification : comment le vérifier ? \item autorisation : quel langage pour exprimer la liste des serveurs autorisés ? XML or not XML ? \item transport : nouveau type de RR DNS ou bien TXT ? Sous-domaine ? \end{enumerate} \end{slide} \begin{slide} \heading{Les ancêtres} Le document historique de Paul Vixie \url{http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html} RMX (MX inverse) \url{http://www.danisch.de/work/security/antispam.html} % Aussi, l'excellent % \url{http://www.mikerubel.org/computers/rmx_records/} \end{slide} \begin{slide} \heading{Microsoft : Caller-ID} \begin{enumerate} \item identification : PRA (et breveté) \item authentification : Session TCP \item autorisation : XML \item transport : TXT RR dans un sous-domaine \dns{_ep} \end{enumerate} \begin{info} % dig +short TXT _ep.hotmail.com " list1._ep.hotmail.com " \end{info} \end{slide} \begin{slide} \heading{Le plus déployé : SPF} Sender Policy Framework \url{http://spf.pobox.com/} Créé et maintenu par Pobox. \end{slide} \begin{slide} \heading{SPF en quatre points} \begin{enumerate} \item identification : 2821 MAIL FROM (casse le \foreign{forwarding}) \item authentification : Session TCP \item autorisation : langage texte \computer{v=spf1 mx/25 -all} \item transport : TXT RR dans le domaine (motivation principale : faciliter le déploiement par tous) \end{enumerate} \end{slide} \begin{slide} \heading{SPF en pratique} Publier le SPF : trivial si on peut éditer le fichier de zone (piège avec les sous-domaines, toutefois). Mais tout le monde n'a pas accès au fichier de zone (\foreign{provisioning issue}). Problème des interfaces ``conviviales''. \end{slide} \begin{slide} \heading{SPF déployé} Nombre de déploiements : dans les cinquantes domaines dans \dns{fr} mais en rapide augmentation (et un pourcentage bien plus grand dans \dns{de}). Beaucoup de grands noms. \end{slide} \begin{slide} \heading{Vérifier le SPF} Mises en oeuvre pour tous les MTA. Au moins trois bibliothèques libres. Exemple avec Postfix et un \foreign{policy server} trivial sur la prise \computer{policy}, écrit en Perl avec \computer{Mail::SPF::Query} : \begin{info} smtpd_recipient_restrictions = ... check_policy_service unix:private/policy, ... \end{info} \end{slide} \begin{slide} \heading{La syntaxe SPF} \begin{info} v=spf1 mécanisme:[valeur] ... \end{info} Exemple : \begin{info} % dig +short TXT freebsd.org "v=spf1 ip4:216.136.204.119 ~all" \end{info} Mécanismes typiques : \begin{itemize} \item a: adresses IP du domaine (v4 ou v6) \item mx: enregistrements MX \item ip4: adresses IPv4 \item all: tout l'Internet \end{itemize} \end{slide} ``a'' désigne les adresses d'un domaine (indiqué en valeur). ``ip4'' ou ``ip6'' donnent directement les adresses. Ils sont donc moins souples en cas de renumérotation mais nécessitent moins de requêtes DNS. \begin{slide} \heading{Préfixes SPF typiques} Devant le mécanisme (+ par défaut) : \begin{itemize} \item ``+'' ajouter \item ``-'' enlever \item ``?'' ne sais pas \item ``\~{}'' probablement pas \end{itemize} \end{slide} \begin{slide} \heading{Exemples SPF} \begin{info} nordnet.fr. IN TXT \ "v=spf1 mx ptr ip4:194.206.126.0/24 ~all" \end{info} Tous les MX de \dns{nordnet.fr}, toutes les machines dont le nom se finit en \dns{nordnet.fr}, tout 194.206.126.0/24 peuvent envoyer du courrier pour \dns{nordnet.fr}. Pour le reste de l'Internet, c'est douteux. \end{slide} \begin{slide} \heading{Résultats SPF à l'AFNIC} Dans le monde réel : encore trop peu d'enregistrements SPF et trop ``laxistes'' (\computer{?all}). Certains spammeurs se font avoir : \dns{cedex.net} publie du SPF et stoppe donc le \foreign{phising}. Ajouter un test SPF à DNSDoctor ? \computer{\textbf{censuré}.fr} publie un enregistrement SPF invalide\ldots \end{slide} \begin{slide} \heading{Résultats SPF à l'AFNIC, suite} Boîte personelle : 10 \% de "SPF pass", aucun "SPF fail", le reste est neutre. Boîtes officielles de l'AFNIC (nic@, hostmaster@, etc) : 2 \% de "SPF pass", aucun "SPF fail", le reste est neutre. Sur ma boîte spam : 2 \% de "SPF pass" (les spammeurs peuvent mettre du SPF eux-aussi), 1 \% de "SPF fail", le reste est neutre. \end{slide} \begin{slide} \heading{Le protocole IETF, Sender-ID} En \foreign{Working Group Last Call} depuis le 23 août. \begin{enumerate} \item identification : PRA (menace de brevet Microsoft) ; 2822 Resent-From puis Sender puis From. \item authentification : Session TCP \item autorisation : langage texte, celui de SPF \item transport : TXT RR dans le domaine puis nouveau type de RR \end{enumerate} \end{slide} \begin{slide} \heading{Techniques non-LMAP} DomainKeys : authentification du domaine par la cryptographie OpenPGP, S/MIME : authentification de l'émetteur par la cryptographie \end{slide} \begin{slide} \heading{L'avenir} Sender-ID sera t-il déployé ? SPF résistera t-il ? Que feront les spammeurs ? Quelle sera l'ampleur des dégâts collatéraux lorsque le déploiement de LMAP commencera sérieusement ? Sender-ID a été rejeté par Apache, Postfix, Courier, Exim, la FSF, etc en raison du brevet Microsoft. Le débat a posé la question de la politique IPR de l'IETF. \end{slide} \begin{slide} \heading{L'avenir unifié} ``Unified SPF'' essaie de reprendre les enregistrements SPF mais en les appliquant à d'autres addresses que le 2821 MAIL FROM (par exemple au PRA) : un sur-ensemble qui mettra tout le monde d'accord ? \end{slide} \end{document}