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

Request Review of draft-ietf-dmarc-psd
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-04-08
Requested 2020-03-18
Authors Scott Kitterman
Draft last updated 2020-04-09
Completed reviews Genart Last Call review of -08 by Dale Worley
Secdir Last Call review of -08 by Sandra Murphy
Opsdir Last Call review of -08 by Qin Wu
Assignment Reviewer Sandra Murphy
State Completed
Review review-ietf-dmarc-psd-08-secdir-lc-murphy-2020-04-09
Posted at https://mailarchive.ietf.org/arch/msg/secdir/53q6fJsmM98smRbNlC3HRoYrfyc
Reviewed rev. 08
Review result Has Nits
Review completed: 2020-04-09

Review
review-ietf-dmarc-psd-08-secdir-lc-murphy-2020-04-09

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