11. Security Considerations
Cette page resume la section correspondante du RFC 9989 et conserve les tags DMARC, noms DNS, ABNF et valeurs IANA.
The security considerations from Section 11 are preserved below.
11. Security Considerations
This section discusses security issues and possible remediations
(where available) for DMARC.
11.1. Authentication Methods
Security considerations from the authentication methods used by DMARC
are incorporated here by reference.
Both of the email authentication methods that underlie DMARC provide
some assurance that an email was transmitted by an MTA that is
authorized to do so. SPF policies map domain names to sets of
authorized MTAs (see Section 11.4 of [RFC7208]). Validated DKIM
signatures indicate that an email was transmitted by an MTA with
access to a private key that matches the published DKIM key record.
Whenever mail is sent, there is a risk that an overly permissive
source may send mail that will receive a DMARC "pass" result that was
not, in fact, intended by the Domain Owner. These results may lead
to issues when systems interpret DMARC "pass" results to indicate a
message is in some way authentic. They also allow such unauthorized
senders to evade the Domain Owner's intended message handling for
DMARC validation failures.
To avoid this risk, one must ensure that no unauthorized source can
add DKIM signatures to the domain's mail or transmit mail that will
evaluate as an SPF "pass" result. Nonetheless, if a Domain Owner
wishes to include a permissive source in a domain's SPF record, the
source can be excluded from DMARC consideration by using the "?"
qualifier on the SPF record mechanism associated with that source.
The DMARC Working Group had a lively discussion about possibly
eliminating SPF entirely as an underlying authentication mechanism
for DMARC, but consensus was not reached, and the suggestion to use
the "?" qualifier for permissive sources is presented here instead.
11.2. Attacks on Reporting URIs
URIs published in DNS TXT records are well-understood possible
targets for an attack. Specifications such as [RFC1035] and
[RFC2142] either expose or cause the exposure of email addresses that
could be flooded by an attacker, for example. Records found in the
DNS such as MX, NS, and others advertise potential attack
destinations. Common DNS names, such as "www", plainly identify the
locations at which particular services can be found, providing
destinations for targeted denial-of-service or penetration attacks.
This all means that Domain Owners will need to harden these addresses
against various attacks, including but not limited to:
* high-volume denial-of-service attacks;
* deliberate construction of malformed reports intended to identify
or exploit parsing or processing vulnerabilities; and
* deliberate construction of reports containing false claims for the
Submitter or Reported-Domain fields, including the possibility of
false data from compromised but known Mail Receivers.
11.3. DNS Security
The DMARC mechanism and its underlying authentication mechanisms (SPF
and DKIM) depend on the security of the DNS. Examples of how hostile
parties can have an adverse impact on DNS traffic include:
* If they can snoop on DNS traffic, they can get an idea of who is
receiving mail using the domain(s) in question.
* If they can block outgoing or reply DNS messages, they can prevent
systems from discovering senders' DMARC policies.
* If they can send forged response packets, they can make aligned
mail appear unaligned or vice versa.
None of these threats are unique to DMARC, and they can be addressed
using a variety of techniques including, but not limited to, the
following:
* Signing DNS records with Domain Name System Security Extensions
(DNSSEC) [RFC9364], which enables recipients to validate the
integrity of DNS data and detect and discard forged responses.
* DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484] can mitigate
snooping and forged responses.
11.4. Display Name Attacks
An increasingly common attack in messaging abuse is the presentation
of false information in the display name portion of the RFC5322.From
header field. For example, it is possible for the email address in
that field to be an arbitrary address or domain name while containing
a well-known name (a person, brand, role, etc.) in the display name,
intending to fool the end user into believing that the name is used
legitimately.
Such attacks, known as display name attacks, are out of scope for
DMARC.
11.5. Denial of DMARC Processing Attacks
The declaration in Section 5.3.1 and elsewhere in this document that
messages that do not contain precisely one RFC5322.From domain are
outside the scope of this document exposes an attack vector that must
be taken into consideration.
Because such messages are outside the scope of this document, an
attacker can craft messages with multiple RFC5322.From domains,
including the spoofed domain, in an effort to bypass DMARC validation
and get the fraudulent message to be displayed by the victim's Mail
User Agent (MUA) with the spoofed domain successfully shown to the
victim. In those cases where such messages are not rejected due to
other reasons (for example, many such messages would violate the
requirement described in [RFC5322] that there be precisely one From:
header field), care must be taken by the Mail Receiver to recognize
such messages as the threats they might be and handle them
appropriately.
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. Experience has shown that most such
messages are abusive and/or unwanted by their recipients, and given
this fact, a Mail Receiver may make a negative disposition decision
for the message prior to and instead of its being subjected to DMARC
processing. However, in a case where a Mail Receiver requires that
the message be subject to DMARC validation, a recommended approach as
per [RFC7489] is to apply the DMARC mechanism to each domain found in
the RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail. Such an approach might
prove useful for a small number of Author Domains, but it is possible
that applying such logic to messages with a large number of domains
(where "large" is defined by each Mail Receiver) will expose the Mail
Receiver to a form of denial-of-service attack. Limiting the number
of Author Domains processed will avoid this risk. If not all Author
Domains are processed, then the DMARC evaluation is incomplete.
11.6. External Reporting Addresses
To avoid abuse by bad actors, reporting addresses generally have to
be inside the domains about which reports are requested. To
accommodate special cases, such as a need to get reports about
domains that cannot actually receive mail, Section 3 of [RFC9990]
describes a DNS-based mechanism for validating approved external
reporting.
The obvious consideration here is an increased DNS load against
domains that are claimed as external recipients. Negative caching
will mitigate this problem, but only to a limited extent, mostly
dependent on the default TTL in the domain's SOA record.
Where possible, external reporting is best achieved by having the
report be directed to domains that can receive mail and simply having
it automatically forwarded to the desired external destination.
Note that the addresses shown in the "ruf" tag receive more
information that might be considered private data since it is
possible for actual email content to appear in the failure reports.
The URIs identified there are thus more attractive targets for
intrusion attempts than those found in the "rua" tag. Moreover,
attacking the DNS of the subject domain to cause failure data to be
routed fraudulently to an attacker's systems may be an attractive
prospect. Deployment of DNSSEC [RFC9364] is advisable if this is a
concern.
11.7. Secure Protocols
This document encourages the use of secure transport mechanisms to
prevent the loss of private data to third parties that may be able to
monitor such transmissions. Unencrypted mechanisms SHOULD be
avoided.
In particular, a message that was originally encrypted or otherwise
secured might appear in a report that is not sent securely, which
could reveal private information.
11.8. Relaxed Alignment Considerations
The DMARC mechanism allows both DKIM- and SPF-Authenticated
Identifiers (Section 4.4) to validate authorized use of an Author
Domain (Section 3.2.2) on behalf of a Domain Owner (Section 3.2.7).
If malicious or unaware users can gain control of the SPF record or
DKIM selector records for a subdomain of the Organizational Domain,
the subdomain can be used to generate email that achieves a DMARC
pass on behalf of the Organizational Domain.
A scenario such as this could occur under the following conditions:
* A DMARC Policy Record exists for the domain "example.com", such
that "example.com" is an Organizational Domain.
* An attacker controls DNS for the domain "evil.example.com" and
publishes an SPF record for that domain.
* The attacker sends email with the RFC5322.From header field
containing "[email protected]" and an SPF-Authenticated Identifier
of "evil.example.com".
Although this email was not authorized by the Domain Owner, it can
produce a DMARC pass because the SPF-Authenticated Identifier
("evil.example.com") has Identifier Alignment with the Author Domain
("example.com").
The Organizational Domain Owner should be careful not to delegate
control of subdomains if this is an issue and consider using the
strict alignment (Section 3.2.10.2) option if appropriate.
DMARC evaluation for relaxed alignment is also highly sensitive to
errors in determining the Organizational Domain if the Author Domain
does not have a published DMARC Policy Record (Section 3.2.6). If an
incorrectly selected Organizational Domain is a parent of the correct
Organizational Domain, then relaxed alignment could potentially allow
a malicious sender to send mail that achieves a DMARC pass verdict.
This potential exists for both the legacy [RFC7489] and current
methods for determining the Organizational Domain; the latter is
described in Section 4.10.2.
The following example illustrates this possibility:
* Mail is sent with an Author Domain of "a.mail.example.com" and
Authenticated Identifiers of "mail.example.com".
* There is no DMARC Policy Record published at
"_dmarc.a.mail.example.com".
* There is one published at "_dmarc.mail.example.com" and this is
intended to be the Organizational Domain for this message.
* There is also a DMARC Policy Record published at
"_dmarc.example.com", with default alignment (relaxed).
* An attacker is able to send mail with the Author Domain of
"evil.example.com" and an Authenticated Identifier of
"mail.example.com".
In this scenario, if a Mail Receiver incorrectly determines the
Organizational Domain to be "example.com", then the attacker's mail
will pass DMARC validation checks.
This issue is entirely avoided by the use of strict alignment and
publishing explicit DMARC Policy Records for all Author Domains used
in an organization's email.
For cases where strict alignment is not appropriate, this issue can
be mitigated by the Domain Owner periodically checking (perhaps
weekly or whatever frequency might be appropriate for a given
organization's operational needs) the DMARC Policy Records, if any,
of PSDs (Section 3.2.15) above the Organizational Domain in the DNS
tree (and for legacy [RFC7489], checking that appropriate PSL entries
remain present). If a PSD publishes a DMARC Policy Record without
the appropriate "psd=y" tag, Organizational Domain owners can add
"psd=n" to their Organizational Domain's DMARC Policy Record so that
the PSD's DMARC Policy Record will not be incorrectly interpreted to
indicate that the PSD is the Organizational Domain.