Re: [dmarc-ietf] Comment on draft-ietf-dmarc-psd

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <[e-mail]> wrote:

> > 1. The change to DMARC should be limited to permitting the query for the
> > organization domain to be anywhere in the DNS tree, including a TLD.
> > Within DMARC this would not look like 'extra' mechanism.
> >
> > 2. The mechanism that processes that query should be cast strictly as a
> > PSL enhancement, independent of DMARC.
>
>
> Trying to refine things further:
>
>
>     DMARC does not care about the PSL.
>
>     What DMARC cares about is the Organizational Domain (OD), as a
> fallback when no DMARC record is found at the desired domain name.
>
>     That is, PSL is literally outside the scope of DMARC.
>
>     At the least, therefore, the DMARC specification should define a
> distinct interface to the outside functionality that tells DMARC where
> the OD is, which will return what suffix of the full domain name is the
> OD --  eg, getOrgDomain(full-domain) -> org-domain-suffix
>
>     The PSL-related side of that interface should be a separate
> specification, so that changes to its behavior -- such as has been
> happening with the introduction of ODs that are TLDs or are otherwise
> 'above' where DMARC has been guessing the OD to be -- are isolated from
> DMARC.
>
>     The current problems are that DMARC has embedded too much detail
> about the PSL world, yet DMARC has no involvement in that world. The
> current proposal embeds assumptions of PSL knowledge further, rather
> than separating PSL knowledge out.
>

We (the chairs) fully agree with all of this.  What we -- I in particular
-- have been struggling with is to find a path forward so the PSD
experiment can still take place without being blocked by the need to first
go back and overhaul RFC 7489 as you've described here, separating DMARC
and the OD determination.  Because that'll take months.

We are perhaps in the fortuitous position in our charter now that our very
next work item is to take up the task of reopening DMARC itself, and the
separation of function Dave is espousing could be made into a reality
during that work.  Given this, we suggest that the PSD draft be allowed to
proceed as Experimental, but with appropriate preamble text added to its
Introduction explaining the deficiency Dave has identified.  So the order
of operations becomes:

* add text to the PSD draft making it clear that what it's describing is an
experiment whose outcome will be taken only as feedback to the revision of
the standard (i.e., this is not intended to be the final form of anything),
and it is not intended to be deployed outside of the experiment's
participants;
* publish the experiment with those cautions and allow the experiment to
begin
* while the experiment is running, spin up the work on two new standards
track documents, in line with our charter:
  a) DMARC, with PSL references replaced by the abstract notion of the OD
that's determined in some non-specific way, as Dave suggests
  b) a PSL document that satisfies the abstract notion of OD in the DMARC
document, also as Dave suggests
* when the experiment completes, either augment (b) if it's still in
development, or publish a revision to it, based on what the experiment has
revealed

Can this be made to work?

Honestly, the experiment could start anyway without an RFC published, but a
formal record of the experiment and its caveats doesn't strike me as a
wrong thing to do.

-MSK