[dmarc-ietf] Additions to draft - Security Considerations

[Douglas Foster <[e-mail]>]

I have attempted to capture the security-related content of recent
discussions:

Security Considerations

Determination of the Organizational Domain

DMARC evaluation is highly sensitive to errors in the determination of the
organizational domain, as the organizational domain is used for the default
policy (when the RFC5322.From domain does not have a published policy) and
for determining relaxed alignment.

If an incorrectly selected organizational domain is actually a parent of
the correct organizational domain, then relaxed alignment will allow a
malicious sender to obtain DMARC PASS while impersonating either the parent
domain or sibling domains.

If an incorrectly selected organizational domain is actually a child of the
correct organizational domain, then relaxed alignment will produce an
incorrect DMARC FAIL when the message is actually authorized by either the
correct organizational domain or siblings of the incorrectly chosen domain.

When the RFC5322.From domain does not have a policy record, the
organizational domain policy is needed to demonstrate DMARC participation
and to provide the default policy.   In this case, when an incorrect
organizational domain is selected, and it does not contain a DMARC record,
then the domain will be treated as not participating in DMARC and the
domain owner will not receive reports.   If the incorrectly selected domain
does have a DMARC policy, the applied policy may be different from the
domain owner’s intended policy, and reporting will go to whatever
destination is specified by that policy.

A DNS path may contain a private registration, where a PSO-registered
domain owner makes subtrees of his domain available to independent
organizations.   This behavior complicates DMARC organizational
determination.    Clients of the private registration will have two
organizational domains in its DNS tree, one at the boundary between the
private registration client and its private registrar, and another between
the private registrar and its PSO.  If a private registry is unknown or
undetected during organizational domain selection, then the registrar
organizational domain may be incorrectly selected as the client’s
organizational domain, allowing the client to obtain DMARC PASS while
impersonating the parent domain or sibling domains.

Reliance on an externally-authored public suffix list, as specified in
RFC7489, creates stability problems for domain owners and evaluators.    An
organization may have their DMARC configuration fully deployed and
successfully tested, then suddenly develop unexplained and difficult to
detect problems if the PSL used by evaluators adds an entry which fragments
the domain’s intended organizational boundaries for email.  Even if the
domain owner manages to detect the problem, getting it corrected may be
difficult or impossible.   Since every evaluator operates on an independent
copy of one or another PSL list, updated at intervals determined by the
evaluator, the domain owner has no certainty about when or if a correction
will be replicated to all evaluators.

Domain owners can minimize the need for determination of an organizational
domain by publishing a DMARC record for each RFC5322.From domain, and
applying a DKIM signature which provides strict alignment.  When this
practice is followed, the organizational domain is only referenced when a
non-mail subdomain is impersonated by a malicious actor.   This
configuration allows the SP clause on all policies to be confidently set to
REJECT.