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