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

Dave Crocker <dhc@dcrocker.net> Thu, 23 July 2020 13:15 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 5C3443A0AB3 for <dmarc@ietfa.amsl.com>; Thu, 23 Jul 2020 06:15:57 -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, HTML_MESSAGE=0.001, 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 NmL0aZklhsfe for <dmarc@ietfa.amsl.com>; Thu, 23 Jul 2020 06:15:54 -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 4676E3A0A56 for <dmarc@ietf.org>; Thu, 23 Jul 2020 06:15:52 -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 06NDIMif014450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Jul 2020 06:18:22 -0700
To: Joseph Brennan <brennan@columbia.edu>, IETF DMARC WG <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> <d8bab034-7539-fbb4-faa0-daf6aa51e087@wisc.edu> <CAMSGcLAfhvsJhzB0Ukaer_ZCS276vZ5i=k08KAcWudJ0mLvLEw@mail.gmail.com>
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <1e38ca7f-2794-52ea-d6d2-e3b2d32f2c8a@dcrocker.net>
Date: Thu, 23 Jul 2020 06:15:42 -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: <CAMSGcLAfhvsJhzB0Ukaer_ZCS276vZ5i=k08KAcWudJ0mLvLEw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------DAF3CB280213EF3CE5CDD002"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/JSSCL6zoouzedKg8PgeJYw3pF7w>
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: Thu, 23 Jul 2020 13:15:57 -0000

On 7/23/2020 6:07 AM, Joseph Brennan wrote:
>> I think that we just have to agree that From-munging by MLMs is a permanent reality.  It needs to be documented more prominently (and promoted as part of the DMARC marketing) so that implementations are more consistent, so that un-munging tactics and/or MUA behavior can be consistently implemented.
>>
> I'd be happier for the proposed standard to say that DMARC policy
> "SHOULD NOT" be compromised by rewriting From lines-- and see how that
> goes over. My reasoning is that blessing the practice makes it easier
> for bad actors to craft spoofed mail and get it accepted. The opposite
> of the purpose of DMARC, isn't it?


Technical specifications are not policy advisories or expressions of 
opinion.  They definebehavior to be used by actors that are trying to 
follow the specification.  A specification defines a sandbox.  Normative 
statements apply to actors that have chosen to be inside the sandbox.

So, normative language in specifications is meaningful only when it will 
be followed.  Giving directives to actors not participating in the topic 
of the specification is wasteful and likely misleading.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net