Rotation des clés DKIM

Source : M3AAWG DKIM Key Rotation Best Common Practices (M3AAWG078, 2013, révisé en mars 2019 ; URL de référence m3aawg.org/DKIMKeyRotation). La révision de 2019 a fait passer le cycle recommandé de trimestriel à tous les six mois et a remanié la convention de nommage des sélecteurs. Les mécanismes de DKIM (syntaxe de la signature et de l’enregistrement de clé, algorithmes) sont décrits dans DKIM ; cet article porte sur la pratique de la rotation.

Pourquoi faire tourner les clés

• Les clés publiques DKIM sont publiées dans le DNS et ouvertes à l’examen, ce qui en fait une cible. Réduire la durée de vie active d’une paire de clés limite les dégâts si une clé est cassée ou volée sur un système de signature compromis.
• Longueur de clé et cassage (RSA, selon le document) : les clés de 512 bits se cassent en quelques heures (Zachary Harris en a cassé une en environ 72 heures pour environ 75 $ de calcul AWS en 2012 ; les clés de 512 bits ont été formellement rendues obsolètes par la RFC 8301 en janvier 2018) ; les clés de 1024 bits sont « à la limite de l’attaque » pour des systèmes généralistes ; les clés de 2048 bits sont considérées comme impossibles à casser dans l’environnement informatique actuel. Des États pouvaient casser des clés de 768 bits dès 2012 environ.
• Une rotation régulière construit un savoir-faire interne, si bien qu’une rotation d’urgence hors cycle après une compromission est rapide. (Google a fait tourner ses clés en quelques jours après la divulgation de 2012 ; d’autres entreprises ont mis des mois.)

Fréquence

Faites tourner les clés au moins tous les six mois. Les membres du M3AAWG ont conclu qu’une rotation semestrielle équilibre le risque de compromission et l’effort opérationnel pour les organisations aux flux complexes et dépendantes de tiers ; les flux plus simples peuvent tourner plus souvent (une rotation trimestrielle réduit encore le risque de cassage, si l’exploitation le permet). Une rotation annuelle est déconseillée : elle augmente le risque de compromission et érode le savoir-faire interne. Choisissez des dates hors des pics d’activité, par exemple avril et octobre pour l’e-commerce.

Une rotation régulière apporte aussi : l’efficacité entre services (l’équipe DNS n’est pas l’équipe email), l’efficacité entre fournisseurs (les expéditeurs tiers pratiquent la procédure), la conformité ITIL/ISO-IEC-20000 (une rotation planifiée est un « changement standard », pas un « changement d’urgence »), l’automatisation (scripts de génération de clés, etc. ; le M3AAWG insiste deux fois sur le développement de scripts), ainsi que la redondance et la relève des compétences.

La procédure de rotation

État de départ (nouveau déploiement DKIM) : générer deux paires de clés (≥1024 bits), publier les deux clés publiques dans le DNS, attendre la propagation, signer avec la clé privée 1. La clé 2 attend son tour (« prochaine en ligne »).

dkim1._domainkey.example.com   ← clé publique 1 active, utilisée pour signer
dkim2._domainkey.example.com   ← clé publique 2 publiée pour un usage futur

À chaque rotation :

1. Générer la paire de clés suivante (clé 3) et publier sa clé publique dans le DNS ; attendre la propagation avant de l’utiliser.
2. Faire passer le signataire de la clé privée 1 à la clé privée 2.
3. Conserver la clé publique 1 dans le DNS sans modification pendant au moins 7 jours et jusqu’à 30 jours, pour que les serveurs de réception puissent encore valider le courrier en transit ou dont la validation est différée.
4. Retirer ensuite la clé 1 en laissant vide le champ p= de l’enregistrement ("v=DKIM1; p="). Ne supprimez pas l’enregistrement du sélecteur : le p= vide signale que la clé a été retirée intentionnellement.

Répéter 1→2, 2→3, 3→4… Exemple après la rotation de la clé 2 vers la clé 3 :

dkim1._domainkey.example.com   ← retirée ("p=")
dkim2._domainkey.example.com   ← valide encore l'ancien courrier pendant 7 à 30 jours
dkim3._domainkey.example.com   ← signe le courrier actuel
dkim4._domainkey.example.com   ← prête pour un usage futur

Remarques d’exploitation :

• Inscrivez les activités liées aux clés (génération, retrait) dans un calendrier opérationnel récurrent. Les étapes peuvent être regroupées sur une seule journée par rotation (ajouter la clé n+2 et retirer la clé n−1 le jour même où l’on change de clé de signature) au lieu d’être étalées sur plusieurs jours : le calendrier doit simplement laisser le temps de la propagation DNS avant de signer avec une nouvelle clé, et le temps de livraison du courrier en transit avant de retirer une ancienne clé.
• Les signatures DKIM prennent en charge une date d’expiration (x= dans la signature selon la RFC 6376 ; le texte du document l’appelle t=, que la RFC 6376 définit comme l’horodatage de la signature) ; elle peut garantir que les signatures ne survivent pas à la période de rotation, mais seulement si la rotation a la certitude d’avoir lieu avant l’expiration des signatures.
• Les serveurs DNS doivent prendre en charge les enregistrements TXT longs pour les clés de 1024 bits et plus : EDNS0 ou la récupération des enregistrements par TCP sont nécessaires.
• Conseils d’exploitation de la RFC 4871 cités par le document : ne signez pas avec une clé dont le sélecteur sera révoqué avant que les vérificateurs puissent valider ; lors d’une rotation, commencez immédiatement à signer avec la nouvelle clé et conservez l’ancienne clé publique « pendant un intervalle de validation raisonnable ».

Schémas de nommage des sélecteurs

Le sélecteur devrait contenir assez d’informations pour faciliter la rotation. Ne réutilisez jamais un nom de sélecteur : la réutilisation fait échouer la revalidation des anciens messages avec la nouvelle valeur de clé et pose problème aux serveurs de réception qui ont gardé en cache des enregistrements périmés.

Convention suggérée : préfixer par le service ou le flux responsable, et inclure la longueur de clé et la date d’activation prévue. Par exemple, sales-201309-1024 = flux « sales », mis en service en septembre 2013, clé de 1024 bits. Un sélecteur peut contenir la longueur de clé, la date et/ou une chaîne aléatoire.

Les sélecteurs datés permettent l’audit (voir plus bas) : après une rotation au 1er avril, chaque message échantillonné devrait être signé avec un sélecteur contenant une date du type 20130401.

Domaines tiers et délégués

La demande de rotation doit venir du propriétaire du domaine organisationnel (en général le client de l’ESP). Le M3AAWG ne recommande pas que les tiers déclenchent la rotation à la place de leurs clients : il vaut mieux apprendre aux clients à effectuer la rotation selon ce document. Ne partagez jamais les mêmes clés DKIM entre plusieurs entités.

Trois modèles de délégation :

1. Délégation de clé via le domaine ou un sous-domaine (clés détenues par le client)

Le client génère les paires de clés, publie les clés publiques dans son domaine (ou un sous-domaine) et transmet la clé privée au tiers de façon sécurisée : uniquement par email chiffré (GPG) ou SFTP. N’envoyez jamais une clé privée par email non chiffré ou par tout autre moyen interceptable ; les clés privées ne devraient jamais être enregistrées en local. Cela exige une coordination à chaque rotation. Variante : le tiers génère la paire et remet la clé publique au client pour publication dans le DNS ; aucune clé privée ne circule, mais le client doit confirmer les paramètres de la clé (taille, etc.) et convenir de la date de retrait.

2. Délégation de clé via un sous-domaine délégué

Le client délègue un sous-domaine au tiers, qui crée lui-même tous les enregistrements. C’est souple, mais cela ajoute un risque sans rapport avec la rotation : le tiers pourrait publier sur le sous-domaine un enregistrement DMARC qui remplace la politique de l’organisation. Auditez tous les domaines délégués.

3. Délégation de clé via CNAME

Le détenteur du domaine publie trois entrées CNAME dans le domaine principal, qui pointent vers des enregistrements contrôlés par le tiers ; le tiers garde une clé valide pendant qu’il fait tourner les autres (key_1 expirée → key_2 en signature → key_3 prochaine en ligne) :

key1._domainkey.example.com  CNAME  key1.example.com.acme.com
key2._domainkey.example.com  CNAME  key2.example.com.acme.com
key3._domainkey.example.com  CNAME  key3.example.com.acme.com

key1.example.com.acme.com  TXT  "v=DKIM1; p="            (expirée)
key2.example.com.acme.com  TXT  "v=DKIM1; p=ADfe34556…"  (en signature)
key3.example.com.acme.com  TXT  "v=DKIM1; p=A783Fg4556…" (prochaine)

Le tiers peut alors faire tourner les clés à son propre rythme sans toucher de nouveau au DNS du client. (C’est le modèle qu’utilisent la plupart des ESP ; les trois modèles de délégation sont aussi traités dans les meilleures pratiques M3AAWG pour les domaines d’envoi.)

Préparation

• Inventaire : recensez tous les flux de messagerie (transactionnel, marketing, conversationnel ou d’employés) et identifiez qui gère chaque domaine et chaque flux ; chacun est partie prenante de la génération, de la publication et de l’utilisation des clés DKIM. Auditez les fusions et acquisitions pour y trouver des flux inconnus. Une politique DMARC p=none avec rapports agrégés RUA est un bon outil de découverte des flux : les rapports quotidiens montrent quel courrier est envoyé (ou prétendument envoyé), avec des signatures DKIM valides ou absentes.
• Discutez des objectifs avec toutes les parties : personne, pas même les fournisseurs tiers, ne devrait être pris au dépourvu au moment de la rotation.
• Parties prenantes : administrateurs email internes, administrateurs DNS, personnel de support, ainsi que les contacts clients et techniques chez les fournisseurs tiers ; documentez la façon dont les modifications de flux sont déclenchées (ticket, demande officielle, clause contractuelle…).
• Préparation aux incidents : soyez prêt à tout moment pour une rotation d’urgence non planifiée. Publier à l’avance la prochaine clé publique dans le DNS signifie qu’une rotation d’urgence ne demande l’intervention que de l’administrateur de messagerie, soit le plus petit groupe de personnes possible.

Audit

• Planifiez un audit peu après chaque rotation (par exemple une semaine plus tard) pour confirmer qu’elle a eu lieu et qu’elle a réussi.
• Tenez un registre des rotations : pour chaque flux de messagerie, tous les domaines et sous-domaines, tous les sélecteurs avec leurs périodes d’activité, et les personnes responsables.
• Auditez en comparant les valeurs d=/s= des signatures des messages échantillonnés avec les valeurs attendues dans le registre. Un schéma de nommage strict des sélecteurs (surtout s’il est daté) simplifie les audits ponctuels et permet l’audit automatisé ; un sélecteur erroné signale à la fois l’échec de la rotation et (avec un bon schéma de nommage) l’endroit où chercher.

Références citées par le document

RFC 6376 (signatures DKIM), RFC 5585 (présentation du service), RFC 5863 (déploiement et exploitation), RFC 8301 (mise à jour sur les algorithmes et l’usage des clés), RFC 3766 et keylength.com (robustesse des clés), Best Practices for Implementing DKIM To Avoid Key Length Vulnerability du M3AAWG (rév. juillet 2017), et l’article de Wired

« How a Google Headhunter’s E-Mail Unraveled a Massive Net Security Hole » (24 octobre 2012).