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 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