Last Call Review of draft-ietf-dmarc-psd-08
review-ietf-dmarc-psd-08-secdir-lc-murphy-2020-04-09-00

This is a secdir review of draft-ietf-dmarc-psd-08 (DMARC (Domain-based Message
Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix
Domains))

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

This document presents an extension to DMARC for Public Suffix Domains (PSD)
(and their operators (PSO)), which are domains that are not organizational
domains and are not subject to DMARC processing.  In DMARC, these PSD domains
can not publish policy or receive feedback for subdomains.  The extension
allows PSDs to express policy for organizational domain that are not themselves
implementing policy.  It also provides a new tag that covers non-existing
subdomains.

I find the document to be well written and well laid out (even in the face of a
few comments below).

Note:  I am not conversant with DMARC and have only read the underlying
normative references to the extent necessary to review this document.  Consider
the source in reading these comments.

The security considerations section states that it does not change the security
considerations of the base DMARC specification RFC7489.  That is common in
extensions to existing protocols.  But the authors, to their credit, note that
this extension increases some of the risks identified in the security
considerations of rFC7489.  I wish more authors of extensions to existing
protocols did similar analysis.

The security considerations section points in particular to Section 12.5 of
RFC7489, which describes the risks of external reporting addresses.  Section 4
of this document describes the privacy concerns of feedback reports leaking
information outside an organizational domain.  Section 12.5 of RFC7489 of
RFC7489 points to a verification mechanism in Section 7.1 of RFC7489.  Section
7.1 presents a detailed procedure to verify that a feedback reporting address
is safe to report to, particularly for rua or ruf tags.  Question to the
authors:  has the correctness of that procedure in the presence of this
extension been considered?  I can't tell.

Some wordsmithing comments:

Section 4.1 page 9

   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.

The sentences
                                                          "For non-DMARC
      Organizational Domains, all DMARC feedback will be directed to the
      PSO.
and
                                "This means that any non-DMARC
      organizational domain would have its feedback reports redirected
      to the PSO."
seem to say the same thing.  Are they redundant?  Or is there a difference
there that I am not seeing?

Section A page 11

              If the experiment shows that PSD DMARC solves a real
   problem and can be used at a large scale, the results could prove to
   be useful in removing constraints outside of the IETF that would
   permit broader deployment.

I would read "removing constraints ... that would permit broader deployment" as
meaning constraints that permit deployment are being removed.  The "that" would
in ordinary reading refer to "contraints".  I think the intended meaning is
"removing constraints ... where those constraints hamper broader deployment" or
"removing constraints ... thereby permitting broader deployment"

And I'm not sure whether "outside of the IETF" means that the removing occurs
outside the IETF or that the constraints exist outside the IETF.  I suspect
both, but I don't know that it makes much difference.

Section A.1 page 12

This section concerns the privacy concerns arising from the external reporting
described in Section 4.1.  In Section 4.1, the privacy risk exists for
"non-DMARC organizational domains" under a multi-organizational PSD (presumably
PSD DMARC participating, right?) that does not mandate DMARC usage for its
registrants.

Section A.1 states that knowing which PSDs do not present this risk would be
beneficial and describes an experiment to produce that knowledge.

Desirable attributes for such a mechanism includes the following:

   o  List PSDs that either mandate DMARC for their registrants or for
      which all lower level domains are controlled by the PSO and that
      the relevant PSO has indicated a desire for the PSD to participate
      in PSD DMARC

I get the "mandate DMARC" part - the risk exists in the case the PSD does not
mandate DMARC - if the PSD mandates DMARC, it does not produce the privacy risk.

I do not get the next part:
                                                               or for
      which all lower level domains are controlled by the PSO and that
      the relevant PSO has indicated a desire for the PSD to participate
      in PSD DMARC"

I do not see how the desire of the PSO that the PSD should participate in PSD
DMARC would help alleviate the privacy risk for the PSD's registrant
organizational domains.  In the first place, what does the PSO's desire got to
do with alleviating risk?  In the second place, this mechanism is supposed to
produce a list of PSDs that do not produce the risk.  The risk in Section 4.1
assumes (or so I thought) that the PSD participates in PSD DMARC.  So if the
PSD is not participating in PSD DMARC, then it is therefore not producing risk,
but it obeys the PSO desire, then the PSD becomes in the category of producing
the risk, not alleviating risk.

I suspect I am just confused here.

--Sandy Murphy