Re: [dmarc-ietf] DMARCbis Privacy Considerations was: Re: I-D Action: draft-ietf-dmarc-dmarcbis-17.txt

[Scott Kitterman <[e-mail]>]

On Monday, August 29, 2022 1:48:57 PM EDT Alessandro Vesely wrote:
> On Mon 29/Aug/2022 18:27:11 +0200 Scott Kitterman wrote:
> > On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote:
> >> 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.
> 
> I have no opinion on the worthiness of a Privacy Considerations section.
> However, I'd mandate that a report generator MUST NOT send failure reports
> related to subdomains of a PSD (which is approximately expressed in the
> failure reporting draft.)
> 
> Prohibition to publish a ruf= sounds strange.  Would the record become
> invalid in that case?  And then there's the case of PSDs sending mail,
> which may be entitled to receive failure reports as well.
> 
> > 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.
> 
> Aggregate reporting seems to be extraneous to those considerations, no?

RFC 9091 Privacy Considerations spend the bulk of its text discussing 
Aggregate reporting.  Failure reporting is a simple "don't".  I'm not 
proposing inventing anything new beyond what's needed to deal with the 
document split.

I hadn't anticipated anything that would cause records to become invalid.

Scott K