SaaSFort DANE et MTA-STS existent tous deux pour arrêter la même attaque : un adversaire en coupure qui retire STARTTLS d’une session SMTP afin que le courrier destiné à votre domaine arrive en clair.
Ils diffèrent par ce qu’ils font confiance pour prouver l’authenticité de la politique, et cette seule différence décide lequel vous pouvez déployer cette semaine.
L’ancre de confiance est toute la distinction
DANE publie dans le DNS un enregistrement TLSA qui épingle le certificat que votre serveur de messagerie présentera. L’enregistrement est authentifié par DNSSEC. Le système d’autorités de certification n’intervient pas, donc une autorité qui émettrait à tort un certificat pour votre domaine ne pourrait pas s’en servir pour intercepter votre courrier.
MTA-STS publie un fichier de politique en HTTPS sur une URL connue d’un sous-domaine mta-sts.. La politique est authentifiée par le certificat de ce sous-domaine, ce qui fait du système d’autorités la racine de confiance.
Cryptographiquement, DANE est plus fort. Opérationnellement, MTA-STS est déployable sur n’importe quel domaine aujourd’hui, car il ne réclame aucun DNSSEC.
La comparaison qui décide vraiment
| DANE | MTA-STS | |
|---|---|---|
| Ancre de confiance | DNSSEC | Autorité de certification |
| Prérequis | Zone signée | Hôte HTTPS pour un sous-domaine |
| Déployable aujourd’hui sans projet | Seulement si DNSSEC est déjà actif | Oui |
| Résiste à une mauvaise émission d’une AC | Oui | Non |
| Résiste à une altération DNS sans DNSSEC | Oui | Oui, politique authentifiée par AC |
| Support côté émetteurs | Largement implémenté, notamment chez les fournisseurs européens | Largement implémenté, notamment chez les grands fournisseurs de boîtes |
La dernière ligne explique pourquoi la réponse honnête est « les deux ». Les émetteurs qui prennent en charge les deux préfèrent DANE et retombent sur MTA-STS quand la validation DNSSEC est indisponible. Ils couvrent des populations de serveurs émetteurs qui ne se recouvrent que partiellement, donc n’en déployer qu’un laisse un trou que l’autre aurait fermé.
La BSI TR-03108 attend les deux, et c’est le raisonnement qui la sous-tend, pas une prudence excessive.
Pourquoi l’ordre est MTA-STS d’abord
Pour un éditeur SaaS sans DNSSEC sur sa zone, la séquence n’est pas vraiment un choix.
Activer DNSSEC est un véritable projet. Cela touche la configuration chez le bureau d’enregistrement, la gestion des clés, la procédure de rotation, et cela comporte un mode de défaillance où une rotation ratée rend tout votre domaine irrésoluble, pas seulement votre courrier. Cela vaut la peine d’être fait. Cela ne vaut pas la peine d’être fait l’après-midi même où vous découvrez que vous n’avez aucune sécurité de transport.
MTA-STS avec TLS-RPT, ce sont deux enregistrements DNS et un fichier statique, avec un mode test qui rend le déploiement observable avant qu’il ne devienne contraignant. Vous pouvez l’avoir en ligne, en test, avant le déjeuner, et en application trois semaines plus tard une fois les rapports propres.
Donc : MTA-STS et TLS-RPT maintenant, DNSSEC et DANE comme projet planifié.
La seule exception est un domaine qui dispose déjà de DNSSEC. Ajoutez alors les enregistrements TLSA en même temps, le coût marginal étant d’une heure.
L’erreur à éviter des deux côtés
Pour MTA-STS, l’erreur est de rester en mode: testing. Le mode test signale les échecs et délivre quand même, donc un domaine qui s’y installe a l’apparence du contrôle et aucune protection. Posez une entrée d’agenda pour la bascule en enforce au moment du déploiement, pas plus tard.
Pour DANE, l’erreur est un enregistrement TLSA qui ne correspond plus au certificat réellement servi après un renouvellement. Avec des durées de vie de certificat qui descendent vers 47 jours, ce risque s’aggrave : chaque renouvellement est une occasion pour l’épinglage de devenir obsolète, et un enregistrement TLSA obsolète ne se dégrade pas en douceur, il bloque le courrier.
Épinglez la clé publique de l’AC plutôt que le certificat terminal (usage TLSA 2 ou 3, sélecteur 1), et automatisez la mise à jour de l’enregistrement en même temps que le renouvellement. Un déploiement DANE sans maintenance automatisée des TLSA cassera, et la baisse des durées de vie décide seulement quand.
Ce que TLS-RPT apporte aux deux
Quel que soit votre choix, TLS-RPT est ce qui vous dit qu’il fonctionne.
_smtp._tls.example.fr. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Du JSON quotidien émis par les fournisseurs expéditeurs, listant les négociations réussies et échouées avec leur motif. Il attrape l’enregistrement TLSA obsolète, l’hôte MX absent de la politique MTA-STS, et le certificat expiré sur le serveur de messagerie secondaire que personne n’a regardé depuis deux ans.
Déployez TLS-RPT avant l’un ou l’autre mécanisme de politique, pour que le premier rapport lu soit une référence et non un incident.
Où cela se mappe
- NIS2 article 21(2)(h) cryptographie, 21(2)(e) sécurité des réseaux.
- ISO/IEC 27001:2022 A.8.24 et A.5.14 transfert d’information.
- DORA article 9 pour les entités financières.
- BSI TR-03108 dans un contexte de supervision allemande.
En résumé
DANE est plus fort, MTA-STS est disponible tout de suite, et les deux couvrent des émetteurs différents : la destination est donc les deux.
Commencez par TLS-RPT pour la visibilité, puis MTA-STS en test, puis en application. Planifiez DNSSEC et DANE comme projet suivant plutôt que comme prétexte à ne rien faire.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.