[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 [127.0.0.1]) 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-Level:
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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (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
Hello, 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: https://www.ietf.org/archive/id/draft-brand-indicators-for-message-identification-05.html 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 https://itsec.hboeck.de/
- Re: [Bimi] Possible security flaw in BIMI spec / … Stephen Farrell
- [Bimi] Re: Possible security flaw in BIMI spec / … John C Klensin
- [Bimi] Possible security flaw in BIMI spec / inte… Hanno Böck
- Re: [Bimi] Possible security flaw in BIMI spec / … Dave Crocker
- Re: [Bimi] Possible security flaw in BIMI spec / … J N
- Re: [Bimi] Possible security flaw in BIMI spec / … Dave Crocker
- Re: [Bimi] Possible security flaw in BIMI spec / … Dave Crocker
- Re: [Bimi] Possible security flaw in BIMI spec / … Brotman, Alex
- Re: [Bimi] Possible security flaw in BIMI spec / … Dave Crocker
- Re: [Bimi] Possible security flaw in BIMI spec / … Taavi Eomäe
- Re: [Bimi] Possible security flaw in BIMI spec / … Brotman, Alex
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Taavi Eomäe
- [Bimi] Re: Possible security flaw in BIMI spec / … John C Klensin
- [Bimi] Re: Possible security flaw in BIMI spec / … Stephen Farrell
- [Bimi] Re: Possible security flaw in BIMI spec / … Taavi Eomäe
- [Bimi] Re: Possible security flaw in BIMI spec / … Murray S. Kucherawy
- [Bimi] Intentions for an IETF BIMI Working Group Seth Blank
- [Bimi] Re: Possible security flaw in BIMI spec / … Murray S. Kucherawy
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Mauro De Gennaro
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Mauro De Gennaro
- [Bimi] Re: Possible security flaw in BIMI spec / … Brotman, Alex
- [Bimi] Re: Possible security flaw in BIMI spec / … John C Klensin
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Possible security flaw in BIMI spec / … Mauro De Gennaro
- [Bimi] Re: Possible security flaw in BIMI spec / … Mauro De Gennaro
- [Bimi] Re: Possible security flaw in BIMI spec / … Dave Crocker
- [Bimi] Re: Intentions for an IETF BIMI Working Gr… Murray S. Kucherawy
- [Bimi] Re: Intentions for an IETF BIMI Working Gr… John C Klensin
- [Bimi] Re: Intentions for an IETF BIMI Working Gr… Murray S. Kucherawy
- [Bimi] Re: Intentions for an IETF BIMI Working Gr… Wei Chuang
- [Bimi] Re: Intentions for an IETF BIMI Working Gr… Tim Hollebeek