Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

[Douglas Foster <[e-mail]>]

This topic becomes much more than "which signature".   It is really about
"what is needed to identify and correct alignment problems".

Based on the authentication discussion, we have several inter-related
issues:
- I started with a concern about putting excessive data collection
requirements on the reporting domain.

- Increased data collection causes data disaggregation.   This becomes a
technical problem as report sizes increase.   Disaggregation also allows
individual message characteristics to be revealed, which becomes a
potential privacy concern.

- In theory, very few attributes should be necessary to triage an alignment
problem:  Source IP, SMTP domain, From Domain, and DKIM scope.  In
practice, investigating root cause is difficult and as a result report
recipients crave maximum data.

My current perspective, still open to being convinced

DKIM Scopes
I have not heard a compelling argument to require information about
authentication tests that are unrelated to alignment testing.    For DKIM
specifically, I think one scope should be sufficient, on this hierarchy:

- The best-aligned scope that verified, or
- the best-aligned scope that failed verification, or
- a no-signature result otherwise.

Anything more complex imposes a gratuitous data collection burden on the
reporting domain and reduces aggregation significantly.   On the technical
side, it has already been noted that variable-length lists are particularly
problematic for calculating aggregates.

I would also suggest dropping the requirement to include all authentication
test results.   Only SPF and aligned DKIM are relevant, and anything more
causes disaggregation.


Aggregation Controls

We have discussed whether the target domain should be included in the
report.  I understand that doing so is not reasonable for the large hosting
services.   On the other hand, including the target domain would be a
trivial matter for smaller operations, and I think it would be valuable for
some research.    Similarly, DKIM scopes are known to be useful for most
investigations, but John has already observed that proliferation of DKIM
scopes can be used to force disaggregation down to the individual recipient
level.

I wonder if the solution to both of these is to use variable aggregation.
  When the number of target domains is small, reporting the source domain
is probably not an issue for either the report sender or the report
receiver.    So we could make the field optional, where some organizations
report an actual target domain and others report a placeholder, with the
level of aggregation chosen by the needs of the reporting organization and
by overall constraints on report size (probably based on number of result
rows).  The same could apply to DKIM:   If disaggregation by DKIM scope
provides a report that is too large, the scope can be replaced with a
placeholder to increase aggregation and reduce report size.

DF

On Mon, Jan 25, 2021 at 1:38 PM Alessandro Vesely <[e-mail]> wrote:

> On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote:
> >
> > I’m not suggesting that we add anything that would report “Signature
> > validation not attempted”, that sounds horrible.  Will the original
> source
> > potentially care that the message was signed in three other places as the
> > message bounced around?
>
> It can be useful to understand the mail flow.  For example, a signature by
> a
> Mediator can reveal a mailing list, even if the receiver didn't evaluate
> it.
>
>
> > Should we put the onus on the reporting entity to do the filter out the
> > non-aligned (what if none aligned) signatures, or just realize it’s some
> > automated job and including all logged/validated signatures is the better
> > way?
>
> The order in which signatures appear in a report can be significant too.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>