On Monday, August 29, 2022 12:27:11 PM EDT Scott Kitterman wrote: > On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote: > > On Monday, August 29, 2022 10:59:55 AM EDT Todd Herr wrote: > > > Version created from the pull request John mentioned on-list on August > > > 28. > > > > Thanks. > > ... > > > Also, I am reminded that since this document will obsolete RFC 9091 if > > approved, we need to incorporate the Privacy Considerations from that > > document instead of referencing them. I'll prepare a recommend change for > > that. > > I looked into this a bit and it turns out to be more complicated than I > expected. > > Currently DMARCbis has no Privacy Considerations section at all. Generally, > I think this is correct since the DMARC relevant privacy issues are tied to > reporting, which is in separate drafts. I do think though that since we > are covering all aspects of DMARC record publishing in DMARCbis, there are > a few specifics that should go in the main draft with pointers to the > reporting drafts for relevant details. > > RFC 9091 Privacy Considerations (which are currently incorporated by > reference in DMARCbis) say that for PSDs, feedback MUST be limited to > Aggregate Reports. > > I think it would be appropriate that DMARCbis have a short Privacy > Considerations section which points out that putting an rua or ruf tag in > your DMARC record may have privacy implications for organizations with > pointers to the reporting drafts for details. I would include something > like if psd=y, MUST NOT also have an ruf= value in DMARCbis. > > The bulk of the RFC 9091 Privacy Considerations text would then go in I- > D.ietf-dmarc-aggregate-reporting. All that would be needed in > I-D.ietf-dmarc- aggregate-reporting Privacy Considerations is a relatively > simple admonition to not send failure reports for PSDs. > > If that seems reasonable to people, I'll prepare specifics for review.
No one complained, so off I went. I've prepared an update in git (that I will shortly submit as a PR). The bulk of it is to add a new Privacy Considerations section. That's provided below. The full diff is at: https://github.com/kitterma/draft-ietf-dmarc-dmarcbis/commit/ e27a0aa41f4d33c52c1c03710eda3c7bbc592002?diff=split I'd like to propose that unless the group turns out to think this is completely horrible, we go ahead and accept it as a basis for further work, since something is generally easier to edit than nothing. Additional changes will be needed for the reporting drafts. I'll work on those once this is settled a bit. # Privacy Considerations {#privacy-considerations} This section discusses issues specific to private data that may be included if DMARC reports are requested. Issues associated with sending aggregate reports and failure reports are addressed in [@!I-D.ietf-dmarc-aggregate-reporting] and [@!I-D.ietf-dmarc-failure-reporting] respectively. ## Aggregate Report Considerations {#aggregate-report-considerations} Aggregate reports may, particularly for small organizations, provide some limited insight into email sending patterns. As an example, in a small organization, an aggregate report from a particular domain may be sufficient to make the report receiver aware of sensitive personal or business information. If setting an rua= tag in a DMARC record, the reporting address needs controls appropriate to the organizational requirements to mitigate any risk associated with receiving and handling reports. In the case of rua= requests for multi-organizational PSDs, additional information leakage considerations exist. Multi-organizational PSDs that do not mandate DMARC use by registants risk exposure of private data of registrant domains if they include the rua= tag in their DMARC record. ## Failure Report Considerations {#failure-report-considerations} Failure reports do provide insight into email sending patterns, including specific users. If requesting failure reports, data management controls are needed to support appropriate management of this information. The additional detail available through failure reports (relative to aggregate reports) can drive a need for additional controls. As an example, a company may be legally restricted from receiving data related to a specific subsidiary. Before requesting failure reports, any such data spillage risks have to be addressed through data management controls or publishing DMARC records for relevant sub-domains to prevent reporting on data related to their emails. Out of band agreements between failure report senders and receivers may be required to address privacy concerns. DMARC records for multi-organizational PSDs MUST NOT include the ruf= tag. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
