DKIM et cryptographie post-quantique : gardez votre calme et corrigez les bases

La cryptographie post-quantique est un enjeu bien réel, mais toutes les composantes de la pile de sécurité de l'email n'y sont pas exposées de la même manière. De nombreux commentaires réduisent tout le sujet à « collecter maintenant, déchiffrer plus tard » : les attaquants collectent aujourd'hui du trafic chiffré, attendent qu'un ordinateur quantique suffisamment puissant existe, puis le déchiffrent plus tard. C'est une préoccupation sérieuse pour le contenu chiffré (PGP, S/MIME, TLS, VPN, sauvegardes, archives), mais ce n'est pas le bon modèle pour DKIM.

DKIM n'est pas un mécanisme de confidentialité. Il ne chiffre pas le message. C'est un signal d'authentification évalué lorsque le destinataire traite l'email. Le destinataire vérifie l'en-tête DKIM-Signature par rapport à une clé publique publiée sous un sélecteur dans le DNS, et ce résultat alimente la politique locale ainsi que DMARC. La préoccupation post-quantique pour DKIM n'est pas que les emails signés aujourd'hui seront déchiffrés plus tard. La préoccupation est la falsification future. Si les signatures de type RSA deviennent cassables, un attaquant pourrait créer des signatures DKIM apparemment valides pour des emails usurpés, à moins que l'écosystème n'ait migré vers des schémas de signature résistants aux attaques quantiques.

Cela compte, mais l'urgence est différente. Le NIST a standardisé des algorithmes de signature numérique post-quantiques tels que ML-DSA, et les organismes de normalisation discutent de l'agilité algorithmique et de l'extensibilité future dans l'authentification des emails. Mais il n'existe pas encore de profil DKIM post-quantique largement déployé, interopérable et prêt pour la production, vers lequel il faudrait se précipiter pour l'intégrer à vos domaines.

Il existe également une réalité pratique de mise en œuvre. Une migration DKIM hybride pourrait éventuellement signifier faire fonctionner en parallèle du matériel de signature classique et post-quantique. Cela a du sens en théorie, mais dans DKIM, les signatures se trouvent dans les en-têtes des messages tandis que le DNS publie des clés publiques associées à un sélecteur. Le vrai travail ne consiste pas simplement à « mettre des signatures post-quantiques dans le DNS ». Il s'agit de s'accorder sur les algorithmes, les formats de clés, les sélecteurs, la gestion des enregistrements DNS, le comportement des vérificateurs, la sémantique des échecs et le traitement de l'alignement DMARC.

DKIM est plus simple que le chiffrement d'une certaine manière, car il n'a pas besoin de protéger le contenu du message dans le temps, mais il est aussi difficile à faire évoluer à l'échelle d'Internet. Le DNS doit porter les clés publiques, et le transport DNS a des contraintes pratiques de taille et de fiabilité qui deviennent plus importantes si les clés publiques post-quantiques sont sensiblement plus grandes que les clés RSA actuelles. Les destinataires traitent des volumes massifs de courrier et évaluent en continu les signatures, donc la performance des vérificateurs compte également. Cela signifie que le secteur doit résoudre non seulement la question de la conception cryptographique, mais aussi les questions d'ingénierie liées à la taille des clés dans le DNS, à la taille des signatures dans les en-têtes, au comportement de recherche, à la mise en cache, au débit et à la compatibilité descendante.

Pour l'instant, il convient de se concentrer sur les bases de l'authentification des emails. Cela signifie des clés DKIM robustes lorsqu'elles sont prises en charge, une gestion rigoureuse des sélecteurs, des sources d'envoi authentifiées et alignées, un DMARC qui dépasse la simple surveillance pour atteindre l'application, ainsi qu'une visibilité continue sur les échecs et les expéditeurs non autorisés. C'est exactement là qu'OnDMARC aide : gérer SPF, DKIM, DMARC, BIMI et MTA-STS, identifier les erreurs de configuration, et maintenir les équipes sur une trajectoire claire vers l'application, plutôt que de traiter l'authentification des emails comme un projet DNS ponctuel.

Le travail post-quantique le plus urgent se situe ailleurs. Faites l'inventaire de l'endroit où vous utilisez la cryptographie à clé publique, en particulier là où la confidentialité doit durer longtemps. Les certificats TLS, les VPN, les sauvegardes chiffrées, les archives de long terme, la signature de code, S/MIME, la PKI privée et les identités machine méritent tous de l'attention avant d'entreprendre des changements spéculatifs sur DKIM. Ce travail commence par la visibilité : quels certificats existent, où sont-ils déployés, quels algorithmes et échanges de clés utilisent-ils, qui en est responsable, et à quelle vitesse peuvent-ils être renouvelés.

Red Sift Certificates gère ce volet. Il couvre la découverte et la surveillance des actifs cryptographiques publics sur les domaines, sous-domaines, certificats et services exposés, y compris la configuration TLS et les détails des certificats. Cela offre aux équipes un point de départ pratique pour la préparation post-quantique. Construisez l'inventaire, comprenez l'exposition, priorisez les risques de confidentialité à long terme, et améliorez l'agilité cryptographique avant qu'une migration forcée n'arrive.

Notre recommandation ? Restez calme et continuez comme d'habitude. Utilisez OnDMARC pour renforcer DKIM et DMARC avec les standards actuels. Demandez à vos ESP et fournisseurs de messagerie leur feuille de route concernant l'agilité algorithmique de DKIM et le support post-quantique futur. Les clients devraient également suivre les travaux DKIM2 de l'IETF dans le cadre de l'évolution plus large vers l'agilité algorithmique de DKIM et une sémantique de traitement des messages plus robuste, tout en les considérant comme des travaux de normalisation en cours plutôt que comme un contrôle post-quantique déployable dès aujourd'hui. Utilisez Red Sift Certificates pour entamer dès maintenant le travail plus large d'inventaire cryptographique et de préparation des certificats.