Re: [Bimi] BIMI & the MUA

["Brotman, Alex" <[e-mail]>]

Taavi,

I agree, it is complex. However, with some of the goals being that the MBP may wish to revoke previous authorization and the MUA being able to rely on the data on the message, that shouldn’t be surprising.

As to relying on the “Authentication-Results” header, the MUA cannot rely on that presence of that alone.  The MUA must be able to be sure that the MBP that received the message is the entity that placed the A-R header into the message.  If a MBP does not utilize BIMI (or maybe even DMARC), they may not remove an pre-existing header that a malicious sender has inserted.  If the MUA finds that header, it could attempt to use it.   So, maybe the MBP signs the A-R header, and that’s sufficient for that part of the requirement.

Perhaps the document needs some additional “rationale” sections to better illustrate why it was being done this way.

Thanks for the feedback

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

From: bimi <[e-mail]> On Behalf Of Taavi Eomäe
Sent: Tuesday, September 5, 2023 7:53 AM
To: [e-mail]
Subject: Re: [Bimi] BIMI & the MUA


Hi,

The draft RFC (draft-brotman-bimi-mua-00) seems to add a very significant amount of complexity to the BIMI process with no clear benefit.

This additional complexity can introduce vulnerabilities, implementation inconsistencies and would cause additional resource usage in both MTAs and MUAs. If it is implemented at all, considering the complexity.

Using DNS as a key-value store is also quite wasteful (especially with DNSSEC) if not simply abuse or misuse of DNS. Such DNS usage also introduces additional risks, especially if you take into account how rare (O)DoH(3) or DoT is.

Inherently the MUA has to trust that the MTA that received the letter. Thus simply looking at Authentication-Results and if it contains "bimi=pass", should be sufficient for the MUA.

The VMC itself contains expiration, if that's important to the MUA. If there is a need for faster revocation, looking into OCSP would be a better choice.

If one of the goals is to further cache logos (and to increase privacy), instead of the massive "BIMI-Receiver-Signature" header, the logo's base64 could be added for the MUA. For example "BIMI-Logo".

It should be noted that we (Zone Media OÜ) are maintaining and developing a web-based MUA that currently supports BIMI<https://bimigroup.org/bimi-infographic/>. (In addition to our own MTA and MSA.) Alternative approaches should be heavily considered instead of this draft RFC.



Best Regards,
Taavi Eomäe
Zone Media OÜ