On Tue, Aug 13, 2019 at 7:02 PM Dave Crocker <dcroc...@gmail.com> 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
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc