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

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

On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker <[e-mail]> wrote:

> Review of:    DMARC (Domain-based Message Authentication, Reporting, and
>                Conformance) Extension For PSDs (Public Suffix Domains)
> I-D:          draft-ietf-dmarc-psd-06
> Reviewer:     D. Crocker
> Review Date:  12 August 2019
>



Dave,

Thanks for your feedback about draft-ietf-dmarc-psd on August 13.  Though
Working Group Last Call closed on July 17th, the chairs have taken careful
consideration of your feedback before allowing the document to proceed.

We take these as the main points of your comments (and please correct us if
we have missed any):


   1.

   The current design of DMARC observes a clear division of functions
   between itself and the PSL.  Specifically, as you point out, DMARC relies
   on a PSL existing and being available as input, but provides no guidance
   regarding selection of a PSL source nor of its content management policy.
   Also, the only operation available on the list is a test of membership
   (i.e., “is this domain on the list?”). Both of these tenets contribute to
   simplicity in DMARC’s current design.
   2.

   The PSD proposal attempts to resolve use cases that have appeared since
   the publication of RFC7489 by prescribing the conditions under which an
   additional check for a policy record at a new (related) location should be
   done.  This violates the tenets of (1) above.
   3.

   This additional lookup, in those cases where it is done, increases
   substantially the complexity of DMARC implementations, and that complexity
   comes with non-trivial cost.
   4.

   The use case(s) sustained by this change are not clearly substantial or
   beneficial enough to warrant enshrining this as a change to DMARC, even
   with only Experimental status.  There has also been very little indication
   of interest for implementation of the experiment.


On review (and our apologies for the duration of that review), we believe
the current draft does attempt to address your concerns, but does not make
this clear in its current form.  Given our responses to your points below,
and if you agree, perhaps you can help us to compose alternative text that
improves that situation.

For the first two points, we concur.  On the issue of the second violating
the tenets of the first, we suggest that the outcome of the experiment can
be used to drive an evolution of the PSL into a new form and perhaps new
update policies.  That is, rather than driving a change to DMARC itself,
the experiment’s results (if successful) can drive a change to the PSL, or
perhaps inform development of an alternative to it.

>From a higher level view, the experiment can be seen as the temporary
construction of an augmented PSL (i.e., the actual PSL coupled with the
queryable registry described in Appendix B), which DMARC then can consume
to resolve the use cases that have appeared which now need to be
addressed.  The portion of the experiment comprising an augmentation to
DMARC’s algorithm would therefore not be part of DMARC permanently. Then,
if the experiment proves effective, that would become prima facie evidence
that the PSL, augmented with this additional information, would enable
DMARC to resolve those use cases.  Such an augmented PSL would still
conform to the desirable separation of functions to which you alluded.

The working group originally discussed other alternative ways to augment or
even replace the PSL, such as creating a queryable IANA registry controlled
under our own terms.  The WG did not achieve consensus on such a proposal.
Should this experiment bear fruit, that discussion could (and should) be
revisited. Also, to be clear, any effort to augment the format, content, or
management of the PSL would require collaboration with the Mozilla
Foundation, as they are its de facto maintainers; absent such
collaboration, or if our proposal is not accepted, we must revisit the
notion of creating our own version of it and coming up with workable query
and update mechanisms and policies.

On the third point, we respectfully disagree.  An informal canvassing of
some members of the DNS community has been done and the consensus opinion
suggests that the additional operational overhead proposed here is
negligible.  This is, indeed, a far cry from the resistance with which the
original DKIM policy work was met, wherein even a one-level tree walk
upward drew heavy criticism. Code-wise, DNS queries are well understood
processes by now, and adding one more to the implementations of those
packages with active representation in the working group has not been seen
as costly enough to be a concern.  And it seems logical that conducting
this experiment will indeed help to confirm whether the additional query is
an apparent burden on either implementers or operators.

On the final point, we suggest that the WG considers this an intentional
part of the experiment’s design.  The set of use cases to which the
experiment applies is deliberately constrained, which of course will limit
the apparent effectiveness of the technique being proposed.  However, if it
is effective for the small number of domains that are part of the
experiment, and with a relatively limited set of implementers, this
constitutes evidence that a wider trial involving more prominent PSL
entries and larger operators would be warranted as part of the development
of DMARCbis.

In addition, there are a few very large players in the space who are
unfortunately reticent to declare publicly that they are interested in
seeing this evolutionary experiment proceed.  These include large email
providers and operators of sizable TLDs in need of the capabilities pursued
here. This provides some weight to the idea that this will not be simply a
niche experiment.

If none of the above are enough to assuage your concerns, we would
appreciate any suggestions you might have about an alternative experiment
that might be run to address the use cases both you and the draft have
described.

Lastly, we note that the idea of “walk up one node” came from an email
thread in December[1] wherein you suggested that approach, and which the
PSD draft now follows.  We are thus a little surprised by the assertion
that it should not proceed at all. Was there some content of that thread
that was not taken into account that would make it palatable?

-MSK, co-chair


[1] https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI