On September 5, 2019 8:28:05 AM UTC, Alessandro Vesely <ves...@tana.it> wrote: >On Thu 05/Sep/2019 07:15:35 +0200 Scott Kitterman wrote: >> On Wednesday, September 4, 2019 9:28:41 AM EDT Dave Crocker wrote: >>> On 9/3/2019 8:57 AM, Murray S. Kucherawy wrote: >>>> >>>> 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. >>> >>> With respect to the use of this work as a model for changes to the >PSL, >>> unfortunately the spec is not written in a fashion to support that. >>> This really is a core concern, in my view: the work needs to have a >>> basic model that really is expected to be appropriate for the long >term; >>> hence my suggestion to highly limit any changes to DMARC and, >instead, >>> cast the bulk of the work as augmenting the PSL. >>> >>> That said, and as for getting changes to the PSL, based on my >>> interactions with that community, I think it unlikely. There does >not >>> seem to be the interest or resources for such work. Strategically, >>> that's the biggest hurdle to overcome, IMO. >>> >>> .. >>> >>> Hence my current view that: >>> >>> 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. >> >> I think some related, but distinct issues are conflated in your >analysis. >> >> The core PSD check doesn't need a PSL change. The current PSL works >fine. The >> sequence is: >> >> 1. Check at the From domain level. >> 2. If no record, check at the org level. >> 3. [New] if no record check one level above the org level (PSD). >> >> That's all doable with the current PSL. I don't think we want to >force >> additional lookups between 1 and 2 for lower level domains. >Currently for >> something like: >> >> a.b.c.d.org.example where only example is in the PSL the queries >would be: >> >> 1. a.b.c.d.org.example >> 2. org.example >> 3. example >> >> As I read your proposal we've have to add in queries for: >> >> b.c.d.org.example >> c.d.org.example >> d.org.example >> >> I don't think querying anywhere in the DNS treee is an improvement >for >> scalability of DMARC. > > >Besides scalability, the question is whether b, c, or d have the right >to >override the DMARC policy of org.example. The current spec clearly >says no. > >My reading of Dave's proposal differs. Modifying the PSL has the >implicit >objective to skip step 2. That is, to limit queries to: > >1. a.b.c.d.org.example >3. example > >Thereby slashing org.example's privilege to establish its own domain >policy. > > >> Adding the single additional PSD lookup works fine with the existing >PSL. >> There are two reasons to go beyond this: >> >> 1. Since most PSDs won't publish DMARC records, as an efficiency, >let's not do >> that third lookup unless we have to. >> >> 2. PSD DMARC without some constraints on the additional lookup >automatically >> opts in all organizational domains that do not publish DMARC records, >which >> has privacy implications. This is discussed in Section 4.1 of the >draft. > > >We should also consider updates: > >How often is/should be the PSL updated at average mail servers? > >How often would then the extra list at psddmarc.org have to be updated? > > >> As it says at the start of Appendix B, the options proposed there are >to >> mitigate the privacy risks described in Section 4.1. The related >requirements >> discussion is in Appendix A, Section A.1. >> >> It is a beneficial side effect that they also reduce the need for DNS >lookups >> and thus provide an efficiency enhancement. >> >> If we didn't care about privacy, this would be easy. That's the hard >part >> that does not have a clear solution. One thing that is clear is that >it's not >> the PSL. PSL is a collector of assertions from operators, so it >fails to meet >> the attributes laid out in A.1. > > >Failure reports are considerably less implemented than aggregate ones. >The >current spec doesn't mention any privacy risk in its Security >Considerations >section. However, some concern must exist, otherwise the difference in >implementations cannot be easily explained. The I-D at hand touches on >this >point marginally. A general consideration would better fit in >DMARCbis.
That's because there's an entire separate section on privacy considerations. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
