Re: [dmarc-ietf] Additions to draft - Security Considerations

[Scott Kitterman <[e-mail]>]

On Sunday, April 24, 2022 9:16:04 PM EDT Douglas Foster wrote:
> 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.

I think you have a reasonable issue in here, but this is not all security 
considerations.  I also think the point that it's independent of how the 
organizational domain is determined is appropriate.

My assessment is that this is an issue that it is appropriate to document in 
this text:

> > 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.

I think it needs some work though and can be substantially shorter.  The same 
potential exists for both public and private registrations.

Org domain too low in the tree causing an incorrect rejection isn't a security 
issue though, that's a protocol problem.

How about something like this:

9.7 Determination of the Organizational Domain For Relaxed Alignment

DMARC evaluation for relaxed alignment is highly sensitive to errors in the 
determination of the organizational domain if the RFC5322.From domain does not 
have a published policy.  If an incorrectly selected organizational domain is 
a parent of the correct organizational domain, then relaxed alignment could 
potentially allow a malicious sender to obtain DMARC PASS.  This potential 
exists for both the legacy [RFC 7489] and current [Section 4.8] methods for 
determining the organizational domain.

This issue is completely avoided by use of strict alignment and publishing 
DMARC records for all domains/sub-domains used as RFC5322.From domain in an 
organization's email.

For cases where strict alignment is not appropriate, this issue can be 
mitigated by periodically checking the DMARC records, if any, of PSDs above 
the organization's domains in the DNS tree and (for legacy [RFC 7489] checking 
that appropriate PSL entries remain present).  If a PSD domain publishes a 
DMARC record without the appropriate psd=y tag, organizational domain owners 
can add psd=n to their organizational domain's DMARC record so that the PSD 
record will not be incorrectly evaluated to be the organizational domain.


I think that captures in a more compact form the issue you are (I think 
rightly) concerned about as well as appropriate advice to protocol users on 
how to avoid or mitigate the issue.

Scott K