[Bimi] Re: Possible security flaw in BIMI spec / interaction of BIMI-supporting MUA with non-BIMI-supporting MTA

[Mauro De Gennaro <[e-mail]>]

Alex,

Sorry I missed the original post.

I have just reviewed your draft and it closely aligns with my thoughts. However, I am particularly concerned about the injection of headers into an unaware MBP, as briefly discussed in sections 6.1.1 and 6.1.2.

To address this issue, I propose an additional mechanism that enables the MUA to determine which BIMI-Receiver-Signature headers are trustworthy. This mechanism would involve validating BIMI-Receiver-Signature headers only if they are signed by a domain that either:

  - Appears in the IMAP greeting banner (or the JMAP session object).

or,

- Corresponds with the server name or matches one of the Subject Alternative Names in the certificate used to establish the TLS connection with the mail store.

The latter option offers a more robust solution, ensuring a higher degree of security and reliability in the validation process.



Best,
Mauro De Gennaro
Stalwart Labs Ltd.


> On 24 May 2024, at 21:13, Brotman, Alex <Alex_Brotman=[e-mail]> wrote:
> 
> Mauro, 
>  
> A couple of weeks ago, I had posted a document to this list that may help with that scenario:
>  
> https://mailarchive.ietf.org/arch/msg/bimi/n_n4N1ueDH8v2yqGzvW-o6_lXBk/
>  
> The rough gist is that the MTA adds a few more headers, and signs them all.  There are mechanism for revocation as well.
>  
> -- 
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast
>  
> From: Mauro De Gennaro <mauro=[e-mail]> 
> Sent: Friday, May 24, 2024 2:24 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Bimi] Re: Possible security flaw in BIMI spec / interaction of BIMI-supporting MUA with non-BIMI-supporting MTA
>  
> Hi Dave,
> Some don't.  Some do.  The limitation is not inherent in the nature of MUAs.
> 
>  
> Thanks for your feedback but I believe the opposite, that these limitations are indeed inherent. 
>  
> Even if a MUA were to attempt to replicate all BIMI validations independently, it inherently lacks access to crucial data such as the SMTP envelope or the IP address of the sending server. These elements are essential for assessing DMARC alignment, which is central to the BIMI validation process as we know.
>  
> While it's true that this information might be available in the Authentication-Results headers, we circle back to the same foundational issue: it requires MUAs to implicitly trust the MTA. Unless you operate within an integrated environment like Gmail or Fastmail, where the MUA and MTA are closely coupled, this trust model poses significant challenges.
>  
> The nature of most MUAs, being independent from the MTAs, restricts them from performing standalone, reliable BIMI validations without either implicit trust in the MTA or a robust mechanism to verify the trustworthiness of the information provided by the MTA. This was the rationale behind my suggestion to use ARC sealing as a method to pass down trust, ensuring both the authenticity and integrity of BIMI headers directly from the server.
>  
>  
> Best,
> Mauro De Gennaro
> Stalwart Labs Ltd.