On Sunday, June 12, 2022 10:22:18 PM EDT Douglas Foster wrote: > Why am I unwilling to move on? > > Because I want this document to succeed and actually reduce email-borne > attacks. > > Because stifling of discussion does not lead to consensus. It does, > however, drag out the process. For those who do not want this process to > succeed, accumulated delay may be almost as good as a win. > > Because I got on this "kick" after Michael Hammer asserted personal > knowledge of a successful attack based on sibling authentication. I did > not discard his input simply because he was not at liberty to name names. > > Because I reviewed the PSL, as you could have done, and gave you a list of > domains that were vulnerable to sibling authentication attacks based on > their current configuration. I think you intended to beg each of them to > implement a PSD policy. How is that effort going? > > Because I manage an actual mail stream, and a destructive malware attack > won't mean a client organization is damaged or destroyed, it will mean my > organization is damaged or destroyed. I have not forgotten that when > the group was asked for mailstream data, I think about usage of DKIM > sibling authentication, you said you had no access to a mailstream source. > > Because I don't know your agenda. I am here to voice the evaluator > perspective. What interest group do you represent? > > Because a good security policy does not defend against what has happened, > it defends against what could happen. > > Because a new idea like Tree Walk does not get adopted unless people > believe the pain of transition is less than the benefit, so it needs to be > "sold". Currently, the tree walk risk seems greater than the PSL risk, > and you don't know how to sell past that objection. Muzzling me will not > cause millions of system administrators to do something stupid simply > because you put it into print. > > Because I have learned that repeating the same points is necessary to be > heard in this group. > > That's why.
For clarity, I don't currently have access to the kind of large enterprise scale data sets that seemed relevant to the discussion. Most people don't. I think the above is almost entirely ad hominem that I think it inappropriate for an IETF mailing list, so I'll ignore most of it. I have not asked anyone to add the PSD tags to a record because it's only a draft. I've mentioned before I think we should ask for early assignment of the psd= tag so that known PSDs can update. I have been involved in some conversations and my impression is that people are surprised that having their domain in the PSL makes sub-domain policy not work for DMARC. I have looked at the list and really find very few that are even potentially problematic. For example, the first four DMARC records I got were for: _dmarc.qld.gov.au _dmarc.sa.gov.au _dmarc.vic.gov.au _dmarc.wa.gov.au I think it's unlikely that sibling authentication is a problem within Australian state governments. In the terminology of RFC 9091 Section 1.2 these are "Branded PSDs". My review of the list leads me to believe that virtually all of them are either Branded PSDs (which it doesn't matter on a practical basis if they have the psd= tag or not) or companies that do have customer specific sub-domains, but don't appear to offer email service for them. Here's one example: https://www.pythonanywhere.com/pricing/ I asked if you had examples for a reason: > > Let's have an example of a real domain, with a real DMARC record, that > > would be negatively impacted by being assessed using the DMARCbis design. > > I haven't found any I think are problematic, but if you have, I'm all > > ears? It's not a giant conspiracy so to keep you from being heard. We can't do protocol design based on vague handwaving. We need specifics. I don't know how to assess "tree walk risk seems greater than the PSL risk". Why? My impression is the opposite. Currently domain owners don't have a scalable way to put domains on the PSL that should be on the PSL for web reasons and also have DMARC work for sub-domains (as it is supposed to). RFC 9091 was a good start, but the tree walk is far superior since it doesn't require a dedicated operational registry. I think we need to get this nailed down and move on because new domains are being added to the PSL all the time and to the extent I've been able to check, they don't anticipate that will break DMARC for them. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
