[dmarc-ietf] PSD simplification

Dave Crocker <dhc@dcrocker.net> Wed, 12 December 2018 04:17 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 BFBE3130DC4 for <dmarc@ietfa.amsl.com>; Tue, 11 Dec 2018 20:17:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=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 FbtlpjCNh5M2 for <dmarc@ietfa.amsl.com>; Tue, 11 Dec 2018 20:17:45 -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 39B8F12EB11 for <dmarc@ietf.org>; Tue, 11 Dec 2018 20:17:45 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wBC4Iajh015832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <dmarc@ietf.org>; Tue, 11 Dec 2018 20:18:37 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1544588317; bh=fuV56bBFnDH7P8Yg78FotjUF0iK3keXe+kWMuDsd+SE=; h=From:Subject:To:References:Reply-To:Date:In-Reply-To:From; b=geSBelmsx/Pac65t6FLHXU8cCFiVMe4GIhGVUEBHyolqfeaRwkjzbN8bCs90nrtSv hQheQwhjNJDxU+TYabLxqyfSEuotS7EWlNUBow8IJzyGVv+wBOLSDtvBEA/RFYXey2 m2Ux4v9DckhAegQGZYES0mBVxzkR1FC3qF+BnA4A=
From: Dave Crocker <dhc@dcrocker.net>
To: IETF DMARC WG <dmarc@ietf.org>
References: <b3ab712a-74b3-d580-65bc-a97bf8c4652d@gmail.com> <611C4FF8-57C8-494A-9C98-EACB3FFD45A1@linkedin.com> <561bd8fd-ee96-a23f-c0a5-9da96e583607@gmail.com> <E88E6515-5046-4C08-B8E5-6A54C73B72AC@linkedin.com> <0d93f07c-824a-7ffc-2ec5-6b216442a456@gmail.com> <2407614A-21F6-403F-9259-92B361380EBB@linkedin.com> <9c0b00d6-8234-0009-97e5-9bbbe89e1c9c@gmail.com> <32A8F41D-978D-46AB-A2C2-741AC20DCEB3@linkedin.com> <9131ae2e-4fa1-90c3-f9ed-912a3fe7ee09@gmail.com> <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <1b0bef4b-61e6-776c-79e8-89631efa8053@dcrocker.net>
Date: Tue, 11 Dec 2018 20:17:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <9e00a59d-33da-33e8-4611-ab2152235106@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/pQpKag3acqIISxb-SOrJ3mHFayI>
Subject: [dmarc-ietf] PSD simplification
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, 12 Dec 2018 04:17:47 -0000

Folks,

Howdy.

This note is the result of some offline discussions, patiently helping 
me to work through the purpose of the kitterman-dmarc-psd.  After some 
false starts, here's where I landed:


I believe the registry created by kitterman-dmarc-psd is not needed. 
More generally I believe the proposal spec can be considerably abbreviated.


     1.  If the registry is to constrain which public suffix operators 
are constrained to assert a default record, then I'll claim that's a 
false sense of security, given the range of unrelated and even more 
serious powers a parent domain can exert over a subordinate one.

     2.  If it is to avoid wasting a DNS a query to a record that won't 
be there, that's false economy.  Most queries to the registry will fail. 
   And most queries to both the From: domain name and its organizational 
domain already fail. The incremental cost of a wasted query to the 
organizational domain's parent is pretty small.

And the cost of creating and running a query-able database that is kept 
current is high and error-prone (as the existing PSL demonstrates.)


So I think that the functional goal of kitterman-dmarc-psd is fully 
satisfied by merely doing a version of the 3A update to DMARC, directing 
the client to query the immediate parent of the organizational domain, 
if the OD has been queried and no DMARC record has been found.

That is, making DMARC have a 3-level lookup sequence rather than two, 
where the additional one is the same as for the organizational domain, 
except one level higher.

Thoughts?

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net