Re: [Bimi] (non)desire for bimi

Dave Crocker <dhc@dcrocker.net> Mon, 18 February 2019 16:36 UTC

Return-Path: <dhc@dcrocker.net>
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 5C1931295D8 for <bimi@ietfa.amsl.com>; Mon, 18 Feb 2019 08:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net
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 fXBRQOsQEQtK for <bimi@ietfa.amsl.com>; Mon, 18 Feb 2019 08:36:56 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B8C1277D2 for <bimi@ietf.org>; Mon, 18 Feb 2019 08:36:56 -0800 (PST)
Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id x1IGcGQc004092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Feb 2019 08:38:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1550507897; bh=9NEGpnQFBubpLgEVXUX/L+jKWA17K5X9z1eGs/DKHQU=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=cFFpPu2ahPFr1TfFyZf3L+LA62SghR4r5jJvVCAWBovA1M0kGt/BDIWHqYWR+rh8E gbzbCvznSI94pQMDKwVUnl1XIbWdvRIsqoXv/JikoLS/IR57dLFrCfITJ6nLxWMaEq vIDrbmabs4eWPTapDLrNaZsNcNHFPhvigyp1H2z4=
To: Thede Loder <thede=40skyelogicworks.com@dmarc.ietf.org>, bimi@ietf.org
Cc: Marcel Becker <marcel.becker@oath.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <aa919aeb-caa1-6494-259d-a553b238c268@cs.tcd.ie> <3d9231e9-6936-cc02-000e-a4d7df919bb4@andreasschulze.de> <CAAYvrBvGediUY1W9PZ+JuS585Mk8wxLpFq7TZELSOF-NSp5CyQ@mail.gmail.com> <5c7a10e3-47a0-e84a-d78a-dea5c44fb2ae@dcrocker.net> <CAAYvrBumzJrj51VdOYEf_Tmo4X-MhvfuabWHb_p5embAe0uAow@mail.gmail.com> <0245cd12-2965-86ca-78e4-b3b1996e6efe@gmail.com> <A08D52DA-AC05-4A6A-BF9C-AEF2239E8F61@skyelogicworks.com> <6ac6da1c-6c60-b983-7e1a-90d3fb30ac5b@dcrocker.net> <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <f686a0a1-6699-2d25-813c-ccf4ef5d3eb0@dcrocker.net>
Date: Mon, 18 Feb 2019 08:36:41 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <6929D4C0-FE58-43E9-9605-98F040308B74@skyelogicworks.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bimi/u5bPcf942rbaf4a3ehOMOe-k5pE>
Subject: Re: [Bimi] (non)desire for bimi
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: Mon, 18 Feb 2019 16:36:59 -0000

On 2/18/2019 7:59 AM, Thede Loder wrote:
> 
>> On Feb 17, 2019, at 21:50, Dave Crocker <dhc@dcrocker.net> wrote:
> Even if we assume that the premise is true (end users treat messages exactly the same), and if we agree that this implies end users will not be made worse off through their own choices as a consequence, it says nothing of other mechanisms through which users might be made worse off (or better off). 

Yes, limiting the scope of discussion to the topic at hand is certainly 
constraining.

So, how is your point relevant to an evaluation of /this/ proposal?


> I asked the question to help move the discussion forward.  Maybe we can agree on some things.

Thede, there has already been a number of very substantial concerns 
raised.  You seem to be focusing on trying to raise new ones rather than 
dealing with the ones already raised.  Your summary list, below, is more 
helpful.


> If people believe that end users treat messages with and without logos exactly the same, then we could potentially move on from considering the positive or negative implications of end user-mediated choices. 

We could do that if Bimi documentation and its advocates didn't keep 
suggesting improvements in recipient handling of email.


> End user choices can neither be a cause of improvement nor a cause of worsening.

That implies that a user's choosing to believe a phishing message 
doesn't make things worse.


> On the other hand, and given that end user security and safety is really really important, it might not be the wisest thing to assume away end-user mediated choices as a potential factor of change in outcomes.

That seems to suggest ignoring the long and solid track record that 
expecting end-user mediated choices will happen has been wrong. Please 
explain why that's being ignored.


> If we let in the possibility that changes in choices could exist and may make users worse off, we have to let in the possibility that end-user choices may be a means through which we can make users better off.  One cannot have it both ways.

You're introducing a view that hasn't been put forward.

What's been put forward is that justifying a security mechanism based on 
an expectation of recipient decision-making during message processing is 
known to be inappropriate.


> My personal opinion is that we need to leave open the possibility, because to do otherwise violates the engineering practice of ‘fail-safe’.

Please explain.


> (That said, none of BIMI’s proponents are arguing that end users' choices resulting from the display of logos will be a primary or substantive cause of improvement in outcomes. 

They have.  And some of the documentations can be taken to imply that it 
will.


> No one is saying that this mechanism should even be considered for reasons other than for its potential to reduce safety. 

The mechanism will /reduce/ safety???


> What I hear from the above as additional concerns are:
> 
> A) larger strategic opportunity costs
> B) narrow, increased security exposures
> C) plausable misuse
> D) extremely expense of doing a standard
> 
> 
> Can you elaborate on A?  Help us understand these costs.

An effort like this both sets expectations and consumes resources.  The 
former won't be met and will disappoint the market which will incline it 
to have lower receptiveness to the next proposal.  People working on 
this won't be working on other strategic effort.  Both of these are 
significant downsides.


> Can you provide examples for B and C so that we can begin a discussion of mitigation strategies?

I believe Stephen offered B.

As fort C, cf DMARC.


> Regarding D, let’s begin a larger discussion of costs.  Given your experience, where do you see the costs in doing a standard?

Consider the aggregate effort to produce a standard and consider the 
cost of the people who do that work.  30 years ago, I estimated at least 
US$1M for the simplest IETF standard.  It hasn't gotten cheaper.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net