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

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 25 Jan 2021 00:25:13 +0000

Hello folks,

Some time ago, an issue[1] was brought to the list where which DKIM(s) being reported is not clear in RFC7489 [2].  There was a short discussion, though no clear resolution before conversation trailed off.  It seems like there were points that may need to be discussed.  One was whether the reporting SHOULD report all signatures, regardless of alignment or validity, or perhaps just the one that aligns (if there is one).  There was also another question if there should be a limit to the number of signatures reported so that it remains sane.

We'd like to try to get this resolved within about two weeks.  Thank you for your feedback.

1: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/
2: https://tools.ietf.org/html/rfc7489#section-7.2

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: Douglas Foster <[email-masked]>
Date: Sun, 24 Jan 2021 22:27:03 -0500

Currently, my filter only evaluates signatures that are relevant to From
alignment, and stops after the first success.   For that decision process,
all that I need returned (and stored) is a Pass/Fail result; I don't need
the details of the algorithm evaluated.  Any additional information
collection is for the benefit of someone else, not the needs of my own
organization.

The burden of data collection is proportionate  to the amount of data
collected.  DMARC reporting is a courtesy service from the data collector
to the domain owner.  Each effort to increase the precision of the data may
reduce the number of domains willing to provide that information.

I suggest that we need report consumers in this group to discuss how they
use the current data and the proposed additions to that data, so that a
cost/benefit assessment can be made.   At least some of that justification
should be included in the final document, since one purpose of that
document will be to convince non-reporting entities to begin sending
reports.

Doug Foster

On Sun, Jan 24, 2021 at 7:25 PM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> Hello folks,
>
> Some time ago, an issue[1] was brought to the list where which DKIM(s)
> being reported is not clear in RFC7489 [2].  There was a short discussion,
> though no clear resolution before conversation trailed off.  It seems like
> there were points that may need to be discussed.  One was whether the
> reporting SHOULD report all signatures, regardless of alignment or
> validity, or perhaps just the one that aligns (if there is one).  There was
> also another question if there should be a limit to the number of
> signatures reported so that it remains sane.
>
> 1:
> https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Дилян Палаузов <[email-masked]>
Date: Mon, 25 Jan 2021 07:09:52 +0200

Hello,

lets say a site signs an email with both rsa and ed25519 algorithms.  This site wants to know, whether the recipient can validate the ed25519 signatures, so that in the future rsa signing for that receiving site can be skipped (or errors in the ed25519 implementation fixed).

For this to work the receiving site must put in the report information about each aligned dkim signature, saying which public key-name was used.

Greetings
  Дилян

On January 25, 2021 2:25:13 AM GMT+02:00, "Brotman, Alex" <Alex_Brotman=[email-masked]> wrote:
>being reported is not clear in RFC7489 [2].  There was a short
>discussion, though no clear resolution before conversation trailed off.
>It seems like there were points that may need to be discussed.  One was
>whether the reporting SHOULD report all signatures, regardless of
>alignment or validity, or perhaps just the one that aligns (if there is
>one).  There was also another question if there should be a limit to
>the number of signatures reported so that it remains sane.
>

---

From: Douglas Foster <[email-masked]>
Date: Mon, 25 Jan 2021 07:21:37 -0500

This is an interesting issue.   Perhaps we need another ticket just to
discuss how to handle signature transition.  My first thought is that it
will be more effective to announce support for ed25519 in the report
header, rather than in each message result.  Another possibility is for a
recipient to indicate support for new signatures in the DMARC policy record.

Any report recipient will have difficulty knowing how to extrapolate from a
single result or even a single report to a general rule.    John has
observed that the RUA report does not even indicate the target domain(s)
being reported.  I would think this data inadequacy should be a priority
for correction.   For any multi-server configuration, knowing that one IP
supports the new signatures does not mean that all servers do so.    The
challenge becomes knowing whether the domain is fully transitioned, and we
don't even know the domain being evaluated.

I suspect that a day will come when a research presents evidence that the
old signatures can no longer be trusted.  At that point, PCI DSS or GDPR
will require us to quickly deprecate the old signatures, and compliant
systems will simply ignore the RSA signatures.   At that point, transition
planning is simplified.

Dual signatures also create some challenges for ARC.  I don't think an ARC
Set can reasonably include signatures under both algorithms.

Doug Foster

On Mon, Jan 25, 2021 at 12:10 AM Дилян Палаузов <[email-masked]>
wrote:

> Hello,
>
> lets say a site signs an email with both rsa and ed25519 algorithms. This
> site wants to know, whether the recipient can validate the ed25519
> signatures, so that in the future rsa signing for that receiving site can
> be skipped (or errors in the ed25519 implementation fixed).
>
> For this to work the receiving site must put in the report information
> about each aligned dkim signature, saying which public key-name was used.
>
> Greetings
> Дилян
>
>> ------------------------------
>> dmarc mailing list
>> [email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Jan 2021 09:19:50 -0800

> signatures reported so that it remains sane.

A warning about use of "SHOULD" (or "RECOMMENDED") with respect to
protocols: Text saying "implementers SHOULD do foobar" presents the
implementer with a choice.  If you're going to say that, you need to
explain the choice; in particular, an implementer should have some idea of
the circumstances under which she might legitimately not do what it says
and what the implications of doing so are with respect to interoperability.

A bare SHOULD, meant to be hand-wavy like "you really ought to do this, but
you don't actually have to if you don't want to" is likely to draw
attention.  I've been kind of picky about this lately during IESG
Evaluation.

In this case, "reporting SHOULD report all signatures" -- why would you not?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 25 Jan 2021 12:58:25 -0500

In article <[email-masked]> you write:
>lets say a site signs an email with both rsa and ed25519 algorithms.  This site wants to know, whether the recipient can
>validate the ed25519 signatures, so that in the future rsa signing for that receiving site can be skipped (or errors in the
>ed25519 implementation fixed).

That strikes me as severe mission creep. It's something you certainly
might want to know, but it's not DMARC's job to solve it.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 25 Jan 2021 17:59:16 +0000

Doug,

And I don’t think what you’re doing is necessarily bad from an operational standpoint.  I think the question centers around whether that aligning signature is sufficient, or should you report all the signatures the receiver attempted to verify?  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?  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?

From: dmarc <[email-masked]> On Behalf Of Douglas Foster
Sent: Sunday, January 24, 2021 10:27 PM
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

Currently, my filter only evaluates signatures that are relevant to From alignment, and stops after the first success.   For that decision process, all that I need returned (and stored) is a Pass/Fail result; I don't need the details of the algorithm evaluated.  Any additional information collection is for the benefit of someone else, not the needs of my own organization.

The burden of data collection is proportionate  to the amount of data collected.  DMARC reporting is a courtesy service from the data collector to the domain owner.  Each effort to increase the precision of the data may reduce the number of domains willing to provide that information.

I suggest that we need report consumers in this group to discuss how they use the current data and the proposed additions to that data, so that a cost/benefit assessment can be made.   At least some of that justification should be included in the final document, since one purpose of that document will be to convince non-reporting entities to begin sending reports.

Doug Foster

On Sun, Jan 24, 2021 at 7:25 PM Brotman, Alex <Alex_Brotman=[email-masked]<mailto:[email-masked]>> wrote:
Hello folks,

1: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/__;!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61zozlYiYw$>
2: https://tools.ietf.org/html/rfc7489#section-7.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7489*section-7.2__;Iw!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61yIx7-bJw$>

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61wMnt5UTQ$>

---

From: "Brotman, Alex" <[email-masked]>
Date: Mon, 25 Jan 2021 18:05:20 +0000

Murray,

Personally, as a report reporter & report receiver, I would prefer to not try to figure that all out during generation/ingestion.  I’m sure there some use case to be stated for storing/reporting unnecessary data elements that have “no bearing” on the outcome for DMARC.  Or perhaps it could be perceived as a data leak to show where messages have passed on the way to their final destination.  But point made, and if we go that route, we’ll be sure to include pros/cons.  Thank you

From: Murray S. Kucherawy <[email-masked]>
Sent: Monday, January 25, 2021 12:20 PM
To: Brotman, Alex <[email-masked]>
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex <Alex_Brotman=[email-masked]<mailto:[email-masked]>> wrote:
Some time ago, an issue[1] was brought to the list where which DKIM(s) being reported is not clear in RFC7489 [2].  There was a short discussion, though no clear resolution before conversation trailed off.  It seems like there were points that may need to be discussed.  One was whether the reporting SHOULD report all signatures, regardless of alignment or validity, or perhaps just the one that aligns (if there is one).  There was also another question if there should be a limit to the number of signatures reported so that it remains sane.

A warning about use of "SHOULD" (or "RECOMMENDED") with respect to protocols: Text saying "implementers SHOULD do foobar" presents the implementer with a choice.  If you're going to say that, you need to explain the choice; in particular, an implementer should have some idea of the circumstances under which she might legitimately not do what it says and what the implications of doing so are with respect to interoperability.

A bare SHOULD, meant to be hand-wavy like "you really ought to do this, but you don't actually have to if you don't want to" is likely to draw attention.  I've been kind of picky about this lately during IESG Evaluation.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 19:25:53 +0100

On Mon 25/Jan/2021 01:25:13 +0100 Brotman, Alex wrote:
> 
> Some time ago, an issue[1] was brought to the list where which DKIM(s) being reported is not clear in RFC7489 [2].  There was a short discussion, though no clear resolution before conversation trailed off.  It seems like there were points that may need to be discussed.  One was whether the reporting SHOULD report all signatures, regardless of alignment or validity, or perhaps just the one that aligns (if there is one).

I think that, in principle, it is good to report all signatures.  Within a 
report, signatures should be ordered by importance.  If the number of 
signatures per report is limited, it is paramount that they be ordered, so that 
the most important ones are reported.

How to define importance is subjective.  A report generators decides the order 
based on internal policies or criteria.  The order in which signatures are 
reported is an additional information, as if each record contained a sort of 
approval index, irrespective of the total number of signatures being reported.

For example, my report generator orders signatures by domain, putting author's 
domain first, and then taking into account alignment and a sort of reputation. 
  That's the order in which validation is attempted.  Afterwards, valid 
signatures are put before invalid ones.  The number of reported signatures is 
limited to 4, because of SQL query limits (the query itself is configurable; it 
does a number of LEFT JOIN, which can be increased.)

>  There was also another question if there should be a limit to the number of signatures reported so that it remains sane.

Yes, I think it's sane to put a limit.  I'd reject messages with more than 128 
signatures.  It never happened.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 19:31:28 +0100

On Mon 25/Jan/2021 13:21:37 +0100 Douglas Foster wrote:
> This is an interesting issue.   Perhaps we need another ticket just to discuss 
> how to handle signature transition.

Reporting the selector suffices.  Ticket #57.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 25 Jan 2021 19:37:59 +0100

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

---

From: Douglas Foster <[email-masked]>
Date: Mon, 25 Jan 2021 13:51:59 -0500

Can we go slightly off topic to review why the report does not include the
destination domain?

That data element seems a lot more relevant than a tertiary signature.

I can see that domain identification and disaggregation could significantly
increase the size of reports from Gsuite and Office365, assuming that they
currently aggregate all domains.   This could be problematic for both them
and for the recipient.

---

From: Douglas Foster <[email-masked]>
Date: Tue, 26 Jan 2021 07:02:46 -0500

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

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 13:50:32 +0100

> problematic for calculating aggregates.

Let me attach an HTML rendering of a report I received today, so we can talk 
about something real.

Lines with IP 4.31.198.44 bear a ietf.org identifier.  I see no reason to 
remove it.  It is useful for understanding the mailflow, which is what DMARC 
reporting is designed to do.

> scopes can be used to force disaggregation down to the individual recipient

Even if this is a small example, learning the disaggregated, or even individual 
recipients does not help my understanding.  Authentication is obviously 
conditioned by how the Mediator treats my messages.

I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using the 
same algorithm, irrespective of the recipient.  That is what I, as a sender, am 
interested in.  Splitting the report in 66 lines wouldn't tell me anything 
more, it would just consume more eyeballs.  And is useless for people who sum 
up all reports and just look at the totals.  In any case, I cannot verify if 
the messages I didn't send directly are real.

If a multi-domain host allows personalized validation algorithms for some 
domains, I'd expect they send separated aggregate reports, if any.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 26 Jan 2021 09:12:57 -0500

At some point, an investigator will ask, "which of our systems sent these
messages?"

I know how to search my logs for messages to domain example.com.  I do not
know how to search my logs for messages to domains hosted by
hostingservice.tld.  That is why I would expect SMTP To domain to be useful.

An rua report is not supposed to be substitute for a forensic report,.  All
possible details are not supposed to be presented.  Source IP, SMTP
MailFrom domain, and SPF status should be sufficient to identify the
organization responsible for the last hop.  Why is additional mailflow data
necessary?

The best mail flow data would be to report the entire Received chain, but
it would cause too much disaggregation.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Jan 2021 18:01:10 +0100

> At some point, an investigator will ask, "which of our systems sent these 

Possibly none.  In that case this is either an abuse or a forward.  Or maybe 
the report generator lies.

> I know how to search my logs for messages to domain example.com I do not

A smart relay can put together in the same message several RCPT commands with 
different domains having the same MX.

> An rua report is not supposed to be substitute for a forensic report.  All 
> possible details are not supposed to be presented.  Source IP, SMTP MailFrom 
> domain, and SPF status should be sufficient to identify the organization 
> responsible for the last hop.  Why is additional mailflow data necessary?

In case of forwarding, the last hop is likely not to be aligned.  Previously in 
this thread you said reporting aligned identifiers only would suffice.  Aligned 
and last hop don't necessarily match.

> The best mail flow data would be to report the entire Received chain, but it 
> would cause too much disaggregation.

If every receiver generated aggregate reports, senders would get the whole 
chain, in different reports.

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 26 Jan 2021 20:49:52 -0500

For indirect mail, the aligned
signature selector tells you where to look for the message origin. The last
hop information tells you where it ended up.

For direct messages, the last hop tells you whether it came from a third
party or internal server, and the aligned signature selector confirms the
same.

In both cases,, verification is secondary, because it mostly indicates
whether the message was modified in transit.

Last hop and aligned selector still seems like a sufficient data set to me.

In fact, asking for extra signatures seems like a backhanded way of trying
to infer the original recipient, but supposedly the recipient is irrevant.

Remember that we are asking systems to collect data for others that they do
not need for themselves.   This is not the place to ask for the moon.

Maybe the massive organizations collect enough data so that the rest of us
do not need to participate.  If so, ask for anything, as the request will
probably not inconvenience them.

Doug Foster

---

From: Douglas Foster <[email-masked]>
Date: Wed, 27 Jan 2021 06:31:51 -0500

Is this already a settled issue?  The specification already calls for a
complete A-R data set, so all signatures are supposed to be included if
they are evaluated.  Are the largest reporting sources already providing a
complete list of DKIM signatures?

However, there are significant technical problems with aggregating a list
with a variable number of members, because the list must be converted into
a list with a fixed number of elements before aggregation can be
performed.

- One technique is to convert the list into a variable-length text string,
so that the entire list is handled as one element.   Including all
signatures in an A-R record, and then grouping on the A-R text, would be an
example of this approach.  The technique will work up to the maximum
allowed text string supported by the data management system.   The maximum
number of list elements will depend on the mechanism used to build the text
string, the information being reported, and the maximum text size.   The
maximum number of supported list elements becomes unpredictable, but in
many data management systems will be larger than the expected number of
signatures in a message, unless a message is specifically constructed to
trigger a denial-of-service attack.

- Another approach, based on E.F.Codd's data normalization rules for
relational databases, is to have a table of messages which is keyed on a
message ID, and a table of signatures, which is keyed on message ID and
sequence number.   Then an outer join can be used to append the list
element with sequence number # to the message record.   A separate outer
join is required for each sequence number being appended, so the
implementation must choose a maximum number of list elements to append.
 One recent poster said that he was using this approach.    Outer joins are
generally inefficient, and this approach might work for up to 4 list
elements, but it will not work acceptable for a list with 100 elements.

For report sources with a fixed limit, it seems appropriate to have a
metadata element where the report provider states the maximum number of
signatures that might be reported by his system.   An indicator would be
needed to indicate "many, with no pre-determined limit"

Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 27 Jan 2021 13:33:51 +0100

On Wed 27/Jan/2021 12:31:51 +0100 Douglas Foster wrote:
> Is this already a settled issue?

There doesn't seem to be a consensus, yet.

I repeat what I already proposed:

*  max number of DKIM signatures: 1024 (say)
*  min number of DKIM signatures: 0
*  can report unverified signatures (<result>none</result>)
*  order signatures by descreasing importance (reporter POV)

Would the WG post some +/-1s, please?

> - Another approach, based on E.F.Codd's data normalization rules for relational 
> databases, is to have a table of messages which is keyed on a message ID, and a 
> table of signatures, which is keyed on message ID and sequence number.   Then 
> an outer join can be used to append the list element with sequence number # to 
> the message record.   A separate outer join is required for each sequence 
> number being appended, so the implementation must choose a maximum number of 
> list elements to append.   One recent poster said that he was using this 
> approach.    Outer joins are generally inefficient, and this approach might 
> work for up to 4 list elements, but it will not work acceptable for a list with 
> 100 elements.

Could fill the whole list using transitive closure.  MariaDB implements 
Recursive Common Table Expressions, which can be used for that purpose. 
Although that feature was implemented in 2016, it landed on the distribution I 
use quite recently.  I haven't yet looked at it.

> For report sources with a fixed limit, it seems appropriate to have a metadata 
> element where the report provider states the maximum number of signatures that 
> might be reported by his system.   An indicator would be needed to indicate 
> "many, with no pre-determined limit"

It is probably more useful to report the total number of signatures found.  The 
fixed limit of a given implementation can be deduced after it is hit.

OTOH, a reference to the software version that generated the report would be 
useful in general, and may lead to the documented fixed number in particular.

Best
Ale
--