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

[John C Klensin <[e-mail]>]

--On Sunday, May 5, 2024 12:20 -0700 Dave Crocker <[e-mail]>
wrote:

> On 5/5/2024 10:59 AM, Brotman, Alex wrote:
>> I meant "BIMI working group" as the Auth Indicators Working
>> Group  (bimigroup.org) 
> 
> The opening bit of text:
> 
> 
>> What is BIMI?
>> 
>> Brand Indicators for Message Identification or BIMI (pronounced: 
>> Bih-mee) is an emerging email specification that enables the use
>> of  brand-controlled logos within supporting email clients. BIMI
>> leverages  the work an organization has put into deploying DMARC
>> protection, by  bringing brand logos to the customer's inbox.
>> For the brand's logo to  be displayed, the email must pass DMARC
>> authentication checks,  ensuring that the organization's domain
>> has not been impersonated.
>> 
> 
> Is nicely written, except for the last clause.  Since BIMI does
> not do that.
> 
> An email can quite easily impersonate an organization's domain in
> all sorts of places in a message, without BIMI or DMARC detecting
> the impersonation.
> 
> Note, for example, that mailing lists must break DMARC in order to
> get mail properly delivered, and in doing so, the recipient sees
> and replies to exactly the domain name that is supposedly protected
> against. And while this is necessary for legitimate mail going
> through mailing lists, it is as easily used by bad actors...

Alex, Hanno, Dave, and others,

I agree with Hanno's and Dave's analyses and conclusions.  Dave's
remarks are a better summary of those issues that I could have
provided, especially when they draw on discussion in M3AAWG before
this work appeared in the IETF.   I'll try to avoid repeating their
comments, but let me add a few...

(1) Some of the concerns about whether BIMI actually provides a
significant level of authentication of a logo and authorization --as
the text Dave quotes above and other materials, including those at
bimigroup.org, seem to claim-- remains questionable.  My memory,
reinforced by a quick scan of the mail archives, indicates that, as
far as this list and the IETF are concerned, goes back to at least
the March 2019 BOF and have, at least IMO, never been seriously
addressed.   A key part of the problem is that the transport of
Internet email assumes a relay model in which a message may be handed
off from one MTA to another to another (potentially independently
operated) one as it moves toward its destination.  

The problem is that any of those intermediate systems can alter any
header (or message body) information from a prior hop, meaning that,
whether we describe the protocols involved as being about security or
not, strong assertions about authenticity of the message, the sender,
or some particular body part that are based on header or DNS
information about systems involved in earlier hops are impossible
without significant external information.    The very nature of BIMI,
as I have understood the descriptions at the BOF, on the web site, in
the I-Ds, and on this list, is to make such assertions about
authenticity. 

That situation changes if one condition is met: the message
originating system (the MUA or, maybe, the MSA), the MUA at the
receiver end, and every intermediate system are all controlled by the
same entity.    For the BIMI case, that entity will presumably also
be the organization that controls the brand identifier.   That
situation would exist for some sort of app use to receive messages
provided by the branding organization for its customers receiving
messages from it, e.g., a Comcast customer receiving mail that was
generated by Comcast into a Comcast-provided mailbox.  Verizon
customers receiving the same messages into a using Verizon-provided
mailboxes and a general-purpose MUA would not work.  They would not
be able to guarantee authenticity of a Comcast brand indicator, at
least without a private deal between Comcast and Verizon.  Either a
single-vendor app structure or a requirement for such an enabling
deal would, IMO, make the work be about support of a private product
and inappropriate for the IETF.  IANAL, but my sense after recent
activities in Europe and various US Government agencies is that it
might also raise competitiveness or antitrust issues from which the
IETF would want to keep a safe distance.

>From a more technical perspective, if the same vendor-entity can be
guaranteed to control that entire originator -> destination MUA path,
there are probably few, if any, advantages to getting involved with
SMTP and the hop-by-hop architecture.  One could have a simpler and
more reliable setup with a private app and transmission mechanism. 

For the general case ("designed to be open and to work at Internet
scale" and several of the bullet points in Section 1 of
draft-brand-indicators-for-message-identification-05), there is a
clear answer to the question posed in Section 10 of that document.
Unless "some semblance of trust" is interpreted as "really not much
more that attaching an image file without all of the complexity of
BIMI", it is, approximately, "dream on". 

I think there are now also at least two procedural issues of interest:

* The apparent current state of the BIMI work and this list, at least
if I correctly understand what is going on, is that the BOF was held
over five years ago.  Since then, even though several separate I-Ds
have been periodically updated (one with a change of name to one that
now violates normal I-D naming conventions), there has been no
significant progress toward an IETF WG, one that, among other things,
would have change control over the protocol.  That is, especially in
Internet years, a very long period of time.   If this work actually
is headed toward an IETF WG, what is the plan?  If so, that plan
should probably assume those of us who raised concerns in the last
few weeks will probably do our best to ensure that the charter
requires that the proposed WG address those concerns and that the
alternate strategies that were identified some years ago also be
considered.  Just my opinion, but there has been enough controversy
already (starting with the BOF) that there isn't going to be a fast
track to an IETF stamp of approval for a specification developed
elsewhere that has already been identified as problematic.

* Use of an IETF-hosted mailing list and the I-D posting process are
likely to create the impression that this is IETF work and/or that
the IETF is considering it, even if (as I'm confident is the case)
the authors don't intend that.  So, if there is no plan about getting
to a WG, can those involved made a plan about moving the list and
documents elsewhere, perhaps to bimigroup.org?

thanks,
   john