Subject: [Bimi] Today's BoF

From: John C Klensin <[email-masked]>
Date: Thu, 28 Mar 2019 20:01:31 -0400

Hi.

Interesting presentation.  I didn't get in the mic queue because
most of my concerns were covered by others and almost certainly
won't have time to follow the list, but I want to make a few
suggestions:

First, the organizers should find and read the Jabber log.
There is a good deal of relevant material there that was not
covered in the same way during the BoF.  Warning: the tone of
several comments, almost certainly including mine, probably
conveys some frustration.  Some of the reasons for that
frustration can be deduced from the comments below.

I'm an oddity as an email user.  As examples, I've been using it
on a near-daily basis for a _very_ long time; I (like many other
IETF participants but unlike the general public) handle a large
amount of traffic every day; and I am in environments often
enough that, due to poor connectivity or other reasons, give me
incentives to download relevant messages in batches and read and
respond to them offline.  It also run my own MTA.    On the
other hand, I've got a sibling who is significantly
technology-challenged, who reads mail through a web interface,
and who thinks getting a dozen messages in 24 hour is a busy
day.  When we agree about something involving user needs or
preferences, it is nothing like the result of a controlled
experiment based on a proper sample, but it is usually a rather
good clue.  The desires of marketers and advertisers
notwithstanding, neither of us like graphical clutter in our
email: images slow down the rate at which messages load, make
caches and archives bigger, and, unless they actually convey
useful information, are rarely actually helpful.  So, if a
system like this one proposes to fill screen real estate with
logos or other brand identification images, I/we are likely to
go looking for ways to block those images.   If there are
characteristics of BIMI images that make that easy, so much the
better.    If I can block them easily, that also helps control
phishing because the only brand images that will get through
will probably be attacks and the delete key is never far away.  

So my first observation isn't really an IETF problem, but you
folks should be careful what you wish for.

More into the IETF problem space, the presentation, as I
understood it, seems to rely on technological ideas that have
been tried and rather thoroughly demonstrated to not work or not
be deployable in practice.  For starters, remember that we knew
by the late 1980s what a technical solution that would have
dealt with all of the key targets of the BIMI proposal and many
others would look like: Sign message bodies, and optionally
encrypt them, using a PKI that provided very strong assurance of
the binding between the certificate, the authenticated identity
of the signer, and with at least some connection to reputational
information.  If that information did not check out on receipt,
the message would either be discarded or would be delivered with
very strong warnings. In particular, if brand identity
information were sent with the message, the recipient could be
assured of its authenticity by knowing where the message came
from in much stronger ways than provided by SPF, DKIM, and/or
DMARC.  

While the technology evolved somewhat, it never took off.   It
would probably be safe to say that, with the exception of a
rather few extra-paranoid or extra-privacy-sensitive individuals
and some special applications, adoption has been about zero.
There were several people at the BOF --in the room or remote--
who could tell you at great length why that never happened
(although we might have different theories about which elements
were most important) but the bottom line is that, AFAICT, the
model presented at today's BOF relies on either the the
assumptions on that early idea and would be likely to have
deployment problems for similar reasons, or relies on variations
on those assumptions that are so diluted as to make attacks by a
determined party rather easy. 

    john

---

From: Wei Chuang <[email-masked]>
Date: Sun, 31 Mar 2019 16:48:15 -0700

John,
Apologies for the delay as I was in transit.

*From: *John C Klensin <[email-masked]>
*Date: *Thu, Mar 28, 2019 at 5:01 PM
*To: * <[email-masked]>

> be deployable in practice.

BIMI depends on DMARC/DKIM/SPF, and if the sender/receiver chooses to
validate the logo owner X.509.  Certainly the former has been deployed at
scale for email, and the latter web and other places at scale.

>   For starters, remember that we knew

On that I agree, that email sender based PKI aka S/MIME would provide much
strong i.e. per sender verifiable identiy.

> and some special applications, adoption has been about zero.

Agreed.

> assumptions on that early idea

The BIMI proposal depends on different, domain based authentication
technologies that have been already deployed at scale.

> and would be likely to have

But agreed that using S/MIME would have been problematic, and that
constraint certainly guides the BIMI proposal.  My own informal polling was
the key management per sender is too difficult for most senders to deploy.
Even managing relatively few keys per domain as needed by DKIM and the
crypto involved is burdensome to many, hence the proposal still allows for
SPF.

My worry, as Dave Crocker's recent message on BIMI highlights, is that
these domain based authentication methods depend on the integrity of DNS,
and apparently there's now viable attacks on DNS (The Route 53/BGP hijack
is another).  Perhaps this proposal needs to take into account such DNS
attacks now rather than later.

-Wei

>     john
>
> --
> bimi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bimi
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 31 Mar 2019 16:59:56 -0700

> technologies that have been already deployed at scale.

The message-based domain-validation components are not the issue.

The use of certificate authorities is.  At scale they are problematic, 
in spite of the tendency to claim that their use for TLS says they aren't.

And their use for linkage between domain name and logo is, since there's 
no history at scale.

And any effort to use 'validated' logos at scale has no history, where 
the challenges in doing that have been well- and often-cited.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net