← RFC Reference

DANE — Authentification basée sur DNS pour SMTP TLS

Pourquoi cela existe

SMTP avec STARTTLS a deux problèmes fondamentaux :

1. Pas d'authentification. Un serveur d'envoi n'a aucun moyen fiable de vérifier que le certificat TLS du serveur récepteur est légitime. SMTP n'utilise pas le modèle de confiance des autorités de certification du web — historiquement, la plupart des serveurs de messagerie utilisaient des certificats autosignés, donc les expéditeurs ont appris à accepter n'importe quoi.
2. Attaques de rétrogradation. Un attaquant réseau actif peut supprimer la publicité STARTTLS de la réponse EHLO, forçant la livraison en texte brut.

MTA-STS (RFC 8461) résout ces problèmes en utilisant HTTPS et l'infrastructure de clés publiques du web. DANE les résout en utilisant DNSSEC et les enregistrements TLSA. Les deux approches se complètent : DANE est cryptographiquement plus robuste (pas de confiance en une CA requise), tandis que MTA-STS est plus facile à déployer (DNSSEC non requis).

Comment cela fonctionne

DANE pour SMTP (défini dans RFC 7672, construisant sur la spécification DANE de base dans RFC 6698) fonctionne en trois étapes :

Étape 1 : Zone signée DNSSEC

La zone DNS du domaine récepteur — et la zone de la cible MX — doivent être signées avec DNSSEC. C'est non négociable. Sans DNSSEC, un attaquant pourrait forger des enregistrements TLSA, rendant DANE pire qu'inutile.

Étape 2 : Publier les enregistrements TLSA

Le domaine publie les enregistrements TLSA pour chaque port SMTP de l'hôte MX. Un enregistrement TLSA lie un certificat TLS (ou sa clé publique, ou son autorité de certification) à un service spécifique.

Champs de l'enregistrement TLSA

Étape 3 : Validation par l'expéditeur

Quand un serveur d'envoi prenant en charge DANE livre du courrier à example.com :

1. Résout les enregistrements MX pour example.com avec validation DNSSEC.
2. Pour chaque hôte MX (par exemple, mail.example.com), recherche _25._tcp.mail.example.com TLSA avec validation DNSSEC.
3. Si des enregistrements TLSA validés par DNSSEC existent : se connecte, effectue STARTTLS, et valide le certificat du serveur par rapport aux données TLSA.
4. Si la validation échoue : ne livre pas. Le message est mis en file d'attente pour nouvelle tentative.
5. Si aucun enregistrement TLSA n'existe (ou DNSSEC n'est pas déployé) : bascule vers TLS opportuniste comme avant.

Détails techniques clés

Configuration TLSA recommandée

Pour les serveurs SMTP, RFC 7672 recommande DANE-EE(3) SPKI(1) SHA-256(1) :

C'est le choix le plus robuste car :

• Utilisation 3 (DANE-EE) contourne entièrement la validation de l'autorité de certification. Le certificat n'a pas besoin d'être signé par une autorité de certification publique — un certificat autosigné fonctionne bien.
• Sélecteur 1 (SPKI) correspond à la clé publique, pas au certificat complet. Vous pouvez renouveler votre certificat (en changeant le numéro de série, l'expiration) sans mettre à jour l'enregistrement TLSA, tant que la paire de clés reste identique.
• Type de correspondance 1 (SHA-256) stocke un hash plutôt que la clé complète, gardant l'enregistrement DNS compact.

Génération d'un enregistrement TLSA

# Extraire le hash SHA-256 de la clé publique du serveur
openssl x509 -in server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  openssl dgst -sha256 -hex
(stdin)= 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

# L'enregistrement TLSA résultant :
_25._tcp.mail.example.com. IN TLSA 3 1 1 2a9f8e3b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f

DANE vs. MTA-STS

Erreurs courantes

• Publier TLSA sans DNSSEC. Si votre zone n'est pas signée DNSSEC, les enregistrements TLSA sont ignorés. Pire encore, certaines implémentations peuvent traiter TLSA non signé comme un signal pour ne pas exiger TLS, dégradant la sécurité.
• Oublier de mettre à jour TLSA lors de la rotation des clés. Si vous utilisez le sélecteur 0 (certificat complet) et renouvelez votre certificat avec une nouvelle clé, l'enregistrement TLSA doit être mis à jour avant que le nouveau certificat ne soit actif. Utilisez le sélecteur 1 (SPKI) et conservez la même paire de clés lors des renouvellements pour éviter cela.
• TLSA sur le domaine, pas sur l'hôte MX. L'enregistrement TLSA va sur le nom d'hôte de la cible MX (par exemple, _25._tcp.mail.example.com), pas sur le domaine lui-même. Si votre MX pointe vers un hôte tiers, l'enregistrement TLSA doit être dans leur zone.
• Rotation incorrecte des enregistrements TLSA. Lors de la rotation des clés, publiez les enregistrements TLSA pour les anciennes et nouvelles clés simultanément. Supprimez l'ancien enregistrement seulement après la rotation du certificat et l'expiration des caches DNS.
• Ignorer la chaîne de confiance DNSSEC. Chaque zone de la racine à l'enregistrement TLSA doit être signée DNSSEC. Une rupture quelque part invalide la chaîne entière.

Impact sur la délivrabilité

• Garantie TLS la plus forte. DANE fournit une preuve cryptographique de l'identité du serveur uniquement à partir de DNS. Aucun compromis de CA, aucune fenêtre TOFU — sécurisé dès la toute première connexion.
• Largement déployé en Europe. Les Pays-Bas, l'Allemagne et la Tchéquie ont une adoption DANE élevée pour la messagerie gouvernementale et institutionnelle. Si vous livrez vers ces régions, le support DANE est un avantage significatif.
• Support natif Postfix. Postfix dispose du support DANE intégré (smtp_tls_security_level = dane). Pour les expéditeurs utilisant Postfix, DANE « fonctionne simplement » quand le domaine récepteur a des enregistrements TLSA.
• Complémentaire avec MTA-STS. Déployez les deux. Les expéditeurs qui supportent DANE l'utiliseront (garanties plus fortes) ; les expéditeurs qui ne supportent que MTA-STS utiliseront cela. Les deux sont meilleurs que le TLS opportuniste seul.

Related RFCs