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

Doug Foster <fosterd@bayviewphysicians.com> Wed, 22 July 2020 13:39 UTC

Return-Path: <btv1==472bc16fc88==fosterd@bayviewphysicians.com>
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 5A4993A0930 for <dmarc@ietfa.amsl.com>; Wed, 22 Jul 2020 06:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bayviewphysicians.com
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 k93Gq9hGm203 for <dmarc@ietfa.amsl.com>; Wed, 22 Jul 2020 06:39:53 -0700 (PDT)
Received: from mail.bayviewphysicians.com (mail.bayviewphysicians.com [216.54.111.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D26D3A097B for <dmarc@ietf.org>; Wed, 22 Jul 2020 06:39:48 -0700 (PDT)
X-ASG-Debug-ID: 1595425187-11fa3107a84a4e0001-K2EkT1
Received: from webmail.bayviewphysicians.com (smartermail4.bayviewphysicians.com [192.168.1.49]) by mail.bayviewphysicians.com with ESMTP id FzSPbbB0RGjpiae2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO) for <dmarc@ietf.org>; Wed, 22 Jul 2020 09:39:47 -0400 (EDT)
X-Barracuda-Envelope-From: fosterd@bayviewphysicians.com
X-Barracuda-RBL-Trusted-Forwarder: 192.168.1.49
X-SmarterMail-Authenticated-As: fosterd@bayviewphysicians.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayviewphysicians.com; s=s1025; h=message-id:subject:to:from; bh=xaZ48RCTHsC5GLwR3+EIqABKuOUnRBLqTsCdEj4lXxE=; b=IHhpk2FFQEQ9ObGYeVkMQhy43HmvzvVuj49sOAPFUPSntiGTcmGsla+kv3hR6NG9I j46L4U4LvQcJl7qoC0FME0OSBaBxjY6srrK8vd9PcSxJRHxHLH5ryGfIO3r2HtSOC aOoT07BAEpvbbv9GY5hUiskKBx2asYExkXpGeM/nk=
Received: from MSA189 (UnknownHost [192.168.2.108]) by webmail.bayviewphysicians.com with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256); Wed, 22 Jul 2020 09:39:38 -0400
From: Doug Foster <fosterd@bayviewphysicians.com>
X-Barracuda-RBL-IP: 192.168.2.108
To: '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> <5AF00366-DB28-41CB-A1C4-F5BCA77EC969@wordtothewise.com> <CAL0qLwZRYb4yk_WJKizR0UA97XK3VedfZw73YgyTPHuOpxZQhQ@mail.gmail.com> <9A436C27-CECC-46DD-B365-1FCF9366E64F@wordtothewise.com> <d71be01e-af9c-7bb1-a8d0-b384039c4e94@dcrocker.net>
In-Reply-To: <d71be01e-af9c-7bb1-a8d0-b384039c4e94@dcrocker.net>
Date: Wed, 22 Jul 2020 09:39:38 -0400
X-ASG-Orig-Subj: RE: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations
Message-ID: <002201d6602d$8b87dca0$a29795e0$@bayviewphysicians.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQE4LtKXiz8pli4lbqSKvNALUr56MgJ5g18OAYZ/SGMBZFHX2QEyqW97AhtZsaICLwmy2wEtHGvdAjdD9nEBr+G5YQMbdNCRqbdyS2A=
X-Exim-Id: 002201d6602d$8b87dca0$a29795e0$
X-Barracuda-Connect: smartermail4.bayviewphysicians.com[192.168.1.49]
X-Barracuda-Start-Time: 1595425187
X-Barracuda-Encrypted: ECDHE-RSA-AES256-SHA384
X-Barracuda-URL: https://mail.bayviewphysicians.com:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at bayviewphysicians.com
X-Barracuda-Scan-Msg-Size: 2416
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.00
X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.83379 Rule breakdown below pts rule name description ---- ---------------------- --------------------------------------------------
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/kY6fc-uZlpLr-KlGpzP1o-YtFZ0>
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: Wed, 22 Jul 2020 13:39:55 -0000

Since the conflict between DMARC and Mailing Lists is related to the changes that Mailing List apply to a received message, it may be useful to review the purposes that each of those changes serve, with a goal of eliminating unnecessary changes.

Specifically, this list adds a footer to every message.   Is the footer a "trust indicator" which serves an imaginary purpose, or a necessary addition for other reasons?   If it is added as a trust indicator, perhaps it could be dropped.

I would be willing to format my submissions to IETF specifications, if it would protect the integrity of my signature.   But IETF has not disclosed a way for that to be done.   What I can determine is that the footer addition is currently unconditional, as evidenced by reply messages with multiple copies of the footer, and therefore I cannot prevent my signature from being invalidated.

DF

-----Original Message-----
From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, July 22, 2020 9:24 AM
To: IETF DMARC WG
Subject: Re: [dmarc-ietf] Response to a claim in draft-crocker-dmarc-author-00 security considerations

On 7/21/2020 1:08 AM, Laura Atkins wrote:
> When we’re basing a protocol on “what the user sees” and “what the 
> user can trust” then I think we have to. DMARC says “users can trust 
> that mail from @domain.example is really from @domain.example” but if 
> the user never sees that, how do they know?


I think this can be connected to the query about threats that DMARC is 
intended to respond to, by virtue of suggesting clarity about /where/ 
the responding takes place.

My contention is that it takes place in a receiving filtering engine and 
does not take place at the user level.

Further, it's one more data point in that engine's analysis process, 
rather than being in any simple way definitive.

In any event, work here really should make a point of creating text that 
is clear about threats DMARC is intended to respond to, and clear about 
where such responding takes place.

To the extent any of that text makes assertions about the performance of 
end users, it needs to cite the basis for the assertions.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc