Note:
DKIM est un protocole permettant d’authentifier l’expéditeur du message et de vérifier son intégrité par des moyens cryptographiques. En savoir plus ici.
Pour rappel, DKIM implique l’usage d’une clé privée et d’une clé publique. On se réfère à une paire de clés par un sélecteur et la clé publique est publiée dans un enregistrement DNS. DKIM prévoit le renouvellement des clés. Mais pourquoi faudrait-il renouveler les clés ? Il y a deux raisons.
La première est de se prémunir d’une compromission de la clé. De la même manière que l’on renouvelle les mots de passe régulièrement, on fait de même avec les clés. Ceci étant, on peut raisonnablement supposer qu’une clé RSA de 4096 bits ne soit pas compromise facilement.
La deuxième raison est plus “politique”.
Lien:
L’article sur lequel se base cet argument est disponible ici : Ok Google: please publish your DKIM secret keys.
L’idée est que DKIM a été conçu pour assurer l’authenticité de l’expéditeur et l’intégrité du mail pendant que celui-ci est en transit. C’est une très bonne chose, car si la clé n’est pas compromise (et que DNSSEC est utilisé), alors on peut avoir l’assurance que le mail provient bien du serveur que l’on pense et que son contenu n’a pas été modifié.
Ceci étant, l’effet de bord est le suivant : des années après, on peut toujours valider l’authenticité et l’intégrité d’un mail, alors que celui-ci est arrivé à destination depuis bien longtemps.
Important:
Avec DKIM, l’intégrité et l’origine de mails piratés peut être vérifiée cryptographiquement pour une durée illimitée, sans que les utilisateurs puissent choisir, puisque c’est le serveur de soumission qui signe le mail.
Or, le but originel de DKIM est d’empêcher des spammeurs de modifier un mail en transit par des relais non-sécurisés, ou de forger un faux mail. C’est essentiellement une mesure anti-spam, dont l’objectif n’a jamais été de garantir la non répudiation ou l’intégrité d’un mail à vie.
Note:
Cette utilisation de DKIM n’est pas hypothétique : de nombreux mails leakés ont été authentifiés grâce à DKIM (voir cet article de Wikileaks).
L’idée n’est pas vraiment de discuter si cet effet de bord est souhaitable, mais plutôt de noter que ce n’est pas le but de DKIM ni ce à quoi on s’attend en envoyant un mail. Lorsque j’envoie un mail que je ne signe pas moi-même, je ne m’attends pas à ce que le serveur mail l’authentifie cryptographiquement à vie.
L’auteur de l’article argumente que cet effet de bord peut créer des incitatifs au piratage de mail et au chantage. D’un autre côté, on pourrait argumenter que l’authenticité garantie par DKIM dans les mails concernant des scandales politiques est une bonne chose.
Note:
L’argument consiste finalement à dire que le mail n’est pas censé empêcher le déni plausible (ou plausible deniability en anglais), terme couramment employé dans les communications chiffrées pour désigner que personne ne peut prouver cryptographiquement que j’ai bien envoyé tel ou tel message. Par exemple, Signal garantit le déni plausible : les messages peuvent avoir été écrits par l’une ou l’autre des parties d’une conversation sans que l’on puisse prouver quoi que ce soit. Les utilisateurs de mail devraient pouvoir choisir s’ils souhaitent renoncer à vie au déni plausible.
Pour éviter cet effet de bord, il faut donc :
Inspiré de la création d'une clé DKIM.
On se rend dans le conteneur mail, dans le dossier /etc/dkimkeys. Ce dossier correspond à un volume Docker persistent dont le chemin réel n’est pas important.
$ docker exec -it pica-mail-mta bash # cd /etc/dkimkeys
On lance ensuite :
opendkim-genkey -b 4096 -s <mAAAA> -d picasoft.net
Note:
Cette commande génère une paire de clés DKIM (RSA/4096 bits), valides pour le nom de domaine picasoft.net et avec un sélecteur au format mAAAA (e.g. janv2021 pour janvier 2021). Le nom du sélecteur est arbitraire.
Les fichiers créés ont pour nom <mAAAA>.private pour la clé privée et <mAAAA>.txt pour l’enregistrement DNS qui contient la clé publique.
Attention:
Renommer <mAAAA>.private en <mAAAA>.picasoft.net.rsa pour un changement transparent au redémarrage de Postfix et lui assigner les bonnes permissions :
mv <mAAAA>.private <mAAAA>.picasoft.net.rsa chmod 600 <mAAAA>.picasoft.net.rsa chown opendkim:opendkim <mAAAA>.picasoft.net.rsa
Le fichier .txt contient déjà l’enregistrement DNS pré-formaté, ce qui rend facile sa publication. Il suffit de le rajouter au fichier de zone et de redémarrer le serveur DNS. On trouvera un peu de documentation sur le serveur DNS de Picasoft sur cette page.
On peut ensuite vérifier que l’opération a bien fonctionné avec la commande suivante :
dig -t txt <mAAAA>.picasoft.net._domainkey
La troisième étape est de modifier la clé DKIM utilisée par Postfix. À ce jour, la modification se fait dans le docker-compose.yml du serveur de mail, via la variable d’environnement DKIM_SELECTOR.
Une fois la modification faite, on redémarrage le conteneur Postfix.
Pour tester si la modification a fonctionné, on peut s’envoyer un mail depuis une adresse Picasoft (mail de test Mattermost, par exemple). On cherche le header DKIM-Signature et on vérifie que le sélecteur correspond bien au nouveau <mAAAA>. À ce stade, on peut supposer que cela fonctionne sans vérifier manuellement l’intégrité du message…
Note:
Pour le moment, cette publication n’est pas faite car par encore discutée/votée.
Important:
À ne faire qu’après quelques jours d’utilisation de la nouvelle clé, pour laisser le temps aux mails retardataires d’arriver et d’être vérifiés par les destinataires.
On peut “révoquer” l’ancienne clé en supprimant tout ce qui se trouve après p= dans l’enregistrement DNS. Elle ne sera alors plus utilisable automatiquement (ce qui ne pose aucun souci, puisque DKIM n’est utilisé en théorie qu’à la fin du transit, plus jamais ensuite).
On peut enfin publier la clé privée à un endroit que l’on aura défini.
Lien:
Une astuce propose de publier la clé privée directement dans la zone DNS.