La rotation des clés cryptographiques, action de changer régulièrement les clés utilisées, est une chose importante : elle permet de se séparer de clés ayant des caractéristiques qui ne sont plus adaptées à l'ère du temps (genre une clé RSA < 2048 bits n'est pas adaptée à 2016), elle permet de limiter l'impact d'une éventuelle compromission de la clé privée, etc.

DKIM, mécanisme de signature cryptographique de quelques entêtes des emails sortants afin de prouver qu'ils ont bien été émis par un des serveurs de mails autorisés à envoyer des emails pour un domaine donné, n'échappe pas à la règle. Cela fait 4 ans que j'utilise DKIM sur les serveurs de mails que j'administre… soit 4 ans que je n'ai pas changé mes clés. :) C'est désormais chose faite et j'voulais partager ici un retour d'expérience en deux points.

Pour générer facilement une paire de clés, j'utilise le soft opendkim-genkey qui est fourni dans le package Debian GNU/Linux facultatif opendkim-tools. Il permet de générer la paire de clés ainsi que l'enregistrement qu'il faudra mettre dans le DNS. Que du bonheur. Exemple d'utilisation : opendkim-genkey -b 2048 -s default-2016 . 2048 est la taille de la clé, en bits et « default-2016 » est le sélecteur (voir ci-dessous). Compte-tenu de l'usage (on ne fait pas de la "vraie" crypto), une taille de 2048 bits me semble appropriée. C'est également le minimum recommandé par le RGS de l'ANSSI quand on cause de RSA (voir http://www.ssi.gouv.fr/entreprise/reglementation/administration-electronique/liste-des-documents-constitutifs-du-rgs-v-2-0/ document B1 ).

Contrairement à ce que l'on voit habituellement dans le monde du DNS (DNSSEC et DANE, par exemple), il ne peut y avoir deux clés DKIM différentes dans une même zone à un même instant. Il ne peut y avoir deux enregistrements « default._domainkey » de type TXT. Si c'est le cas, OpenDKIM ne valide pas la signature des mails émis par ce domaine et indique : « Authentication-Results: [...] dkim=permerror reason="verification error: multiple keys found; [...]" ». On ne peut donc pas faire de la prépublication c'est-à-dire publier la nouvelle clé dans le DNS, continuer à utiliser l'ancienne paire de clés pendant qu'on laisse les caches DNS expirer puis utiliser la nouvelle paire de clés quand on sera sûrs que tous les récursifs-cache DNS de la planète pourront en récupérer la partie publique.

Avec DKIM, pour faire une rotation des clés, il faut utiliser un sélecteur différent que l'on peut assimiler à un nom, un label attribué à une paire de clés. Il suffit donc de générer une nouvelle paire de clés avec un sélecteur différent de celui utilisé en ce moment (le plus simple est de mettre l'année dans ce nom ;) ), de pousser la partie publique dans le DNS, de bien vérifier que la publication est OK, puis de modifier les paramètres « KeyFile » et « Selector » dans la config' d'OpenDKIM puis de redémarrer OpenDKIM. Ainsi, tous les mails sortants seront désormais signés en utilisant la nouvelle paire de clés et les serveurs mails destinataires pourront la vérifier sans attendre l'expiration du cache DNS.