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

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

Alex,

I’ve just realised that the TLS-based mechanism I proposed in my previous email could be challenging to implement in multi-tenant scenarios where, for example, the MUA connects to mail.mycorp.org while the MBP is validating BIMI using isp.net. This can create complications in ensuring the authenticity of BIMI-Receiver-Signatures.

To address these challenges, I propose below two new mechanisms to flag BIMI-awareness. Being "BIMI-aware" means that the message store guarantees the following to the MUA:

- Any BIMI-Receiver-Signature found in a message has been generated by the MBP itself.
- All external BIMI-Receiver-Signatures received either via SMTP or through IMAP/JMAP append operations have been removed.

The two new mechanisms to flag BIMI-awareness I propose are:

- Introduce a new "BIMI" capability in the IMAP CAPABILITIES response and the JMAP Session Resource object. Implementing this should be fairly simple but requires a new IANA registration for the capability.
- Add a new CNAME entry for each message store within the MBP indicating BIMI-aware status. The entry would look something like "_bimi.<hostname> CNAME TXT 'v=BIMI1;'", ensuring a clear and direct method to verify the message store's capabilities. For example, if the MBP allows clients to retrieve emails from both "mail.isp.net" and "mail.mycorp.org," this would necessitate two distinct CNAME entries: "_bimi.mail.isp.net" and "_bimi.mail.mycorp.org”.

The DNS-based mechanism is my preferred solution due to its simplicity and the direct way it communicates the BIMI-aware status to the MUA.


Best,
Mauro De Gennaro
Stalwart Labs Ltd.


> On 24 May 2024, at 22:57, Mauro De Gennaro <[e-mail]> wrote:
> 
> 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.
> 
>