Re: [dmarc-ietf] Next draft concerns

Les' question has returned us to the problem of justifying the tree walk.
 We need to document the problems with PSL, but we also need to demonstrate
that the tree walk solves those problems without creating others.

In most cases, the tree walk and PSL will produce the same results, because
they will both find the top-most DMARC policy in a structure with neither a
private registrar nor a PSD policy.   So the justification is really
limited to those exceptions.

We assume that most PSL errors will cause organization fragmentation,
because of identifying a private registry for XSS purposes which is not a
private registry for email purposes.    We also know that the current DNS
has no information about private registries, so if we apply the tree walk
to the current DNS, we may sometimes error by landing too high and causing
inappropriate organization consolidations.

In the case that the tree walk stops lower than the PSL target, the most
secure solution is to believe the DNS policy.   This can only occur if the
policy has a DMARCbis token which explicitly says that a policy has the
Organizational Domain role.

In the case that the tree walk stops higher than the PSL target, which do
we believe?    To tilt the decision in favor of the tree walk, we need a
token which indicates that the tree walk did not pass over an undocumented
private registry.   This will also require a new token on the
organizational domain, which is not yet defined.   I see these possible
informational signals:
- No private registries or organizational boundaries underneath this
organizational domain.
- All sub-organizations underneath this organizational domain are also
documented with organizational domain DMARC policies.
- A private registry exists underneath this organizational domain and is
documented with a PSD policy.

This means that for either exception, a new DMARCbis token is required on
the organizational domain.   Consequently, a domain which has not published
an applicable DMARCbis token should be evaluated using the PSL, and a
domain which has published a sufficient set of DMARCbis tokens should be
evaluated using the Tree Walk.   This approach also satisfies our other
requirement, which is that the tree walk requires an organizational domain
policy.

I know this is discouraging, because John's original hope was to avoid
placing a change requirement on domain owners, but I do not see that it can
be helped.

Doug Foster

On Thu, Jun 9, 2022 at 3:18 PM Les Barstow <lbarstow=
40proofpoint.com@dmarc.ietf.org> wrote:

> Thank you for the history fill-in, John. That does at least explain why
> we’re here and not somewhere else.
>
>
>
> I will respectfully disagree that the “psd” tree walk standard is
> well-defined based on the remainder of my response – that the use of the
> “psd” TLA for the tag is unfortunate/misleading and that more specificity
> is desirable. But having the alternatives eliminated at least gets me to
> “it should be in this spec”.
>
>
>
> On Thursday, June 9, 2022, John Levine wrote:
>
>
>
> It appears that Les Barstow  <lbarstow@proofpoint.com> said:
>
> >-=-=-=-=-=-
>
> >[Strong opinion follows]
>
> >
>
> >IMO [from April], determination of a DMARC authority boundary (registrar, PSD+1, private registry (+1), or internal subdomain
>
> >boundary) should really be done outside of the DMARC standard altogether – a separate DNS lookup not dependent or centered
>
> >around DMARC, and one flexible enough to respond with indications of various levels of authority. It is useful for
>
> >decentralizing other queries beyond just DMARC (e.g. determining an appropriate WHOIS TLD for lookup). Unfortunately, here we
>
> >are at draft 8 of the new DMARC standard and we have nothing to use as a sidecar mechanism.
>
>
>
> The DBOUND working group already tried and failed to come up with a
>
> general way to publish DNS boundaries, so we're not going back there.
>
>
>
> >Is there a driving need to have this in the standard NOW?
>
>
>
> Yes, of course. The point of writing a standard is to tell people what
>
> to do to interoperate. The current underspecified fudge which winks at
>
> the PSL has well known issues since, among other things, the people
>
> who run the PSL have made it quite clear that it's not designed to
>
> make DMARC work. It contains plenty of entries which make sense for
>
> web cookies but not for DMARC.
>
>
>
> The tree walk is well specified and doesn't depend on third parties
>
> who aren't interested in what we want or need.
>
>
>
> R's,
>
> John
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>