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

[Douglas Foster <[e-mail]>]

I am pretty content with your text.

I am still see a security vulnerability without something like
the OrgsBelow token.  DMARC is all about verified data.   Since the tree
walk can be compromised by omitting psd=n, the selected organization domain
needs a verification method.   I don't understand why you think it is
already handled by the existing text.


On Sun, Apr 24, 2022 at 11:57 PM Scott Kitterman <[e-mail]>
wrote:

> 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
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>