Enregistrement ADSP pour renforcer DKIM

Encore du www.bortzmeyer.org très intéressant.

Ce billet fait suite à celui sur Opendkim

• DKIM : DomainKeys Identified Mail
• ADSP : Author Domain Signing Practices

Le protocole de signature des messages électroniques DKIM, normalisé dans la RFC 4871, à un petit défaut : si un message ne porte pas de signature, comment savoir si c'est parce que le domaine émetteur ne signe pas ou bien si c'est parce qu'un attaquant a modifié le message et retiré la signature ?

La solution choisie par le groupe de travail DKIM de l'IETF est, comme documenté dans ce RFC 5617, de permettre à un domaine de publier ses pratiques de signature. Désormais, un domaine va pouvoir annoncer dans le DNS qu'il signe tous ses messages (et donc qu'un message sans signature est suspect) ou bien qu'il ne signe pas systématiquement et qu'il faut donc être indulgent à la vérification.

Dans le futur, il est théoriquement possible que DKIM soit tellement largement déployé que cette publication soit inutile, et qu'on puisse considérer que tout message doit être signé. Mais on en est très loin (section 1 du RFC).

Le RFC 5016 avait défini le cahier des charges pour un tel mécanisme de publication des pratiques. Voici donc sa réalisation.

La section 3 de la RFC définit les grandes lignes du mécanisme :

• Publication par l'émetteur, dans le DNS, d'un enregistrement à _adsp._domainkey.mydomain.example, indiquant les pratiques de signature de mydomain.example (mais pas celles des domaines fils comme child.mydomain.example, cf. section 3.1).

• Consultation par le destinataire de cet enregistrement, le nom de domaine utilisé étant celui qui apparait dans le champ From: du message (l'Auteur, en terminologie DKIM). À noter que le message peut avoir des signatures pour d'autres domaines que celui de l'Auteur, par exemple s'il a été transmis via une liste de diffusion qui signe (cf. section 3.2).

• Décision par le destinataire du sort du message, en fonction de ce qu'il a trouvé dans ADSP et de la présence ou pas d'une signature. Par exemple, si un message ne porte aucune signature mais que l'enregistrement ADSP indique que le domaine de l'auteur signe systématiquement, le message est très suspect. Par défaut, la situation actuelle est « pas de signature, pas d'enregistrement ADSP » (cf. section 3.3).

Place maintenant à la description détaillée du protocole, en section 4. Les enregistrements ADSP sont publiés sous forme d'enregistrements TXT. Les objections de la RFC 5507 ne s'appliquent pas ici puisque l'enregistrement n'est pas immédiatement dans le domaine, mais dans _adsp.domainkey.LEDOMAINE. Dans le texte de l'enregistrement, la syntaxe habituelle de DKIM, clé=valeur, est utilisée. Actuellement, seule la clé dkim est définie (section 4.2.1) et elle peut prendre les valeurs suivante :

• unknown : on ne sait pas (c'est la valeur par défaut, s'il n'y a pas d'enregistrement ADSP),
• all : tout le courrier venant de ce domaine est signé,
• discardable : tout le courrier venant de ce domaine est signé et peut être jeté à la poubelle sans remords s'il ne l'est pas.

Des futures valeurs pourront apparaître plus tard dans le registre IANA (section 5).

On retrouve, dans le choix d'une valeur pour la clé dkim, un problème classique de l'authentification : que faire lorsqu'elle échoue ? Si on met unknown, ADSP ne sert à rien puisque le récepteur n'a aucune idée de s'il peut agir ou non. Si on met discardable, on fait courir un grand risque à son courrier puisque une bête erreur comme l'expédition d'un message depuis un site qui ne signe pas pourra entrainer la destruction du message. Je fais le pronostic que, par prudence, les émetteurs n'utiliseront que unknown ou all et les récepteurs ne jetteront le message que lorsqu'un discardable apparait. En pratique, il est donc probable qu'aucun message abusif ne sera éliminé par ADSP.

Les tests faits suite à des requêtes ADSP peuvent donc fournir des informations sur l'authenticité d'un message et ces informations peuvent être publiées dans un en-tête Authentication-Results: du RFC 5451. La méthode dkim-adsp s'ajoute donc aux méthodes d'authentification utilisables (section 5.4).

La section 6, les questions de sécurité, explore les risques et les problèmes associés à ADSP. Elle note par exemple, ce qui est plutôt amusant, que puisque des MUA très courants comme Outlook n'affichent pas l'adresse de courrier de l'expéditeur, authentifier le domaine de celle-ci (tout le but de ADSP) n'apporte pas grand'chose avec ces MUA.

Comme ADSP dépend du DNS, il en partage les vulnérabilités, et l'usage de DNSSEC peut donc être nécessaire.

Voici un exemple de requête dig pour trouver l'enregistrement ADSP de system-linux.org :

dig +short TXT _adsp._domainkey.system-linux.org  
"dkim=all"

D'autres exemples, très détaillés figurent en annexe A, couvrant les différents cas.

L'annexe B est très intéressante et couvre plusieurs scénarios d'utilisation typiques, où l'usage d'ADSP n'est pas complètement évident. Le cas des listes de diffusion n'y apparait pas, alors qu'elles sont souvent un des plus gros casse-têtes avec DKIM. Si une liste de diffusion respecte le message original et ne le modifie pas, pas de problème. Elle peut laisser l'éventuelle signature DKIM originale (et, si elle le souhaite, ajouter sa propre signature, mais qui ne pourra pas utiliser ADSP puisque le domaine de l'auteur n'est pas celui de la liste). Mais si la liste modifie les messages, par exemple pour ajouter de la publicité à la fin, ou pour ajouter une étiquette dans le sujet, alors la signature DKIM originale ne correspondra plus. Le message sera alors jugé comme étant de la triche (ce qu'il est, puisque le message originel a été changé). Si le programme gestionnaire de listes supprime la signature et que le domaine de l'auteur publiait avec ADSP dkim=discard, ce n'est pas mieux, le message sera également considéré comme faux.

À l'heure actuelle, les mesures faites par DNSdelve montrent qu'il n'existe quasiment aucun domaine publiant de l'ADSP sous .fr.

Créer un enregistrement ADSP avec Bind9, a mettre dans votre fichier db.votre-domaine.xx sans oublier d'incrémenter votre serial :

;** ADSP pour renforcer DKIM

_adsp._domainkey.system-linux.org. TXT "dkim=all"

C'est un peu technique mais interessant pour ceux dont c'est le métier , en luttant contre le spam chacun de son coté on lutte ensemble contre ce fléau mondial.

Source : http://www.bortzmeyer.org/5617.html