Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Chair weighing in, as chair:

We're divided in the sense that there are some who want to add this
information, but as I see it the rough consensus is not divided:
- This is extra information that's being proposed... so, a new
feature.  That requires rough consensus to add it.
- Serious privacy issues have been raised with respect to adding that
information.
- No refutation of those privacy issues has been given, and no
adequate mitigation has been proposed.  The suggestion of requiring a
minimum level of aggregation is insufficient, as there's ample general
evidence that privacy leaks survive aggregation.
- We therefore do not have rough consensus to add this.

The chairs, therefore, declare this issue closed.

I'll also note that the IESG *will* bring up the privacy issues and
would very likely block the document on those grounds.  I don't think
we want to go there.

Barry

On Wed, May 5, 2021 at 9:18 PM Brotman, Alex
<Alex_Brotman=40comcast.com@dmarc.ietf.org> wrote:
>
> Are we divided?  Seems like use cases have been noted.  However, removing these completely protects some aspects of privacy.  Could we perhaps err on the side of caution, removing these definitions, and leave a note to suggest that if domain holders need further assistance to reach out to the report generator. The generator can then make decisions about how much information to expose.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>
> > -----Original Message-----
> > From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Alessandro Vesely
> > Sent: Tuesday, May 4, 2021 5:07 AM
> > To: dmarc@ietf.org; Douglas Foster
> > <dougfoster.emailstandards@gmail.com>
> > Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
> >
> > Doug,
> >
> >
> > On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
> > > No.  I can't talk straight.
> > >
> > > I meant to say that we need N unique (and valid) smtp TO addresses, so
> > > that an attacker cannot send a single email address and wait for an
> > > rua report to know where it lands.
> >
> >
> > A simple positive DSN can confirm email addresses better than elaborate
> > DKIM design.  To confirm delivery is usually not considered a privacy
> > violation, given that the sender learned the recipient's address.  Privacy
> > violation occurs when senders track the recipient's opening of each message,
> > which is typically obtained by inserting unique images in HTML messages.
> >
> > Avoiding to reveal final email addresses requires various precautions, which,
> > if I understood what Laura wrote, can be put into effect on forwarding.  I
> > would *add to the Privacy Consideration section* that, due to reporting,
> > changing the envelope from is not enough, From: has to be changed as well
> > in order to forward without revealing the final address.
> >
> >
> > > Valid addresses are needed to hinder usage of bogus addresses to defeat
> > the test.
> >
> >
> > However, the aggregate report counts the number of messages, not the
> > number of recipients.
> >
> >
> > > Requiring aggregation on DKIM selector follows the sane logic to hinder
> > > tracking an individual.
> > >
> > > Using DKIM selectors for tracking will also put a huge load on DNS if
> > > implemented at scale, so it needs to be obstructed.
> >
> >
> > I think mass mailers have better means to track recipients.  But I agree that
> > to generate, publish, retrieve and report million DKIM selectors would be
> > somewhat impractical.  Putting a limit on aggregate report size (even if not
> > requested by the report consumer) can prevent excessive disaggregation.
> >
> >
> > > It is also not enough to null the DKIM selector; the null aggregate still needs
> > > to meet the N recipient requirement.  If not, then additional selectors need
> > to
> > > be nulled or the nulled-selector messages need to be completely excluded
> > from
> > > the report.
> >
> >
> > Most reports I send have <count>1</count>, given my volumes.  Yet, by
> > aggregating many of them one could reach significant sums.
> >
> >
> > > If the To domain is included in the report, the aggregation rules should still
> > > apply.  If they cannot be met, then the To domain must be nulled out or
> > the
> > > report not sent.
> >
> >
> > This is a recipient's choice.  If I wanted to stay anonymous, I'd use a domain
> > like gmail.com rather than tana.it.
> >
> >
> > > I favor making To domain an option which the owner domain requests and
> > the
> > > sending domain chooses to follow or ignore.  This provides upward
> > > compatibility.  The request for this data element keeps coming up.  The
> > > protocol can allow flexibility so that the participants make the final decision.
> >
> >
> > It is already optional in the I-D.  (Not that I find it useful.)
> >
> >
> > > I asked previously whether report senders do any filtering based on
> > domain
> > > reputation, and the answer was "probably not".  I think the specification
> > > should encourage recipients to omit reporting to sources with negative
> > > reputations, as their motive for report collection may be unrelated to
> > > self-identification.
> >
> >
> > Some receivers cannot report mail discarded during early SMTP phases at all,
> > for example because the DMARC filter is run after the end of data.
> >
> >
> > > I want the protocol to address all of Laura's concerns.  I think ensuring
> > > aggregation is the best way to do this.
> >
> >
> > DMARC cannot address those concerns directly, IMHO.  However, it can note
> > under
> > what conditions aggregate reporting doesn't violate privacy.  It is especially
> > useful to note that, in most cases, aggregate reports do NOT constitute a
> > privacy risk.
> >
> >
> > Best
> > Ale
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> > __;!!CQl3mcHX2A!R7ZKTY4HhF1wSMZwpruVsXIE5-
> > EtRxdlYaxRVkylrlTKnqYLGf-PSpD4ChOUaRGFE27SBql-1Q$
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc