Re: [dmarc-ietf] Feedback on draft-ietf-dmarc-psd-02

[Scott Kitterman <[e-mail]>]

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