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

Benny Lyne Amorsen <benny+usenet@amorsen.dk> Mon, 20 July 2020 09:44 UTC

Return-Path: <gid-dmarc@m.gmane-mx.org>
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 85B663A07C2 for <dmarc@ietfa.amsl.com>; Mon, 20 Jul 2020 02:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, NICE_REPLY_C=-1, SPF_HELO_NONE=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 LsuDkOYQwldN for <dmarc@ietfa.amsl.com>; Mon, 20 Jul 2020 02:44:05 -0700 (PDT)
Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) (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 63FB73A07BF for <dmarc@ietf.org>; Mon, 20 Jul 2020 02:44:05 -0700 (PDT)
Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from <gid-dmarc@m.gmane-mx.org>) id 1jxSL5-0008aC-NP for dmarc@ietf.org; Mon, 20 Jul 2020 11:44:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: dmarc@ietf.org
From: Benny Lyne Amorsen <benny+usenet@amorsen.dk>
Date: Mon, 20 Jul 2020 11:43:58 +0200
Message-ID: <87zh7ur069.fsf@orion.amorsen.dk>
References: <bf5b68c74a3c487ca8a07a0a27061e47@com>
Mime-Version: 1.0
Content-Type: text/plain
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Cancel-Lock: sha1:H0PiOUOdFfk913zAcxHp3O5LDxU=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/MgaNDhOMb6dT3f_Ntie5HBjNMV8>
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: Mon, 20 Jul 2020 09:44:07 -0000

"Douglas E. Foster" <fosterd@bayviewphysicians.com> writes:

> Ultimately, this becomes a question of power.  Do domain owners have
> the right, with the help of their correspondents, to prohibit spoofing
> (unauthorized use) of their digital identity?

Domain owners are free to use the court system to assert trademark
rights and copyright. They are also free to apply whichever seals of
digital identity that they want, of course.

> Or since they are technically leaseholders, not owners, are their
> rights conditional?

You seem to be laboring under the impression that domain owners have a
right to compel mail recipients to respect a DRM scheme. This is not the
case. You can try to sue Google to force them to reject incoming email
with your domain in the From: field and no valid DKIM (or whatever)
signature, of course, but I have a hard time imagining which right you
would assert to make the suit successful.

> Specificslly, do Internet insiders have the right to declare their
> spoofing control efforts to be based on foolish premises, both
> unnecessary and inconvenient, and therefore not allowed?

No one, certainly not "Internet insiders" of which I am certainly not
one, is stopping you from doing whichever spoofing control efforts you
want on your systems.

Feel free to keep p=reject on your domains. Many mail servers will keep
using that as a signal among many others, rather than as a blanket
reject.

If you want recipient mail servers to change that policy you can either
do it by convincing their administrators or by getting a law passed. So
far you appear to favour the latter approach, with your focus on
"prohibit" "unauthorized use" and "rights". The IETF is not a lawmaking
body, so it appears there are better venues for you.