On Thursday, April 11, 2019 03:33:34 PM Kurt Andersen wrote: > Firstly, just a nit, but section 4.1 introduces a new abbreviation in the > last bullet point: "PSDo". I suspect that this should be PSO for > consistency.
Agreed. Thinko on my part. Fixed for the next revision. > More substantively, in Appendix A, the case is being advanced for "concerns > associated with Multi-organization PSDs that do not mandate DMARC usage". > I'm not sure why "multi-organization" is an appropriate qualifier, nor as > to what mandated DMARC usage has to do with any of the privacy concerns. > Neglected DMARC usage is what leads to the spillage up to the PSD level. > Even within a single organization there may be serious privacy walls which > need to be respected between different sub-portions of the org - which may > or may not be represented in a DNS hierarchy. When you say "Neglected DMARC usage", it gives the impression that you think not participating in DMARC is somehow negligent. It's not. It's not even an IETF RFC of any kind. DMARC is opt-in. PSD DMARC is opt-in for PSOs, but not for lower level organizations. When an organization is involuntarily subject to having details of it's email activity mailed to an entity which it has not authorized to get it, that's the very definition of a privacy breach. For single entity PSDs, the decision to participate in PSD DMARC and receive feedback is approximately identical to the decision for non-PSO organizations to participate in DMARC with their organizational domains. Yes, their can be sensitivities within an organization, but they have a common management to determine how to address those issue. The Internet doesn't have to do it for them. For multi-entity PSDs, there is no common management among the organizational domains, so it is a different situation. Where DMARC is already required within a PSD, compliant organizations have already opted-out of PSD DMARC, so the privacy breach potential is, I argue, effectively mitigated. Where DMARC is not required (approximately everywhere today), that's not the case and I feel pretty strongly there's an issue we have to address. > I've read through the breakdown in section 4.1, but I think that it is > incomplete - largely on the terms mentioned above. Also, the claim that > reports on cousin domains would be sent to the [right] PSO ignores the risk > of the PSD itself being the cousin attack point. After all if a domain > doesn't exist, one may as well start from the top :-) OK. If this discussion helps you understand where I'm coming from, I'd appreciate suggestions on text to make it clearer in the document. > I think it would be more effective to add an anti-RUF requirement to the > implementation of this spec - such that no RUF reports would be sent, > regardless of the record which is published by the PSD. Since very few > providers even support RUF at all, this does not seem to be a big ask, > although it does require some additional logic. The privacy risk is > primarily related to RUF, not RUA reports so blocking RUF could (IMO) > effectively mitigate the perceived risk of the PSD records while still > allowing the DMARC validation protection. I think adding a MUST NOT regarding RUF is a good idea. I added this to the draft for the next revision in the section about RFC 7489 Section 7: [RFC7489] Section 7.3 Failure Reports MUST NOT be sent for PSD DMARC. I don't think eliminating RUF reports is nearly sufficient. While the content of the RUA reports is certainly much less sensitive than the content of the RUF reports, they are still privacy sensitive. As an exercise, I've reviewed my own domain's RUA reports and explored what conclusions I could draw from them. I concluded it was enough that they are still privacy sensitive, much more so for small domains than large ones since patterns of individual users will be more obvious. Consider, as a scenario, the ccTLD operator of an oppressive nation state reviewing RUA reports and then passing on information to the national police when they see indications someone in a domain has been communicating with human rights activists. The 'law' enforcement agency can then require details from the domain owner to determine who the individual in question is. Yes, there are other ways this could be done, but I don't think we should make things like this easier. This is well within the scope of attacks described by RFC 7258. It's a BCP to mitigate such attacks. I don't think leaving them unmitigated is acceptable. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
