On Sun, Mar 15, 2020 at 5:49 AM Dave Crocker <[email protected]> wrote:
> On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote: > > Since we're mentioning a tree walk here, I believe we are ripe for a > reopening of that debate. > > That's a shame. Besides created additional general cost, it creates an > attack vector. > > Consider: From [email protected] > Yeah, I'm familiar with the nature of the attack. But based on what amounts to the hallway track, it feels like the perspective of the DNS community these days is that the currently deployed DNS infrastructure could easily deal with such an attack, to at least the extent that it's not a blocker for something potentially useful like resolving the Organizational Domain problem for DMARC. Tim might be able to elucidate here. I believe where this is leading, though, is toward the notion that the use > of the PSL should be considered external to DMARC. I don't think anyone > has disagreed with that assertion. > > And yet both DMARC and PSD have text tied to the term and its function. > My point here is that I believe we've already agreed that you're correct, and this separation should happen, but there's no apparent urgency that MUST be done before the PSD experiment can proceed. Indeed, I'm fairly certain the amount of code change in my own implementation in order to be compliant with such a change in the specification is around zero. The audience for the experiment, by my read, also agrees, so they understand the need, but this won't change the experiment either. > > > 2. Externalizing internal difficulties >> > >> > Some organizations have sub-groups to which various administrative >> > responsibilities have been delegated. In general, there can be many >> > levels of such delegation. Not just two. >> > >> > For the cases the PSD specification is intended to cover, >> > PSD seeks to adapt to slow DMARC adoption or non-existent domains for >> > one of its delegated sub-groups, by looking for an even-higher-level >> > encompassing record under a next-level Organizational Domain. That is, >> > PSD is specifying using two different Organizational Domains. The usual >> > one and its parent. >> > >> > A difficulty within the organization is being externalized to a burden >> > for everyone else on the net. >> > > Can you expand on how you see abuse of non-existent domains to be an > exploitation of an internal problem? Specifically, what's the internal > problem being exploited? > > I apologize for not being more clear about what I meant. I hope that the > above effort elaborate on this suffices. Basically it concerns an > organization's inability to get its subordinates to publish DMARC records > and problems with PSLs that lead to identifying the wrong domain as an OD. > Or somesuch... > The issue PSD is attempting to address is mail sent as a nonexistent subdomain. For example, irs.gov doesn't have a subdomain called auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send email as [email protected] without limitation. The goal here is to come up with a mechanism to prevent this. Obviously the maintainers of irs.gov can't anticipate all possible nonexistent names that might be used, so either something like PSD is needed, or some kind of wildcarding mechanism is needed by which the domain owner can block any name they're not actually using. What such mechanism could be developed? Don't wildcard TXT records, for example, have some other side effects? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
