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

[Douglas Foster <[e-mail]>]

Unfortunately, the PSL is not an adequate tool for validating the Tree Walk
algorithm.   You disparaged that idea when I proposed it earlier, and you
were right.

The expected PSL error is domain fragmentation, because
Cross-Site-Scripting scope boundaries are likely to be narrower than email
domain boundaries.   The expected Tree Walk error is domain consolidation,
because missing information will cause the walk to continue upward.  When
the two algorithm results are compared, we know nothing about which
algorithm is mistaken.  (Maybe both algorithms are incurring their
respective error types are occurring at the same time!)

We have a fundamental weakness when a trust-verification algorithm like
DMARC is highly dependent on unverifiable data about organizational
boundaries.   The PSL algorithm has this problem, which is why we are
considering a replacement, but at least its mistakes are not considered
malicious.   Additionally, a domain owner can manage the consequences of
domain fragmentation by adding more DMARC policies and adjusting DKIM
signature domains.   For the Tree Walk Algorithm, mistakes are likely to be
malicious, and the malicious domain owner has no incentive to fix the
problem.   Observing that malicious use will only be possible on a few
domains is not the same as solving the problem.

I have proposed a solution to this problem, which replaces the awkward and
"intentionally confusing" psd=n token with the more useful
OrgsBelow=<integer> token.   The OrgsBelow token both indicates an
organizational domain and defines the subtree to which it applies.
 Consequently, if fixes the known vulnerability in the Tree Walk
algorithm.  The real question is why there is resistance to solving the
problem correctly.



On Sun, May 1, 2022 at 7:59 PM Scott Kitterman <[e-mail]> wrote:

>
>
> On May 1, 2022 11:25:02 PM UTC, Neil Anuskiewicz <neil=
> [e-mail]> wrote:
> >  On Apr 24, 2022, at 8:57 PM, Scott Kitterman <[e-mail]>
> wrote:
> >>
> >> 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.
> >
> >Though the risk’s low, “periodically checking the DMARC records, if any”
> >isn’t particularly reassuring. It’s like saying periodically give your
> >pilot a breathalyzer. :-)
>
> I agree, although in this case it can be automated.  Similarly,
> periodically checking the PSL under the current scheme would be a good idea
> and not hard to do.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>