Re: [Bimi] MUA Evaluation of BIMI

[Trent Adams <[e-mail]>]

These are all good points… and knowing that there's no clear win here, what if the specification identified a pattern along the lines of:


  1.  If the MUA can validate the DKIM signature in the message, and DMARC alignment passes, it can validate BIMI and take the appropriate steps to display the logo.  Sure, it's a long shot, but it could happen.
  2.  If DKIM validation fails, the MUA looks for the most recent ARC signature block, and if it's from the mailbox provider (e.g. "gmail.com"), the MUA may use the signed AuthN-Results on the way to validating BIMI.
  3.  If there is no identifiable ARC signature from which the MUA can extract verified AuthN-Results from the mailbox provider, the MUA may (at their peril) cook up local magic to identify what they believe to be reasonable AuthN-Results to use for BIMI validation (though, this is discouraged within the Security Considerations section).

I know… this is all very algorithmic… and it side-steps the point about resources of constrained devices (but since there's at least one mobile client doing it today, I guess it's not impossible)… but it would provide some guidance to address the question of how independent MUAs might be able to perform BIMI validation.

Otherwise… if we really don't think it's a good idea to allow anyone other than the MTA validating SPF+DKIM+DMARC to evaluate BIMI… then we should update the spec to specifically call that out.  It's the ambiguity hole we should try to address (even if just for now, knowing we can think up better ideas over time).

More thoughts,
Trent


From: Dave Crocker <[e-mail]>
Organization: Brandenburg InternetWorking
Date: Tuesday, March 15, 2022 at 12:14 PM
To: Ken O'Driscoll <ken=[e-mail]>, Trent Adams <[e-mail]>, "Brotman, Alex" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Bimi] MUA Evaluation of BIMI

On 3/15/2022 11:00 AM, Ken O'Driscoll wrote: >> So, not, it is not (necessarily) the wrong place for the >> operation. > > Sure, DKIM can be implemented in an MUA, but the accuracy of the > results is architecture dependent.


On 3/15/2022 11:00 AM, Ken O'Driscoll wrote:

>> So, not, it is not (necessarily) the wrong place for the

>> operation.

>

> Sure, DKIM can be implemented in an MUA, but the accuracy of the

> results is architecture dependent. For example, if the architecture

> modifies inbound messages after DKIM is verified (e.g., puts an

> "External message" warning in) then while the A-R header is correct,

> the MUA-level DKIM validation will give a different answer. The MUA

> may correctly validate DKIM but that does not fully inform the user

> of anything useful regarding message authentication.

>

> So yes, it's possible but with too many caveats to be useful to

> recommend in general, or in a specification.



1. the concern applies to all components that touch the message along

the path.  Within a recipient's enterprise system, the odds of this

being a problem might be higher, but that simply points to the need for

clarity about end-to-end trust issues with BIMI use; it also turns out

to play into the next, larger point...



2. Just as the enterprise might mess up the DKIM signature, it might

create problems with an A-R field.







> I believe the same goes, to a lesser degree, for MUA-level ARC



Sorry to have left that off.  As I recall, it, too, is an end-to-end

architecture that can reasonably be implemented in the MUA.  And yes,

handlers along the path to it can mess up the ARC data.







>> As for the receiving MTA lying, turn the issue around:  how can the

>> MUA know that the field came from that specific, well-behaved,

>> thoroughly compliant MDA or MTA.

>>

>> Broadly, how is the chain of trust established sufficiently for the

>> MUA to know that the A-R header field is to be trusted?

>

> I'm actually not sure that they should be programmatically trusted by

> an MUA because there isn't an established reliable low-cost mechanism

> to do so.



I think you've just implied that an independent MUA should never display

a BIMI icon, since it can't be trusted...





By that I mean, for example, even if the ARC trust issue

> was solved tomorrow, I doubt that a mobile phone based MUA is going

> undertake the resource cost of reliability implementing ARC

> validation for each message.



I was making an architectural point, which means it is independent of

implementation specifics.



You are making a reasonable point, but it is about a specific

implementation/use concern  (And given the power and connectivity of

typical smartphones these days, uhhh...)







> MUA level trust in headers should be based on user/implementor

> awareness of its limitations and risks. A spec. can do that. A spec.

> could even say that a TLS connection between the MUA and MTA is

> required. If you want chain of trust at MUA level, then use a

> PKI-based solution.



This goes back to the original point that this issue needs due diligence

and documentation.







> I believe the goal should be to avoid as much as possible some future

> MTA-level implementation with the hypothetical

> "Always_show_BIMI_logo_regardless = true;" configuration option. I

> think that best way to work towards that goal is for the

> specification to clearly articulate the conditions, limitations, and

> considerations for implementing BIMI at MUA level.



+1



d/





--

Dave Crocker

Brandenburg InternetWorking

bbiw.net