[Bimi] Today's BoF
John C Klensin <john-ietf@jck.com> Fri, 29 March 2019 00:01 UTC
Return-Path: <john-ietf@jck.com>
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 BF4F9120308 for <bimi@ietfa.amsl.com>; Thu, 28 Mar 2019 17:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id regZ60vy9ai8 for <bimi@ietfa.amsl.com>; Thu, 28 Mar 2019 17:01:40 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7708120342 for <bimi@ietf.org>; Thu, 28 Mar 2019 17:01:40 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1h9exn-000FiI-GP for bimi@ietf.org; Thu, 28 Mar 2019 20:01:39 -0400
Date: Thu, 28 Mar 2019 20:01:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: bimi@ietf.org
Message-ID: <309EBD4AD64BE436663E721D@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/OhNI8NW8TirOuZLVgWGVg5Pp9i0>
Subject: [Bimi] Today's BoF
X-BeenThere: bimi@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 29 Mar 2019 00:01:44 -0000
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
- [Bimi] Today's BoF John C Klensin
- Re: [Bimi] Today's BoF Wei Chuang
- Re: [Bimi] Today's BoF Dave Crocker
- Re: [Bimi] Today's BoF Wei Chuang
- Re: [Bimi] Today's BoF Dave Crocker
- [Bimi] Laches (was: Today's BoF) Richard Clayton
- Re: [Bimi] Today's BoF John C Klensin
- Re: [Bimi] Today's BoF John Levine
- Re: [Bimi] Today's BoF John C Klensin
- Re: [Bimi] Today's BoF Wei Chuang
- Re: [Bimi] Today's BoF Wei Chuang
- Re: [Bimi] Today's BoF Wei Chuang
- Re: [Bimi] Today's BoF Richard Clayton
- Re: [Bimi] Laches (was: Today's BoF) Wei Chuang
- Re: [Bimi] Laches Dave Crocker
- Re: [Bimi] Laches John Levine
- Re: [Bimi] Laches Dave Crocker
- Re: [Bimi] Today's BoF Wei Chuang