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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dmarc-psd-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

There seems to be a bit of internal inconsistency in Appendix B.2:

   Names of PSDs participating in PSD DMARC must be registered this new
   registry.  New entries are assigned only for PSDs that require use of
   DMARC.  [...]

These two sentences seem to be in conflict, since a PSD can participate
in PSD DMARC without requiring use of DMARC for all its subdomains.  The
rest of the section is clear that the registry is only intended to be
for PSDs that do require the use of DMARC for subdomains, so I expect
that a minor tweak to the wording of "PSDs participating in PSD DMARC"
would be an appropriate fix.


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

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.

Section 3

As Lars and Éric already commented, I suggest using a phrasing that
includes something like "this experiment" and maybe "proposes", since
actually formally updating the DMARC specification would procedurally be
a bit exciting.

Section 3.2

   np:  Requested Mail Receiver policy for non-existent subdomains
      (plain-text; OPTIONAL).  Indicates the policy to be enacted by the

I assume that "subdomains" here refers only to direct children (i.e.,
one additional label), not deeper in the hierarchy.  It's not entirely
clear to me whether all readers will do likewise, though...

Section 3.3, 3.6

It sounds like this entire paragraph is appended to the section?
In other subsections we are a bit more explicit about where the new text
is going and what part is the new text.

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

Appendix A

   o  Section 3.2 adds the "np" tag for non-existent subdomains (DNS
      NXDOMAIN).  [...]

Per §2.7, this is for NXDOMAIN or NODATA, not just NXDOMAIN.

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.