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

Hanno Böck <hanno@hboeck.de> Sun, 05 May 2024 11:21 UTC

Return-Path: <hanno@hboeck.de>
X-Original-To: bimi@ietfa.amsl.com
Delivered-To: bimi@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 09242C14F61E for <bimi@ietfa.amsl.com>; Sun, 5 May 2024 04:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hboeck.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UkeQeeSL4tdi for <bimi@ietfa.amsl.com>; Sun, 5 May 2024 04:21:50 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [IPv6:2a01:4f8:121:1ffe:1::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656FCC14F693 for <bimi@ietf.org>; Sun, 5 May 2024 04:21:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hboeck.de; s=key1; t=1714908105; bh=wQWu+AKxkilRM4tDIvyHQz11sEGBjOBP9SzZyHIeDSk=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=XPMeLyXxHQ1nCWzquCLsi7+DWff9tGdR3iNFA7YaaDoFLHoF3U0YyE1EKUruIagla +v5zDDtCrk994f9HuPwPmKyvVGjbLy06/KI7R2iFkHMnGIF5h0PHWgrXUNvCvkgrM7 bPRTPWkdJqXbxQtfeOzY9FtNfcnypP8YTIE0uE+5sW19j5qKpnuwpoL3+LAOZSggRT BQnnVdABcW3lddUetTc3E4NkMLP82ZLJDfu2tn6xGJmvyWWtkLB274XUU8pTt8r/Gn SsYvDtMq8gp5wUvOAmQFIUqwfLtMM5GjdJKfsTUjSd4a2J9myRmDMUQc1i08T9hKU6 2zD9oCnoaXOPQ==
Original-Subject: Possible security flaw in BIMI spec / interaction of BIMI-supporting MUA with non-BIMI-supporting MTA
Author: Hanno Böck <hanno@hboeck.de>
Date: Sun, 05 May 2024 13:21:44 +0200
From: Hanno Böck <hanno@hboeck.de>
To: bimi@ietf.org
Message-ID: <20240505132144.1b62ff64@computer>
X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/PS8Xf1hQ41oCAwtsUvVsbRSs34Q>
Subject: [Bimi] Possible security flaw in BIMI spec / interaction of BIMI-supporting MUA with non-BIMI-supporting MTA
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Brand Indicators for Message Identification <bimi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bimi>, <mailto:bimi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bimi/>
List-Post: <mailto:bimi@ietf.org>
List-Help: <mailto:bimi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bimi>, <mailto:bimi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 May 2024 11:51:30 -0000


I have recently looked into BIMI, and I believe there is a fundamental
security issue in the way it is currently proposed.

I'm referencing the spec in the document
draft-brand-indicators-for-message-identification-05, which I believe
is the latest version:

In the case of BIMI with Verified Mark Certificates (VMCs), which I
believe is the common case, I understand that the protocol roughly
works like this:

1. A mail sender implements DKIM/SPF/DMARC and publishes a DNS policy
referencing a logo and a VMC.

2. The receiving MTA is responsible for validating those. Upon
successful validation, the MTA sets the BIMI-Location and
BIMI-Indicator headers. The BIMI-Indicator header contains the
base64-encoded logo.

3. The MUA will display the logo in the BIMI-Indicator header.

There's an obvious issue here: How does the MUA know that the MTA that
set this header? It could have been set by the sender, letting the
sender display any logo he chooses.

This appears to be addressed in the spec, and it is even mentioned that
there might be a security issue. It says in 7.8: "Regardless of success
of the BIMI lookup, if a BIMI-Location or a BIMI-Indicator header is
already present in a message it MUST be either removed or renamed.
[...] Allowing one or more existing headers through to a MUA is a
security risk."

However, there is an obvious problem: only MTAs implementing the BIMI
spec will do this. Using a MUA that implements BIMI and an MTA that
does not support BIMI creates an inherent security risk.

This is such an obvious problem that I wonder if it was really missed.
It looks like there is some missing piece that the spec fails to
mention. Some hints sprinkled throughout the spec appear to suggest
things that are not explicitly spelled out.

One could imagine that BIMI should only be implemented by mail
operators that offer an integrated combination of MTA/MUA. Common
examples would be webmail interfaces or apps provided by mail operators
that have hardcoded the mail server host. A sentence in the spec hints
that this may be the idea. ("It is expected that MBPs implementing BIMI
will do so in both their MTAs and MUAs.") It appears an MBP is
referencing such a tightly integrated solution.

If that is the idea, clearly the spec should spell that out - and also
explicitly say that any MUA that allows configuring the mail server
MUST NOT implement the spec.

Another possible idea might be that there is some mechanism for a
server to communicate to a client that it has implemented BIMI, like an
IMAP extension. However, such an extension would obviously have to be
documented somewhere. It also raises some nontrivial questions for
implementors: What happens if a user moves a mail from a
BIMI-supporting mailbox to a non-BIMI-supporting mailbox? Would the MUA
need to track where a mail came from? Would an IMAP server have to make
sure that it removes BIMI-Location / BIMI-Selector headers that were
uploaded via IMAP and not received via SMTP and validated?

These are subtle issues that one would expect to be addressed in the
security considerations.

An IMAP extension mechanism is also hinted at: "This document does not
cover how domains or indicators are verified, how MUAs should display
the indicators, or how other protocols (i.e. IMAP, JMAP) can be
extended to work with BIMI. Other documents may cover these topics."

Of course, "other documents" is not a very precise reference. Also, I
have not found any other document specifying an IMAP-BIMI-Extension
that would address this. (I shall say that there are multiple points in
the spec that reference "elsewhere" or "other documents". I would not
consider that to be acceptable for a spec.)

There is also a sentence saying: "The MUA performs locally defined
checks to make sure that it can trust the BIMI-Indicator header."
Again, this implies that the MUA would have to do something extra. But
it does not say what.

To summarize:

* There appears to be a major, inherent security flaw in the BIMI spec
  for the combination of a BIMI-supporting MUA with a
  non-BIMI-supporting MTA.

* Some ideas about how this might be addressed are hinted at, but they
  are not clearly spelled out.

Currently, I believe implementing BIMI in MUAs is not possible in a
secure way based on the current specification. It requires additional
safeguards that have yet to be documented. Or that may be documented
"elsewhere" or in "other documents" that the spec does not reference.

I have some other security concerns about the BIMI spec, which I will
probably explain in a future mail.

Hanno Böck - Independent security researcher