Subject: Re: [Bimi] What if DKIM doesn't validate the selector header.

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 6 May 2021 13:19:07 +0000

Jakub,

Are you suggesting that in order to use an alternate selector (beyond default._bimi.sub.example.com or similar default) that it MUST be DKIM-signed, and MUST align in the DMARC-sense?  I could see that as being reasonable.  Let’s say this happens.  If DKIM (which originally signed the header and was properly aligned) is mangled during forwarding, and ARC is properly validated, is that also acceptable to use an specified selector?

I’m also not sure it answers the original question (if DKIM fails, and there’s a selector, should the evaluator fallback to default._bimi, assuming SPF/DMARC pass/align).

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

From: bimi <[email-masked]> On Behalf Of Jakub Olexa
Sent: Friday, April 30, 2021 2:44 AM
To: [email-masked]
Subject: Re: [Bimi] What if DKIM doesn't validate the selector header.

If the logic relies only on DMARC authenticating rather than DKIM pass then what is the abuse risk if the BIMI-Selector header is unsigned? You trust the source domain, the BIMI record comes from that "trusted source" and there was a clear intent from the sender for a specific selector. I'd suggest a binary choice here - either MUST or no signature requirement for the selector at all.

Jakub Olexa
Founder & CEO
E-mail: [email-masked]<mailto:[email-masked]>
Tel: +420 777 744 440<tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t7iKs5acU$>
On 30.04.2021 3:33, Marc Bradshaw wrote:
Hi,

I see what you are saying, this is the section...

If present, the BIMI-Selector header SHOULD be included in the DMARC-aligned
DKIM signature used to confirm authenticity of the message.  If it is not
included in the DMARC-compliant DKIM signature, the header SHOULD be ignored.

In the absence of a clear statement of what should happen if the BIMI-Selector is included in a failing DKIM signature I had read (and implemented) this as ignoring this header unless it has a valid DKIM signature, but not considering a failed signature as a blocker if DMARC passes for some other reason, either SPF, or the presence of a second passing DKIM signature for the same domain.

I propose the modification of this section to state that failing DKIM signatures SHOULD be ignored, but BIMI processing SHOULD continue.
The use of SHOULD in this section was intended to cover the cases where MBPs did not implement this check, however I would be happy to make these checks a MUST, what is the opinion of the group?

On Fri, 30 Apr 2021, at 1:45 AM, Zack Aab wrote:
Hi,
>Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails).
This is it exactly.  Maybe I missed something, but as written there is no suggested or required action if the receiver sees that the BIMI-selector is DKIM signed but that DKIM fails to validate.  This can probably be covered with one line in section 5.4, it's just a question of "should the receiver skip to default._bimi. or skip BIMI entirely?"
Thanks!
Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097<tel:+15127174097> | C +1 (404) 317-6729<tel:+14043176729> | W trendlinei.com<https://urldefense.com/v3/__https:/www.trendlineinteractive.com/__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t72RIcDAo$>

On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex <Alex_Brotman=[email-masked]<mailto:[email-masked]>> wrote:

I’m not entirely sure that answers the original question.  I don’t think the OP is an attempt to second guess DMARC. Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails).  If we believe the sections A.1/A.5 covers this scenario, perhaps we just need a little embellishment on this scenario below to be more explicit.  And yes, local policy can impact this.

--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast

From: bimi <[email-masked]<mailto:[email-masked]>> On Behalf Of Marc Bradshaw
Sent: Thursday, April 29, 2021 2:56 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Bimi] What if DKIM doesn't validate the selector header.

Hi,

Opinion: This feels like a discussion outside the scope of BIMI, SPF forgery is a known issue ref the recent Multipass attack at a well known vendor. There is a related note in the "Unsigned BIMI-Selector Header" section of the spec.

We do see senders with p=reject who rely entirely on SPF and do not DKIM sign at all, I would argue that the problem being described here is more about vulnerabilities in some shared infrastructure platforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take place in the DMARC group, and that BIMI should take the DMARC result as is as much as is possible, without imposing additional constraints over what constitutes a valid DMARC pass or fail.

MBPs are, of course, free to implement whatever additional constraints they see fit, but I don't feel that this one belongs in BIMI.

On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:

Hi,

In my opinion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector.

If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.

Jakub Olexa

Founder & CEO

E-mail: [email-masked]<mailto:[email-masked]>

Tel: +420 777 744 440<tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A1DGUptw$>

On 28.04.2021 22:06, Zack Aab wrote:

I was reading section 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi.

BUT

What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF?

It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely.

Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097<tel:+15127174097> | C +1 (404) 317-6729<tel:+14043176729> | W trendlinei.com<https://urldefense.com/v3/__https:/www.trendlineinteractive.com/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A2tiXW_Y$>

--

bimi mailing list

[email-masked]<mailto:bimi%40ietf.org>

https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A3P4VcGQ$>

--

[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  Marc Bradshaw

  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3Ajv1deoc$> | @marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3AYnziQXA$>

--
bimi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t7tmtMhfg$>
--
bimi mailing list
[email-masked]<mailto:bimi%40ietf.org>
https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t7tmtMhfg$>

--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  Marc Bradshaw
  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t79NtKVsQ$> | @marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!TfLCVUwlA6N-UmGBdsTK83EMJ7Y6e0vZDbakmAadQBUEukVeKNUlVVb2aYdaT6t7bCbWKL8$>