Re: [dmarc-ietf] what to document about the tree walk

[Douglas Foster <[e-mail]>]

1) I believe that replacing the PSL is a good thing, if it is done with
markers present.   The domain owner is the best source of information about
the organization boundaries.   We MUST provide him with a way to
communicate that knowledge in DNS, and a compliant implementation MUST find
and use that information when it is present.

2) I believe that the document needs a vigorous explanation of why the PSL
needs to be replaced.   I made a stab at the effort in the text that I sent
Sunday night.   Murray's text here is more comprehensive.   But we need
something.  We are asking evaluators to undertake a change which requires
effort and any change creates multiple risks.

3) The critical question is whether we can treat the PSL as replaced
without obtaining the markers first.   On this issue, John and I have a
different assessment of the risk.   I can accept a solution which lays out
the assumptions and risks to the evaluator, and lets them decide what to
do.  This is what sections 4.7. and 4.8 in my text from Sunday night
attempted to do.

Doug

On Wed, Jul 13, 2022 at 1:12 AM Murray S. Kucherawy <[e-mail]>
wrote:

> Hatless once again.
>
> On Tue, Jul 12, 2022 at 3:08 PM Douglas Foster <
> [e-mail]> wrote:
>
>> The tree walk solves the problem IF the policy has boundary information
>> provided by the domain owner.   Without that, aren't we substituting one
>> insufficiently  reliable solution for another insufficiently reliable one?
>>
>
> Another way to look at it: The PSL was never designed to provide the
> information for which DMARC has been using it.  Hanging DMARC on it was a
> reasonable thing for a proof of concept, which is what RFC 7489 really was;
> it happens to give the right answer most of the time, but that's something
> of a coincidence.  Here we're taking control over the input to the
> Organizational Domain and Policy Discovery algorithms, which is a more
> defensible way to do things if you're heading for the Standards Track.
>
> The tree walk also eliminates any concern that two compliant operators are
> using different versions of the input data.  There is no guarantee that my
> copy of the PSL is any more or less up to date than yours is, leading us
> both to different determinations about the very same message.  But once
> we're using the DNS for this, then, other than staleness caused by
> short-term caching, we're all talking about the same thing.
>
> There is indeed more of a burden on sending domains and registry operators
> to publish the needed markers in the DNS before this will all work the way
> we want it to.  My view is that the working group perceives the risk of
> continued use of the PSL to be less favorable than taking on that burden.
> The tree walk has been a goal for years.
>
> Changes to nodes in the DNS tree are visible immediately; changes to the
> PSL take an unknown amount of time to be published and deployed globally.
>
> Changes to the DNS are made by the operator in charge of the name(s) being
> updated; as far as I'm aware, changes to the PSL are made by a limited
> community not involved in (or perhaps even interested in, or cognizant of)
> DMARC.
>
> If we want a migration period, some kind of hybrid model might work: Do
> the DNS tree walk, but at each step, if you find you've hit a name that's
> present in the PSL, you can stop and pretend you found a marker you're
> looking for.  When those markers are all (or mostly) actually published,
> then stop doing that.  For bonus points, find some non-DoS way to notify
> those operators that they really should be publishing the missing markers.
> (The 1990s DNS "lame delegation" stuff comes to mind.)  We just need to
> remember that SPF had a not-so-great transition plan, so we need to be
> careful how we craft this one.
>
> -MSK
>