Experimental DMARC Extension For Public Suffix Domains
draft-ietf-dmarc-psd-12

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Benjamin Kaduk Discuss

Discuss (2021-04-20)
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 (2021-04-20)
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.

Murray Kucherawy Yes

Roman Danyliw No Objection

Comment (2021-04-21)
Thank you to Sandra Murphy for the SECDIR review.  Please review those proposed clarifying edits.



** Section 4.1
Due to the inherent Privacy and Security risks associated with PSD
   DMARC for Organizational Domains in multi-organization PSDs that do
   not particpate in DMARC, any Feedback Reporting related to multi-
   organizational PSDs MUST be limited to non-existent domains except in
   cases where the reporter knows that PSO requires use of DMARC.

Is there any guidance on how the reporter might know “that [the] PSO requires use of DMARC”.

** Section B.2.
-- Please define the semantics of the “status” column and the expected/possible values

-- Reconcile the differences between the initial values noted in this this document and those at http://psddmarc.org/registry.html:
o the text in this section says “current” for the status column, but the html page has same values as set to “active”

o the PSD names in the initial values of this document are of the form “.*”, but the html page has no leading dot (i.e., “.bank” vs. “bank”)

Lars Eggert No Objection

Comment (2021-04-14)
Section 3, paragraph 2, comment:
> 3.  PSD DMARC Updates to DMARC Requirements
>
>    This document updates DMARC as follows:

If I understand things correctly, this document specifies an experiment that -
if successful - would lead to an update of RFC7489. It's therefore confusing to
see the text in Section 3 that is written as if that update was already being
brought into effect. I'd much prefer text that said things like "to participate
in this experiment, implementations should do X or Y or Z and/or interpret
Section foo of RFC7489 as bar", etc.

Section 7.3, paragraph 1, comment:
> 7.3.  URIs

It's unusual for an RFC to have reference sections other than for normative and
informative references, because it's not clear what category references here
would fall into. Also, I'll note that [psddmarc.org] was cited as an informative
reference in that section, so why not this one?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3.2, paragraph 3, nit:
>       to that of the "p" tag defined below.  If the 'np' tag is absent,

The document uses both single and double quotes throughput (above is an
example), and it's not clear if this is deliberate (i.e., there is a meaning to
this) or whether this is an editorial oversight that should be corrected.

Section 6.1, paragraph 5, nit:
>    +----------+-----------+---------+-------------------------------+
>    | Tag Name | Reference | Status  | Description                   |
>    +----------+-----------+---------+-------------------------------+
>    | np       | this      | current | Requested handling policy for |
>    |          | document  |         | non-existent subdomains       |
>    +----------+-----------+---------+-------------------------------+
>

You should add an RFC Editor Note instructing them to replace "this document"
with the RFC number of this document (to make sure they are aware of the
action).

Section 1, paragraph 2, nit:
-    DMARC ([RFC7489]) provides a mechanism for publishing organizational
-          -         -
+    DMARC [RFC7489] provides a mechanism for publishing organizational

Section 1, paragraph 3, nit:
-    found in Section 3.2 of the DMARC specification.  Currently the
+    found in Section 3.2 of the DMARC specification.  Currently, the
+                                                               +

Section 1, paragraph 4, nit:
-    In the basic DMARC model, PSDs are not organizational domains and are
+    In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains and are
+                               +++++++++++++++++++++++   +

Section 1.2, paragraph 7, nit:
-    handling policy for non-existent subdommains.  This is provided
-                                           -
+    handling policy for non-existent subdomains.  This is provided

Section 1.2, paragraph 7, nit:
-    of requesting harsh policy treatment (e.g. reject) is lower.
+    of requesting harsh policy treatment (e.g., reject) is lower.
+                                              +

Section 1.2, paragraph 8, nit:
-    (i.e. if a DMARC record were published for 'example', then mail from
+    (i.e., if a DMARC record were published for 'example', then mail from
+         +

Section 2.7, paragraph 2, nit:
-    is a broader definition than that in NXDOMAIN [RFC8020].
-                                         ---------
+    is a broader definition than that in [RFC8020].

Section 4.1, paragraph 7, nit:
-    not particpate in DMARC, any Feedback Reporting related to multi-
+    not participate in DMARC, any Feedback Reporting related to multi-
+              +

"B.3.", paragraph 3, nit:
-    supposed to be the output domain of the regular PSL lookup, i.e.  the
+    supposed to be the output domain of the regular PSL lookup, i.e.,  the
+                                                                    +

Erik Kline No Objection

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2021-04-15)
Thank you for the work put into this document. It is easy to read and specify an experiment, which could be useful.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Sections 1 and 3--
I share Lars' concern about the "update" in the last paragraph.

-- Section 5.1 --
Editorial comment: why using a sub-section ? Let's 'glue' its contents to the first § of section 5. BTW, interesting read this section.

== NITS ==

-- Section 2.2 --
Unsure whether "Requests for Comment (RFC)" is really required ;-) cfr https://www.rfc-editor.org/materials/abbrev.expansion.txt

-- Sections 2.2 ... 2.7 --
Mostly cosmetic but I would have preferred the usual presentation to introduce terminology, i.e., a list and not several sub-sections.

Robert Wilton No Objection

Comment (2021-04-19)
Thanks for this document.  A few minor clarifying comments that may help this document:

   o  Branded PSDs (e.g., ".google"): These domains are effectively
      Organizational Domains as discussed in [RFC7489].  They control
      all subdomains of the tree.  These are effectively private
      domains, but listed in the current public suffix list.  They are
      treated as Public for DMARC purposes.  They require the same
      protections as DMARC Organizational Domains, but are currently
      unable to benefit from DMARC.

I found this paragraph confusing.  In "These are effectively private domains", it wasn't clear to me what "these" refers to.  Is it the domains or the subdomains.   Otherwise it says "these are effectively" twice, with two different descriptions.  ​Perhaps, check if this paragraph can be reworded to make it clearer.


  ​These
  ​issues are not typically applicable to PSDs, since they (e.g., the
  ​".gov.example" used above) do not typically send mail.
  ​
I presume that this means that emails are not directly sent from @gov.example, rather than there is no mail below .gov.example.  Perhaps worth clarifying?

    For DMARC purposes, a non-existent domain is a domain for which there
   is an NXDOMAIN or NODATA response for A, AAAA, and MX records.  This
   is a broader definition than that in NXDOMAIN [RFC8020].
   
I presume that this means that there is no response for any of A, AAAA and MX records, not that there is no response for a particular type of record.  Should this be clarified? Although arguably it seems pretty obvious.

Thanks,
Rob

Martin Duke No Record

Warren Kumari No Record

Francesca Palombini No Record

Zaheduzzaman Sarker No Record

John Scudder No Record