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

[Tim Wicinski <[e-mail]>]

Scott

PSD DMARC does talk about organizational domains which from the original
DMARC spec (section 3.2)
does say 'Acquire a "public suffix" list'

The addition of the preamble text shouldn't move the document in either
direction.
I do feel anything which helps focus us on moving forward on DMARC-bis is a
good thing.
The WG should be able to start writing the PSL document right away.

Murray and I will be in Singapore if anyone wishes to speak their mind.

thanks
Tim




On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman <[e-mail]>
wrote:

>
>
> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" <
> [e-mail]> wrote:
> >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.
>
> The current revision of the PSD DMARC draft makes no reference to the PSL
> in the body of the draft (it only comes up in Appendix A and C).    It
> seems like an odd choice to continue to insist PSD DMARC is specifically
> tied to the PSL when the text indicating so has been removed (Dave's email
> was two months ago and things have changed in the interim).
>
> I don't think the proposed note says anything the status of experimental
> shouldn't already communicate.  Given the current state of the draft, I
> don't think it's necessary to have such a note.
>
> Scott K
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>