Re: [Bimi] MUA Evaluation of BIMI

[Dave Crocker <[e-mail]>]

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