12. Considérations de Sécurité

Cette section traite des considérations de sécurité spécifiques à DMARC.

12.1. Méthodes d'Authentification

DMARC est construit au-dessus de SPF et DKIM. La sécurité de DMARC dépend donc de la sécurité de ces mécanismes sous-jacents. Les implémenteurs doivent être familiers avec les considérations de sécurité de SPF [SPF] et de DKIM [DKIM].

Points clés:

1. Sécurité SPF: SPF peut être contourné si un attaquant peut envoyer du courrier via un serveur autorisé dans l'enregistrement SPF.

2. Sécurité DKIM: Les signatures DKIM peuvent être forgées si la clé de signature est compromise. La gestion des clés est critique.

3. Sécurité combinée: L'exigence de DMARC pour l'Identifier Alignment fournit une authentification plus forte que SPF ou DKIM seuls.

12.2. Attaques sur les URIs de Rapport

Un attaquant pourrait tenter de faire en sorte que les récepteurs de courrier envoient de grands volumes de rapports à l'adresse d'une victime en:

1. Publiant un enregistrement DMARC pour un domaine sous le contrôle de l'attaquant avec l'adresse de la victime dans les balises "rua" ou "ruf".

2. Envoyant de grands volumes de courrier non authentifié prétendant provenir de ce domaine.

Le mécanisme de vérification décrit dans la Section 7.1 empêche cette attaque en exigeant que les destinations de rapport externes autorisent explicitement la relation de rapport.

De plus, les récepteurs de courrier doivent:

• Implémenter une limitation de taux sur la génération de rapports
• Surveiller les modèles de rapport inhabituels
• Respecter les demandes de désinscription des destinataires de rapports

12.3. Sécurité DNS

DMARC s'appuie fortement sur le DNS pour la distribution des politiques. Les considérations de sécurité DNS incluent:

1. Usurpation DNS: Un attaquant qui peut usurper les réponses DNS pourrait:

   • Fournir une fausse politique DMARC
   • Rediriger les rapports vers une adresse contrôlée par l'attaquant
   • Causer un déni de service en supprimant les enregistrements de politique

2. DNSSEC: L'utilisation de DNSSEC peut atténuer les risques d'usurpation DNS. Les implémenteurs devraient envisager de déployer DNSSEC pour les domaines publiant des politiques DMARC.

3. Empoisonnement du cache: L'empoisonnement du cache DNS pourrait entraîner la mise en cache et l'application de politiques DMARC incorrectes.

12.4. Attaques par Nom d'Affichage

DMARC ne protège pas contre les attaques sur la partie nom d'affichage du champ RFC5322.From. Un attaquant peut utiliser un nom d'affichage qui semble digne de confiance tout en utilisant un domaine différent dans l'adresse:

From: "Banque de Confiance" <[email protected]>

Les utilisateurs peuvent ne voir que "Banque de Confiance" et ne pas remarquer le domaine d'envoi réel. Cette limitation est explicitement notée comme hors de portée dans la Section 2.2.

L'éducation des utilisateurs et les améliorations du MUA (comme l'affichage proéminent de l'adresse e-mail réelle) sont nécessaires pour traiter cette menace.

12.5. Adresses de Rapport Externes

Lorsque les rapports DMARC sont envoyés à des adresses externes (adresses à des domaines autres que celui sur lequel on rapporte), plusieurs considérations de sécurité s'appliquent:

1. Exposition des données: Les rapports contiennent des informations sur l'infrastructure de courrier électronique du domaine et les modèles de trafic. Ces informations pourraient être précieuses pour les attaquants.

2. Confiance envers les tiers: Les propriétaires de domaines doivent faire confiance aux destinataires de rapports tiers pour:

   • Gérer les données de rapport de manière sécurisée
   • Ne pas abuser des informations
   • Se conformer aux réglementations applicables en matière de confidentialité

3. Vérification: Le mécanisme de vérification de la Section 7.1 garantit que les destinations externes sont autorisées, mais les propriétaires de domaines doivent toujours examiner attentivement les informations qu'ils partagent.

12.6. Protocoles Sécurisés

Bien que DMARC lui-même ne mandate pas l'utilisation de protocoles sécurisés spécifiques, les implémenteurs devraient considérer:

1. DNSSEC: Comme mentionné dans la Section 12.3, DNSSEC peut protéger contre les attaques d'usurpation DNS.

2. TLS pour les rapports: Lors de l'envoi de rapports par e-mail, l'utilisation de STARTTLS ou d'autres mécanismes de chiffrement protège le contenu des rapports en transit.

3. HTTPS pour les URIs de rapport: Si de futures extensions permettent des URIs HTTPS pour la livraison de rapports, TLS devrait être utilisé pour protéger les données de rapport.

4. Stockage sécurisé des clés: Les clés privées DKIM doivent être stockées de manière sécurisée pour éviter toute compromission.

---