Rotation des clés DKIM

Si vous signez votre courrier avec DKIM, vos clés doivent être remplacées selon un calendrier. Les DKIM Key Rotation Best Common Practices du M3AAWG recommandent à quelle fréquence et comment. Le document porte la référence M3AAWG078, a été publié pour la première fois en 2013 et 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.

Ces recommandations portent sur la pratique de la rotation. Pour le fonctionnement de DKIM lui-même (la syntaxe des signatures et des enregistrements de clé, et les algorithmes), voir DKIM.

Pourquoi faire tourner les clés

• Les clés publiques DKIM sont publiées dans le DNS, où tout le monde peut les examiner, ce qui en fait une cible. Garder courte 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 peuvent être cassées en quelques heures. Zachary Harris en a cassé une en ~72 heures pour ~75 $ de calcul AWS en 2012, et les clés de 512 bits ont été formellement rendues obsolètes par la RFC 8301 en janvier 2018. Une clé de 1024 bits est « à la limite de l’attaque » pour des systèmes généralistes. Une clé de 2048 bits est considérée comme impossible à casser avec la puissance de calcul actuelle. Des États pouvaient casser des clés de 768 bits dès ~2012.
• Une rotation régulière construit un savoir-faire au sein de l’organisation, si bien qu’une rotation d’urgence hors du cycle normal après une compromission peut être faite rapidement. (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 deux fois par an équilibre le risque de compromission et l’effort opérationnel, pour les organisations qui ont des flux de messagerie complexes et des dépendances envers des tiers. Les organisations aux flux plus simples peuvent faire tourner leurs clés plus souvent : une rotation trimestrielle réduit encore le risque de cassage, si l’exploitation le permet. Une rotation annuelle est déconseillée, car elle augmente le risque de compromission et laisse aussi s’effacer le savoir-faire de l’organisation sur la procédure. Choisissez des dates qui évitent les pics d’activité, par exemple avril et octobre pour l’e-commerce.

Une rotation régulière apporte d’autres avantages :

• Les services apprennent à travailler ensemble, puisque l’équipe DNS n’est pas l’équipe email.
• Les expéditeurs tiers pratiquent la procédure, si bien que les fournisseurs travaillent aussi ensemble.
• La rotation est conforme à ITIL et à ISO-IEC-20000, car une rotation planifiée est un « changement standard », et non un « changement d’urgence ».
• Elle mène à l’automatisation, comme des scripts qui génèrent les clés. Le M3AAWG insiste deux fois sur le développement de scripts.
• Elle crée de la redondance, avec davantage de personnes capables de faire le travail.

La procédure de rotation

État de départ, pour un nouveau déploiement DKIM : générez deux paires de clés (≥1024 bits), publiez les deux clés publiques dans le DNS, attendez la propagation DNS, puis signez avec la clé privée 1. La clé 2 est prête, « prochaine en ligne ».

dkim1._domainkey.example.com   ← active public key 1, used to sign
dkim2._domainkey.example.com   ← public key 2 published for future use

À chaque rotation :

1. Générez la paire de clés suivante (clé 3) et publiez sa clé publique dans le DNS. Attendez la propagation avant de l’utiliser.
2. Faites passer le signataire de la clé privée 1 à la clé privée 2.
3. Laissez 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 validé plus tard.
4. Retirez 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 volontairement.

Répétez le cycle : 1→2, 2→3, 3→4 et ainsi de suite. Après la rotation de la clé 2 vers la clé 3, les enregistrements se présentent ainsi :

dkim1._domainkey.example.com   ← retired ("p=")
dkim2._domainkey.example.com   ← still validates old mail for 7–30 days
dkim3._domainkey.example.com   ← signs current mail
dkim4._domainkey.example.com   ← ready for future use

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 d’une rotation peuvent toutes avoir lieu le même jour : ajoutez la clé n+2 et retirez la clé n−1 le jour même où vous changez de clé de signature, au lieu d’étaler le travail sur plusieurs jours. Le calendrier doit seulement laisser le temps de la propagation DNS avant de signer avec une nouvelle clé, et le temps que le courrier en transit soit livré avant de retirer une ancienne clé.
• Les signatures DKIM prennent en charge une date d’expiration. Il s’agit de x= dans la signature selon la RFC 6376 ; le texte du BP l’appelle t=, que la RFC 6376 définit comme l’horodatage de la signature. Une date d’expiration peut garantir que les signatures ne survivent pas à la période de rotation, mais seulement s’il est garanti que la rotation aura lieu avant l’expiration des signatures.
• Les serveurs DNS doivent prendre en charge les enregistrements TXT longs pour les clés de ≥1024 bits, si bien que la récupération des enregistrements par EDNS0 ou TCP est nécessaire.
• Le BP cite les conseils d’exploitation de la RFC 4871 : ne signez pas avec une clé dont le sélecteur sera révoqué avant que les vérificateurs puissent valider la signature. 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

Un 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 validation des anciens messages avec la nouvelle valeur de clé, et elle pose problème aux serveurs de réception qui ont gardé l’ancien enregistrement en cache.

Une convention suggérée : commencez par le service ou le flux responsable, et incluez la longueur de clé et la date d’activation prévue. Par exemple, sales-201309-1024 désigne le flux « sales », une clé mise en service en septembre 2013, et une clé de 1024 bits. Un sélecteur peut contenir la longueur de clé, la date, une chaîne aléatoire, ou une combinaison de ces éléments.

Les sélecteurs qui contiennent une date rendent l’audit possible (voir plus bas). Après une rotation le 1er avril, chaque message que vous échantillonnez devrait être signé avec un sélecteur daté dans le style de 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 pour leurs clients. Apprenez plutôt aux clients à faire tourner leurs clés selon ce BP. Ne partagez jamais les mêmes clés DKIM entre plusieurs entités.

Il existe 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 envoie la clé privée au tiers de façon sécurisée, uniquement par email chiffré (GPG) ou par SFTP. N’envoyez jamais une clé privée par email non chiffré ni par tout autre moyen qui peut être intercepté, et n’enregistrez jamais de clés privées en local. Ce modèle exige une coordination à chaque rotation.

Dans une variante, le tiers génère la paire de clés et remet la clé publique au client pour qu’il la publie dans le DNS. Aucune clé privée n’est transférée, mais le client doit confirmer les paramètres de la clé (comme sa taille) et convenir de la date à laquelle la clé sera retirée.

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 enregistrements CNAME dans le domaine principal, qui pointent vers des enregistrements que contrôle 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="            (expired)
key2.example.com.acme.com  TXT  "v=DKIM1; p=ADfe34556…"  (signing)
key3.example.com.acme.com  TXT  "v=DKIM1; p=A783Fg4556…" (next)

Le tiers peut alors faire tourner les clés selon son propre calendrier sans toucher de nouveau au DNS du client. La plupart des ESP utilisent ce modèle. Les meilleures pratiques M3AAWG pour les domaines d’envoi décrivent aussi les trois modèles de délégation.

Préparation

• Faites l’inventaire de tous les flux de messagerie (transactionnel, marketing, et courrier conversationnel ou d’employés), et identifiez qui gère chaque domaine et chaque flux. Chacun d’eux est partie prenante de la génération, de la publication et de l’utilisation des clés DKIM. Vérifiez les fusions et acquisitions pour trouver des flux que vous ne connaissez pas. Une politique DMARC p=none avec des rapports agrégés (RUA) est un bon moyen de découvrir les flux : les rapports quotidiens montrent quel courrier est envoyé, ou prétend être envoyé, avec des signatures DKIM valides ou absentes.
• Discutez des objectifs avec toutes les parties. Personne, y compris les fournisseurs tiers, ne devrait être pris au dépourvu au moment de la rotation.
• Les parties prenantes comprennent les administrateurs email internes, les administrateurs DNS et le personnel de support, ainsi que les contacts clients et techniques chez les fournisseurs tiers. Documentez la façon dont les modifications d’un flux sont demandées (un ticket, une demande officielle, une clause contractuelle, etc.).
• Soyez prêt en cas d’incident, c’est-à-dire pour une rotation d’urgence non planifiée à tout moment. Si vous publiez à l’avance la prochaine clé publique dans le DNS, 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, notez tous les domaines et sous-domaines, tous les sélecteurs avec les périodes où ils étaient actifs, et les personnes responsables.
• Auditez en comparant les valeurs d= et 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 inclut des dates, simplifie les audits ponctuels et rend possible l’audit automatisé. Un sélecteur erroné révèle à la fois l’échec de la rotation et, avec un bon schéma de nommage, l’endroit où chercher.

Références

Le BP cite : 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), les 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).