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

[Scott Kitterman <[e-mail]>]

On Thursday, May 9, 2019 1:35:28 PM EDT Seth Blank wrote:
> On Thu, May 9, 2019 at 9:39 AM Scott Kitterman <[e-mail]> wrote:
> > In theory, I agree, but in practice, I think the new MUST NOT is a great
> > 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.

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.

> > > Speaking of which, with the normative MUST NOT that's been added, now
> > > 4.1
> > > 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.
> 
> 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.

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

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