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

From: Kurt Andersen <[email-masked]>
Date: Thu, 11 Apr 2019 15:33:34 -0700

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.

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.

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 :-)

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.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 11 Apr 2019 22:57:34 -0400

> last bullet point: "PSDo". I suspect that this should be PSO for

Agreed.  Thinko on my part.  Fixed for the next revision.

> 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.

> 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.

> 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

---

From: Seth Blank <[email-masked]>
Date: Fri, 12 Apr 2019 09:00:33 +0200

On Fri, Apr 12, 2019 at 4:57 AM Scott Kitterman <[email-masked]>
wrote:

> I think adding a MUST NOT regarding RUF is a good idea.
>

I think this is a bad idea for two very important reasons:

1) Any gTLD being used as a brand domain (i.e. .google, .microsoft, etc.)
may wish to use failure reports on these domains just as they would on
their .com's.

2) We wanted this spec to be the *minimum* delta from DMARC possible.
That's why we added the third lookup but removed all other items. A MUST
NOT for RUF no longer feels like a minimum delta. It also adds extra
overhead to any implementation changes needed to test the experiment.

We should (and I believe do) make the case in privacy consideration that
failure reports for a third lookup is a bad idea. I don't think we need
more of this right now. If during the experiment it becomes clear that this
guidance is needed, then it can be folded into DMARC 2.0 when everything
comes together.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2019 07:38:35 -0400

> guidance is needed, then it can be folded into DMARC 2.0 when everything

I think your first point is a reasonable one.  For the second one, I think 
minimum may be in the eye of the beholder.  From an implementation 
perspective, I think the difference is trivial (if X then don't do Y) and I 
think part of minimum is a design that makes sense from a privacy perspective.

As a practical matter, since so few entities send RUF reports, it's not a 
major issue either way.  Let's see what others think.  I'm glad to take it 
back out if that's the way the group leans.

Scott K

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 12 Apr 2019 08:23:01 -0700

On Thu, Apr 11, 2019 at 7:57 PM Scott Kitterman <[email-masked]>
wrote:

> not participating in DMARC is somehow negligent.  It's not.
>

I'm using that term in the context of what you are deeming "mandated
usage". Hence, not doing it is neglecting that mandate.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2019 12:13:54 -0400

> usage". Hence, not doing it is neglecting that mandate.

OK.  I didn't get that.

Agreed that for an organizational domain in a PSD that mandates DMARC, not 
having an organizational DMARC record is neglectful.  In that context, I think 
it's perfectly reasonably to say that if you don't follow the rules, you get 
the consequences (in our case the PSO gets your reports).

Somewhat similarly, for a .bigcompany PSD, it's really an internal matter if 
they want reports to the PSO or various subdomains.

So there are two criteria for is there a privacy risk in my view:

1.  Is DMARC a requirement for organizations within the PSD?
2.  Are multiple organizations represented with the PSD?

Hopefully this ASCII art truth table will come out OK (leading '/' represent 
negation (i.e. not required and not OK):

      |One  | Multi |
      |org  |  org  |  
------+-----+-------+
DMARC |     |       |
Req   | OK  |  OK   |
      |     |       |
------+-----+-------+
DMARC |     |       |
/Req  | OK  | /OK   |
      |     |       |
------+-----+-------+

In the lower right corner of the table where I see the problem, there's no 
mandated DMARC usage, so the opt-in/opt-out problem exists.  I hope that makes 
it clearer why I used multi-organizational as a qualifier.

Scott K