Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-03.txt

From: [email-masked]
Date: Tue, 07 May 2019 19:10:51 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
        Author          : Scott Kitterman
	Filename        : draft-ietf-dmarc-psd-03.txt
	Pages           : 11
	Date            : 2019-05-07

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  DMARC policies can be
   applied at the individual domain level or for a set of domains at the
   organizational level.  The design of DMARC precludes grouping
   policies for a set of domains above the organizational level, such as
   TLDs (Top Level Domains).  These types of domains (which are not all
   at the top level of the DNS tree) can be collectively referred to as
   Public Suffix Domains (PSDs).  For the subset of PSDs that require
   DMARC usage, this memo describes an extension to DMARC to enable
   DMARC functionality for such domains.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-03
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 07 May 2019 22:16:03 -0400

On Tuesday, May 7, 2019 10:10:51 PM EDT [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance WG of the IETF.
> 
>         Title           : DMARC (Domain-based Message Authentication,
> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
> Author          : Scott Kitterman

Significant changes from -02:

Based on offline feedback:

Added a paragraph on PSD exact domain match issues.
Added a clear MUST NOT for [RFC7489] Section 7.3 Failure Reports

Finished Appendices:

Added more text to Appendix B about support for the experiment available from 
psddmarc.org.
Added Appendix C to track implementations.

If anyone else has an implementation that's not listed, please let me know and 
I'll add it.

Other than that, I think it's about done.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 7 May 2019 19:30:25 -0700

Thanks, Scott!

To me (as an individual) this seems ready for last call.

A few items:

1. In the new paragraph in section 1 clarifying requirements, you have an
open parens that is never closed.

2. In Section 3.5, I'm concerned with the normative MUST NOT. This would
mean .example couldn't receive failure reports the way example.com does.
For something like .bank or .com, this is a feature. But for a .google,
this is a bug. I really think this MUST NOT is, while well advised, delving
into policy and not interop.

I really think the guidance in 4.1 is the best way to approach this.

Speaking of which, with the normative MUST NOT that's been added, now 4.1
no longer makes any sense.

My recommendation would be to roll this change back, and perhaps replace it
with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless
you really really know what you're doing."

3. psddmarc.org - I think we need a brief paragraph outlining the
experiment, and in it need to explicitly call out that a permanent solution
needs to be determined for answering the "what's a PSD" question - which
may or may not be psddmarc.org.

Thanks again!

Seth

On Tue, May 7, 2019 at 7:16 PM Scott Kitterman <[email-masked]> wrote:

> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 May 2019 12:39:13 -0400

> open parens that is never closed.

Fixed locally for the next revision.

> into policy and not interop.

In theory, I agree, but in practice, I think the new MUST NOT is a great 
change to promote implementation simplicity.  Recall that the failure reports 
we are discussing are not commonly sent even for regular DMARC due to privacy 
concerns, so there's almost no loss of feedback as a practical matter defining 
it this way.

Consider what implementers would have to do in the alternative.  In order to 
treat failure reports differently for single and multi-organizational PSDs, one 
would need to know which is which.  While some, like .google are relatively 
obvious, other are much less so.  It is much better to give clear guidance 
than to be handwavy.

> no longer makes any sense.

Only if you assume that there are no privacy risks associated with aggregate 
reports, which I don't believe is accurate.  I certainly wrote 4.1 on the 
assumption that it was mostly about aggregate reports, since failure reports 
are not commonly sent.

> you really really know what you're doing."

I disagree.  That puts the (potential) fox in charge of the hen house.

> may or may not be psddmarc.org.

I thought I'd done that in Appendix A.  Please review and provide specific 
recommendations as I don't really know how to address this general comment.

Other than the typo, I'm going to leave my local copy as is while we wait and 
see what others think.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Thu, 9 May 2019 10:35:28 -0700

On Thu, May 9, 2019 at 9:39 AM Scott Kitterman <[email-masked]> wrote:

> change to promote implementation simplicity.

This increases complexity. With this normative requirement, we're adding a
third lookup that behaves differently than the previous two. This
complicates the experiment and solidifies a (good) policy consideration
normatively.

> assumption that it was mostly about aggregate reports, since failure

The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD.

> recommendations as I don't really know how to address this general comment.

You're absolutely right, you did.

I do, however, think there's more to the PSD experiment than just deciding
where a PSD list should live - the crucial bit is if this actually
addresses and demonstrates value (i.e. stops spoofed email) for the use
cases discussed in Section 1.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 May 2019 18:03:14 -0400

> complicates the experiment and solidifies a (good) policy consideration

Either way there's a consideration.

If there's no MUST NOT, then any entity that does failure reporting needs to 
consider if they should do it for PSDs and if so, which ones.  That's a 
question that, at best, has a squishy answer.

If the MUST NOT is present, it's a straightforward processing change to not 
apply failure reporting if you got the result from a PSD lookup.

Either way, entities that don't do failure reporting now, won't be affected 
(which is almost everyone).

The changes to add PSD DMARC to an existing DMARC implementation are not 
complex, but they are required.  A clean implementation requirement while 
you're updating related code it, IMO, much easier to deal with than vague 
policy guidance.

> The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD.

I agree a small change is needed.  If we leave it the way it is (with the MUST 
NOT), then it would be appropriate to add that the MUST NOT requirement fully 
mitigates the privacy concern as it relates to RUF.

> cases discussed in Section 1.

I don't think so.  We know technically that it can do so.  There is no 
technical question in that regard, so nothing to experiment over.  Will people 
use it isn't really the proper basis for an IETF experiment.  The IETF 
publishes non-experimental RFCs all the time without any particular data to 
suggest the RFC will get implemented and deployed.

I think how to get the privacy issue mitigation correct is the only technical 
issue that needs experimentation, but I may have missed something.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Thu, 9 May 2019 16:16:58 -0700

> question that, at best, has a squishy answer.

I don't agree. It's up to the PSO, not the system generating reports, to
determine which type of reports are wanted. The proposed registry is the
control of who can even make a decision like this. If there were no
registry and PSD functionality were open to all, then this would be a more
concerning case.

But the entire point of DMARC is that a receiving system doesn't need to
guess - it's up to the domain owner to publish their policy. This flips
that distinction on its head and says it's no longer up to the domain owner.

To reiterate:

This normative MUST NOT is a mistake from many different angles, as it:
1) codifies a policy decision that doesn't affect interoperability
2) adds complexity because reporting against the third lookup is now
different than reporting for the other lookups
3) doesn't apply for all use cases (specifically, it would prevent .com
from gathering RUF data, but also prevents .google from operating in the
same manner as google.com)
4) reverses a key value of DMARC: giving control of policy to domain owners

I strongly agree that RUF is potentially problematic here, and it would be
better off if no one got it, but I really believe that's a policy decision
for a domain owner / PSO (and a policy decision for who is allowed in a
registry of PSOs), not something that should be normative in the spec.

Seth

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 15 May 2019 12:17:24 +0200

On Fri 10/May/2019 01:16:58 +0200 Seth Blank wrote:
> 2) adds complexity because reporting against the third lookup is now different
> than reporting for the other lookups
> 3) doesn't apply for all use cases (specifically, it would prevent .com from
> gathering RUF data, but also prevents .google from operating in the same manner
> as google.com <http://google.com>)
> better off if no one got it, but I really believe that's a policy decision for
> a domain owner / PSO (and a policy decision for who is allowed in a registry of
> PSOs), not something that should be normative in the spec.

In part I agree.  However, RUF is potentially problematic in general.  Whether
and how to honor RUF requests deserves a better discussion in the DMARC
specification.  I certainly wouldn't send a non-redacted failure report to an
unknown domain.

That said, I agree that control of PSDs should be given to PSOs, by the same
logic of bullet (4) above.

> I disagree.  That puts the (potential) fox in charge of the hen house.

It is true that we cannot trust the generic domain owner.  However, PSOs are
somewhat more constrained by policies and contracts.  In addition, their public
DNS records are quite easy to check.  Perhaps we could concede a little bit of
trust to those foxes?

In addition to Seth's "if you're a PSD, don't ask for RUF", I'd propose that
multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage SHOULD
publish a blank DMARC record, that is policy=none, no ruf, no rua.  PSOs that
violate those recommendations would not do so in a concealed or unanticipated
way, but as an integral part of their legalities.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 15 May 2019 07:22:59 -0400

On Wednesday, May 15, 2019 6:17:24 AM EDT Alessandro Vesely wrote:
> > same manner as google.com <http://google.com>)
> In part I agree.  However, RUF is potentially problematic in general. 
> Whether and how to honor RUF requests deserves a better discussion in the
> DMARC specification.  I certainly wouldn't send a non-redacted failure
> report to an unknown domain.
> 
> somewhat more constrained by policies and contracts.  In addition, their
> public DNS records are quite easy to check.  Perhaps we could concede a
> little bit of trust to those foxes?
> 
> multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage
> SHOULD publish a blank DMARC record, that is policy=none, no ruf, no rua. 
> PSOs that violate those recommendations would not do so in a concealed or
> unanticipated way, but as an integral part of their legalities.

There are multiple types of entities running PSDs under multiple sets of 
rules.  I don't think it's nearly that simple.  Transparency only helps 
moderate bad behavior where there are alternatives.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Wed, 15 May 2019 08:04:28 -0700

> moderate bad behavior where there are alternatives.

Agreed. Which is why I think litigating behavior of failure reports is a
separate matter for the working group, and we shouldn't shim new normative
behavior into the PSD draft.

That said - I'm still unclear if anyone agrees with me or if I'm the lone
person concerned about this, in which case I'll gladly shut up. Regardless,
I believe this document is ready for WGLC and we should proceed with it.

Seth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 May 2019 22:31:53 -0700

Hatless:

> into policy and not interop.

I've read Scott's replies to this as well.  The question I have is whether
we have consensus to include this change, but that's hard to gauge when
there's been so few names offering comments.

I'm partial to using MUST NOT only where it goes to interoperability, so
I'm inclined to agree with Seth.  However, I've been nudged away from that
position on this in the past, i.e., that it can be used to encourage best
practices and there's ample precedent for such.  Still, given other replies
on the topic, especially the presence of "unless you know what you're
doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT
with an explanation of why, and in what circumstances one would deviate
from that advice.  There are aspects of the discussion in this thread that
would be valuable to implementers (summarized, of course).

I'm also inclined to agree with Seth on his points of complexity, and on
moving contrary to DMARC's tenets.

Having said all of that, I'm not firmly resisting given that the plan is to
send this up as Experimental, as its deployment and results could usefully
inform our choices with respect to standards track DMARC.

While you all stew on that, I owe the group a top-down review of it
and the start of a shepherd write-up, so I'll do both this week.

-MSK

---

From: Dotzero <[email-masked]>
Date: Mon, 20 May 2019 04:39:39 -0400

I also lean towards Seth's perspective. Additional comments in-line.

> would be valuable to implementers (summarized, of course).

I agree with avoiding MUST NOT in this case for the reasons given (policy
vs interoperability). I think SHOULD NOT with explanation of why might be
acceptable.

> Having said all of that, I'm not firmly resisting given that the plan is
> to send this up as Experimental, as its deployment and results could
> usefully inform our choices with respect to standards track DMARC.
>
>
>
Michael Hammer

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 May 2019 00:40:11 -0400

> > usefully inform our choices with respect to standards track DMARC.

Having read the feedback from a number of people, I am inclined to revert the 
MUST NOT that I added in the last revision.  "Don't unless you know what you 
are doing" pretty generally applies to RUF, so I can see it being reasonable 
to not special case it here.

I'll wait to see if anyone else has any other changes we should make before 
posting an updated draft.

Scott K