Subject: [dmarc-ietf] DMARC bis: ticket 38: reporting the proper DKIM key(s)

From: Seth Blank <[email-masked]>
Date: Sun, 7 Jun 2020 14:23:12 -0700

https://trac.ietf.org/trac/dmarc/ticket/38

The spec is ambiguous about which DKIM key needs to be reported.

The real world problem here is that sometimes the DKIM key(s) which are
reported in a row of an aggregate report have nothing to do with the DKIM
key used to evaluate the DMARC status within the same row.

In https://tools.ietf.org/html/rfc7489#section-7.2, it says:

    The report SHOULD include the following data:

        o  The identifier evaluated by DKIM and the DKIM result,

Elizabeth Zwicky previously wrote:

https://mailarchive.ietf.org/arch/msg/dmarc/0HnvtYeeseqopq1tLELctYte34M/
"is genuinely unclear. Often there are multiple identifiers. Does this mean
I can pick any one of them? (That does not actually provide sufficient
interoperability.) If there’s a specific one I should pick, which is it?"

https://mailarchive.ietf.org/arch/msg/dmarc/zDALDe2zbXhqfQ-_RVeUO1BT084/
"I believe they MUST contain any aligned DKIM signature regardless of
validity and SHOULD  contain an entry for each domain, selector, result
triple."

Is it desirable to clarify this language, such that it is clear which DKIM
keys are required to include in a report, and if so, how should the
appropriate keys be determined?

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 07 Jun 2020 19:21:36 -0400

> appropriate keys be determined?

In DKIM, I would have thought that the 'identifier' is the d= domain.  Just 
based on that text, there's no need to provide the selector.  Looking through 
the rest of the list, I don't see anything that indicates the DKIM selector 
should be included in an aggregate report.

That said, the selector is pretty useful.  I'd suggest it's essential for 
troubleshooting failures.

Maybe there's two things here:

1.  identifier needs a better definition.

2.  Is there a backward compatible way to specify inclusion of the selector.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Sun, 7 Jun 2020 16:42:00 -0700

> 2.  Is there a backward compatible way to specify inclusion of the

Selector is already there, it’s just OPTIONAL. There’s another ticket about
making it required.

>
> Scott K
>
>
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
--

---

From: "John Levine" <[email-masked]>
Date: 7 Jun 2020 20:02:13 -0400

In article <CAOZAAfOoFYMhZXy0um0t8hL=[email-masked]> you write:
>-=-=-=-=-=-

How about saying that reports MUST include the key used to evaluate
the DMARC status, if there was one, and SHOULD include all DKIM keys
evaluated.

The other ones can be useful, e.g., mailing lists usually resign their
outgoing mail so if you have an idea what what lists are sending you
mail, that gives you a strong hint that a DMARC failure is due to mail
from a list.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jun 2020 02:13:54 +0000

On June 8, 2020 12:02:13 AM UTC, John Levine <[email-masked]> wrote:
>In article
><CAOZAAfOoFYMhZXy0um0t8hL=[email-masked]>
>you write:
>>-=-=-=-=-=-
>>

When you say 'include the key', do you mean put the literal public key in the report or the selector which, in combination with the signing domain, tells one where to find the record in DNS?

Scott K

---

From: "John Levine" <[email-masked]>
Date: 8 Jun 2020 02:35:28 -0000

In article <[email-masked]>,
Scott Kitterman  <[email-masked]> wrote:
>When you say 'include the key', do you mean put the literal public key in the report or the selector
>which, in combination with the signing domain, tells one where to find the record in DNS?

Sorry, domain and selector.

R's,
John
-- 
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: Scott Kitterman <[email-masked]>
Date: Mon, 08 Jun 2020 02:58:00 +0000

>Sorry, domain and selector.

Thanks for clarifying.  I think that makes sense.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 8 Jun 2020 11:46:50 +0200

On Sun 07/Jun/2020 23:23:12 +0200 Seth Blank wrote:
> reported in a row of an aggregate report have nothing to do with the DKIM key
> used to evaluate the DMARC status within the same row.
> 
> "is genuinely unclear. Often there are multiple identifiers. Does this mean I
> can pick any one of them? (That does not actually provide sufficient
> "I believe they MUST contain any aligned DKIM signature regardless of validity
> and SHOULD  contain an entry for each domain, selector, result triple."

I think every MTA can have its own criteria about how to order DKIM signatures
in each message.  For DMARC validation, aligned signatures are important.
Valid signatures are more important than invalid or non-verifiable ones,
although reporting unverifiability is important.  Signature by trusted domains
are more important than those by unknown ones.  Key size also matters.  These
are all subjective criteria.

> Is it desirable to clarify this language, such that it is clear which DKIM keys
> are required to include in a report, and if so, how should the appropriate
> keys be determined?

Signatures should be reported in order of decreasing importance.  The more
signatures are reported, the better.  The subjective order in which they appear
is part of the informative content of the report.  Software should allow to
configure ordering criteria when possible.

Best
Ale
--