Re: [dmarc-ietf] Benjamin Kaduk's Discuss on draft-ietf-dmarc-psd-12: (with DISCUSS and COMMENT)

[Tim Wicinski <[e-mail]>]

On Tue, May 11, 2021 at 12:24 AM Benjamin Kaduk <[e-mail]> wrote:

> Hi Tim,
>
>
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > This document is generally in pretty good shape; my comments (and,
> > > to some extent, my discuss as well) are pretty minor points.
> > >
> > > Thanks to Sandra Murphy for the secdir review.  I think there were some
> > > questions in there that are worth a response and possibly
> clarifications
> > > in the document.
> > >
> > >
> > Sandra did a strong review and I believe we worked through the issues
> > raised.
>
> I'm happy to hear it; I may have just been misled by the mailarchive entry
> for the secdir list.
>

There was a Large GENART review that had us rework several sections
which were ones that Sandra had also mentioned.  I will go back and
read her email again just to make sure.


> >
> > > Section 1.2
> > >
> > > It seems like the "branded PSD" and "multi-organization PSD" cases
> would
> > > benefit from a protocol-level indication and separate handling by
> > > message recipients.  It seems likely that the newly defined np (in
> > > combination with the preexisting sp) provides the flexibility to
> > > describe the different cases, but it seems like it would be helpful to
> > > have some discussion in this document that relates these two cases to
> > > the actual protocol mechanisms used to achieve them.
> > >
> > >
> > There is no different handling of between a "Branded PSD" and a
> > "multi-organization PSD".  The difference is highlighting the types.
>
> I think I agree that the actual mechanics of handling the protocol
> elements, if they exist, shouldn't really differ for the two cases.  It
> seems that there may be some subjective differences, though, in that it
> would be really surprising if the "multi-organizational PSD" decided to
> publish policy for existant subdomains, whereas for branded PSDs that is
> normal and expected, since in some sense they really ought not be PSDs at
> all.
>

Consider the case of the bad actor attempting to publish
a "multi-organizational PSD" policy for purposes of
pervasive monitoring.   One of the reasons for the registry
is to prevent such actions.


>
> >
> > > Section 4.1
> > >
> > >    o  Multi-organization PSDs (e.g., ".com") that do not mandate DMARC
> > >       usage: Privacy risks for Organizational Domains that have not
> > >       deployed DMARC within such PSDs are significant.  For non-DMARC
> > >       Organizational Domains, all DMARC feedback will be directed to
> the
> > >       PSO.  PSD DMARC is opt-out (by publishing a DMARC record at the
> > >       Organizational Domain level) vice opt-in, which would be the more
> > >       desirable characteristic.  This means that any non-DMARC
> > >       organizational domain would have its feedback reports redirected
> > >       to the PSO.  The content of such reports, particularly for
> > >       existing domains, is privacy sensitive.
> > >
> > > It might be worth making some statement about the applicability of PSD
> > > DMARC for such PSDs that do not mandate DMARC usage.  (I guess the
> > > following paragraphs mostly play that role, though perhaps editorially
> > > tying them together more clearly is possible.)
> > >
> >
> > I'm not sure where you're going on this, but the following paragraphs do
> > try to pull it together.  I've been trying to wordsmith these with little
> > luck.
> >
> > Also, it appears that the word "vice" above should be "versus".
>
> I suspected it might :)
>
> Maybe the following is useful input to your wordsmithing attempts:
>
> By definition the new mechanisms in this document result in PSDs receiving
> feedback on non-existent domains.  However, these non-existent domains may
> be similar to existing Organizational Domains, and as mentioned above,
> feedback on existing organizational domains is privacy-sensitive.  To
> minimize the risk of privacy-sensitive information relating to existing
> organizational domains being sent to the parent as feedback on a similar
> non-existent domain, PSD DMARC feedback MUST be limited to Aggregate
> Reports.  Feedback Reports carry more detailed information and present a
> greater risk.
>


Thanks.  I'm want to also see what the working group thinks/feels
on the current text and your suggestions.


> >
> >
> > > Or, in the vein of my comment on section 1.2, an explicit protocol
> > > mechanism could be introduced that limits the reporting to just the
> > > indicated (public suffix) domain and does not apply to subdomains.
> > >
> > >    organizational PSDs MUST be limited to non-existent domains except
> in
> > >    cases where the reporter knows that PSO requires use of DMARC.
> > >
> > > Do we have examples of how the reporter might come to know this?
> > > Say ... Appendix B.2?
> > >
> > >
> > Roman raised a similiar point.   I was thinking of adding
> >     "(by checking the DMARC PSD Registry)"
> >
> > or would a full sentence be used to bring the point back home?
>
> I don't see a need for a full sentence.  I would check whether an "e.g." is
> warranted, vs the registry being the only way to do so.
>

Okay, I'll add this and will figure out the "e.g."


> > > Appendix B.1
> > >
> > >    A sample stand-alone DNS query service is available at
> > >    [psddmarc.org].  It was developed based on the contents suggested
> for
> > >
> > > "DNS query service" is so generic so as to be almost meaningless.  Even
> > > if we defer usage instructions to the external site, we should probably
> > > say a bit more about what it is expected to do.
> > >
> > I tend to agree with you here.  The only other options I could come
> > up with is "PSD DMARC Lookup service".    I'll try a few others.
>

I am leaning toward "DNS Lookup service", which fits into my DNS
world view.

tim