Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

Dave Crocker <dhc@dcrocker.net> Sun, 26 July 2020 11:33 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785813A0DC5 for <dmarc@ietfa.amsl.com>; Sun, 26 Jul 2020 04:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Hgji2yHuOaPm for <dmarc@ietfa.amsl.com>; Sun, 26 Jul 2020 04:33:09 -0700 (PDT)
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 4A2013A0DC2 for <dmarc@ietf.org>; Sun, 26 Jul 2020 04:33:06 -0700 (PDT)
Received: from [192.168.1.67] (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 06QBZeMZ031222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Jul 2020 04:35:41 -0700
To: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
References: <cd9258e6-3917-2380-dd9b-66d74f3a64d3@gmail.com> <20200717210053.674D61D2C431@ary.qy> <CAL0qLwbkhG-qUyGqxaEjcFn2Lb7wPMhcPFEMA8eqptBJpePPxA@mail.gmail.com> <8efcf71c-f841-46a4-10b7-feb41a741405@gmail.com> <CAL0qLwbK7GQXkiS+H8GtsvHMzWr4o431Shc7Cc9MhqsTiHfzFw@mail.gmail.com> <bc7ed18c-8f1d-b41b-0a4b-3aa180a63563@gmail.com> <CAL0qLwYgs7py1aTQ87pykNT_0dpnrKz=+1DxMMSQMgbwz4XZDg@mail.gmail.com> <381c7792-5bd8-a1be-6b93-b7df015a2333@gmail.com> <e3278cc0-731d-5453-771d-60ca3c89842d@tana.it>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <9e9616aa-ea9e-836c-6319-377e7db80193@dcrocker.net>
Date: Sun, 26 Jul 2020 04:32:59 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <e3278cc0-731d-5453-771d-60ca3c89842d@tana.it>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/HZss_ZElwh7EXzz7O2zXfI2AxTw>
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jul 2020 11:33:13 -0000

On 7/20/2020 1:44 AM, Alessandro Vesely wrote:
> On Sun 19/Jul/2020 20:33:46 +0200 Dave Crocker wrote:
>> The essential point that needs to be made is that standards like this 
>> MUST NOT be cast in terms of what end users will do.  In practical 
>> terms, this work has nothing to do with end users. Really.  Nothing.
>> [...]
>> (*) I've seen one posting here or somewhere else that noted that 
>> letting bad mail through can lead to end-users being deceived. I'll 
>> claim that while true, it is not relevant, since the behavior happens 
>> after DMARC, and the like, are relevant.  That is, DMARC, etc., do 
>> not inform the end-user behavior.
>
> Aren't those two paragraphs self-contradictory?

No.

A specification defines a field of activity.  (A sandbox.) Things 
outside that field are not relevant to the specification, even though 
they might be highly relevant from a larger perspective. There is a 
constant desire to have a specification that involves security-related 
decision-making include the (human) recipient be an actor within the 
scope of the specification. The first paragraph, quoted above, is a 
reminder that we need to resist that desire.

The second paragraph, quoted above, is a reminder about a specific 
example of this, namely about the DMARC specification. It acknowledges 
that, in general, recipients can be deceived, for the specific From: 
field protection that DMARC provides, the recipient is not a relevant actor.


> If DMARC were dependable, maybe users would learn to trust From:. Or 
> maybe not.  Avoiding end user considerations cuts both ways. Yet, we 
> can trust that if we do a well-defined, clear job, then the whole 
> system will work better.

It is expensive and highly risky to create an international standard 
that relies on such a tenuous hope about future behavior, especially in 
the face of consistent empirical evidence that it won't happen.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net