← RFC Reference

RFC 8463 : Ed25519 pour les signatures DKIM

Pourquoi cela existe

DKIM (RFC 6376) spécifiait à l'origine uniquement RSA pour les signatures. RSA a bien servi, mais il a ses coûts :

• Grandes clés. Une clé publique RSA 2048 bits est ~400 octets en Base64. Les enregistrements TXT DNS ont une limite pratique d'environ 255 octets par chaîne (la plupart des résolveurs supportant jusqu'à ~4096 octets au total), rendant les grandes clés RSA encombrantes et parfois fragiles dans DNS.
• Vérification lente. La vérification de signature RSA, surtout avec des clés plus grandes, consomme un temps CPU mesurable quand un destinataire traite des millions de messages par heure.
• Escalade de taille de clé. La sécurité RSA dépend de la longueur de clé. À mesure que la puissance de calcul croît, les clés 2048 bits devront éventuellement devenir 3072 ou 4096 bits, aggravant le problème DNS.

Ed25519 (Edwards-curve Digital Signature Algorithm utilisant Curve25519) résout les trois problèmes. Ses clés 256 bits offrent une sécurité équivalente à environ 3072 bits RSA, la clé publique est seulement 32 octets (44 caractères Base64), et la vérification est significativement plus rapide.

Comment cela fonctionne

Signature avec Ed25519

Le processus de signature est identique au DKIM standard, avec deux changements : la balise a= utilise ed25519-sha256 au lieu de rsa-sha256, et la clé privée est une clé Ed25519 au lieu de RSA.

1. Canonicalisez les en-têtes et le corps selon les règles RFC 6376.
2. Calculez le hash SHA-256 du corps canonicalisé (balise bh=).
3. Calculez le hash SHA-256 des en-têtes signés plus le hash du corps.
4. Signez le hash d'en-tête en utilisant la clé privée Ed25519.
5. Émettez l'en-tête DKIM-Signature avec a=ed25519-sha256.

Exemple : En-tête DKIM-Signature Ed25519

Enregistrement de clé publique DNS

L'enregistrement de clé utilise k=ed25519 et la clé publique est dramatiquement plus petite que RSA :

Double signature : l'approche recommandée

Pas tous les destinataires supportent encore Ed25519. RFC 8463 recommande la double signature : appliquez à la fois une signature RSA et une signature Ed25519 à chaque message. Les destinataires qui comprennent Ed25519 peuvent vérifier la signature plus forte ; ceux qui ne la comprennent pas reviendront à la signature RSA.

Les deux signatures partagent le même bh= (hash du corps) et h= (en-têtes signés) mais utilisent différents sélecteurs pointant vers différents types de clés dans DNS.

Détails techniques clés

Comparaison de taille de clé

Génération de clé

Format d'enregistrement DNS

Le seul changement par rapport à un enregistrement de clé DKIM standard est k=ed25519. Toutes les autres balises (v=, p=, t=, etc.) fonctionnent de la même manière que pour les enregistrements de clé RSA :

Comportement du destinataire

Quand un destinataire rencontre a=ed25519-sha256 dans un en-tête DKIM-Signature :

1. Recherchez l'enregistrement de clé DNS pour le sélecteur.
2. Confirmez k=ed25519 dans l'enregistrement de clé.
3. Décodez la clé publique de 32 octets à partir de la balise p=.
4. Vérifiez la signature Ed25519 par rapport au hash SHA-256 des en-têtes canonicalisés.

Si le destinataire ne supporte pas Ed25519, il traite la signature comme non vérifiable (pas une défaillance définitive) et continue avec les autres en-têtes DKIM-Signature du message.

Erreurs courantes

• Déploiement d'Ed25519 uniquement sans double signature. Beaucoup de destinataires ne vérifient toujours pas les signatures Ed25519. Abandonner RSA signifie que ces destinataires ne voient pas de signature DKIM valide, ce qui nuit à l'alignement DMARC et à la livrabilité.
• Extraction incorrecte de clé. Les clés publiques Ed25519 au format PEM incluent un préfixe ASN.1. La valeur p= DNS doit être la clé brute de 32 octets, pas la SubjectPublicKeyInfo complète codée en DER. Une erreur à ce stade produit une clé qui semble valide mais échoue la vérification.
• Utilisation d'une ancienne version d'OpenSSL. La prise en charge d'Ed25519 a été ajoutée dans OpenSSL 1.1.1 (septembre 2018). Les versions antérieures ne peuvent pas générer ou vérifier les clés Ed25519. Beaucoup de distributions Linux ont livré une OpenSSL antérieure bien après 2020.
• Supposer qu'Ed25519 remplace RSA aujourd'hui. Ed25519 est la direction future, mais RSA reste la ligne de base que chaque vérificateur DKIM comprend. Prévoyez une double signature pendant au moins les prochaines années.
• Ne pas tester la vérification. Après la publication de l'enregistrement DNS, envoyez des messages de test et vérifiez que les deux signatures sont valides. Des outils comme opendkim-testkey peuvent vérifier l'enregistrement DNS indépendamment.
• Partage de sélecteurs entre types de clés. Utilisez des sélecteurs distincts pour les clés RSA et Ed25519. Un sélecteur ne peut pointer que vers un type de clé. Tenter de surcharger un seul sélecteur provoque des défaillances de vérification.

Impact sur la livrabilité

• Empreinte DNS plus petite. Les clés Ed25519 s'adaptent trivalement aux enregistrements TXT DNS, éliminant les problèmes de fragmentation qui affligent parfois les grandes clés RSA. Moins d'échecs DKIM liés à DNS signifie une authentification plus cohérente.
• Préparation pour l'avenir. À mesure que les tailles de clé RSA doivent augmenter (2048 → 3072 → 4096), le problème DNS s'aggrave. Ed25519 offre une sécurité plus forte sans escalade de taille de clé.
• Vérification plus rapide à grande échelle. Pour les destinataires à haut volume traitant des milliards de messages, la vérification Ed25519 est sensiblement plus rapide que RSA. Cela bénéficie à l'écosystème en réduisant le coût de calcul de l'authentification.
• Démontre la maturité en sécurité. Déployer une double signature Ed25519 montre qu'un expéditeur maintient activement son infrastructure d'authentification. Bien que cela ne soit pas un facteur de notation direct, cela reflète une maturité opérationnelle qui correspond à de bonnes pratiques d'envoi.
• Double signature comme filet de sécurité. Avec deux signatures indépendantes, un message a deux chances de passer la vérification DKIM. Si une signature se casse en raison d'une modification intermédiaire du message, l'autre peut survivre.

Related RFCs