[dmarc-ietf] Summary comments on draft-ietf-dmarc-psd

Dave Crocker <dhc@dcrocker.net> Tue, 10 March 2020 22:16 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 42A3E3A0EFB for <dmarc@ietfa.amsl.com>; Tue, 10 Mar 2020 15:16:49 -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, 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 GnDvaWbNAdjA for <dmarc@ietfa.amsl.com>; Tue, 10 Mar 2020 15:16:47 -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 D10503A0EF1 for <dmarc@ietf.org>; Tue, 10 Mar 2020 15:16:46 -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 02AMIDl1016114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <dmarc@ietf.org>; Tue, 10 Mar 2020 15:18:13 -0700
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
To: IETF DMARC WG <dmarc@ietf.org>
Message-ID: <86865bcb-0b58-f0dc-c0d5-76053ded31e2@dcrocker.net>
Date: Tue, 10 Mar 2020 15:16:41 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
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/th_lPIG2nq0tJU65gqbwpH8Ukio>
Subject: [dmarc-ietf] Summary comments on draft-ietf-dmarc-psd
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: Tue, 10 Mar 2020 22:16:50 -0000

This is offered as summary comments, focusing on some basic concerns, 
rather than providing a detailed review of the specification.

My original comments were posted 12 August 2019:

    https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg



0. DMARC use of Organizational Domain

DMARC specifies use of the Organizational Domain as a fallback for not 
finding a DMARC record at the full domain name under scrutiny.  The need 
for this is to cover slow DMARC adoption among sub-domains and to handle 
queries about non-existent domains.



1. These are not 'public' suffixes (1)

The concept of a 'public' suffix refers to domain names associated with 
registries subject to externally-imposed operational policies.  For want 
of a better term, these operations are regulated.  The domain suffixes 
that PSD attends to are not public registries.

    *  If the company that uses .example.com also gets .example, the 
latter is not a 'public' domain.  It is a private domain, just like 
example.com.  In terms of DMARC, the fact that it is delegated by ICANN 
rather than a 'regular' registry is -- or at least should be -- irrelevant.

    *  If member-based association that uses association.example gets 
.association, the latter is not a public domain.  It's private.

    *  A government-based domain name that want to enforce DMARC onto 
subordinate domain names of subordinate agencies that haven't yet 
adopted it are, of course, pursuing an entirely reasonable goal.  But 
these, too, are not public suffixes and their need is internal to their 
organization.

In every case, these are domains at the top of an administrative 
authority, for all of the subordinate domains.  That's the definition of 
an Organizational Domain.




2. Externalizing internal difficulties

Some organizations have sub-groups to which various administrative 
responsibilities have been delegated.  In general, there can be many 
levels of such delegation.  Not just two.

For the cases the PSD specification is intended to cover,
PSD seeks to adapt to slow DMARC adoption or non-existent domains for 
one of its delegated sub-groups, by looking for an even-higher-level 
encompassing record under a next-level Organizational Domain.  That is, 
PSD is specifying using two different Organizational Domains.  The usual 
one and its parent.

A difficulty within the organization is being externalized to a burden 
for everyone else on the net.



3. DMARC wants the Organizational Domain

The existing DMARC model is a) look under the full domain, and then b) 
look under the Organizational Domain, as a fallback.  My strong 
suggestion is to keep the model as simple as that.

The argument for adding just this one more layer of Organizational 
Domain seems modest, primarily because it is purpose-built to handle a 
new, special case, rather than because it represents a considered, 
general case.




4. DMARC should not specify how to obtain the Organizational Domain.

DMARC needs to say 'give me the organizational domain' or perhaps 'give 
me the dmarc record under the organizational domain' and it needs to 
have nothing to do with the method of satisfying the request.

It's not that the problem being addressed by PSD isn't real.  It's that 
it needs to be viewed more carefully.

The combination of this being a problem /within/ an organization, along 
with the various continuing challenges of the PSL, mean that all 
knowledge of this needs to be kept away from the DMARC spec.




5. There is little engagement with the PSD technical effort

It is easy to see why owners of some domains would want a mechanism like 
PSD.  As noted, they do have a real and significant problem.  So, 
statements of support from such folk merely confirm their need.  (As an 
aside I'll note that historically the IETF hasn't been all that 
interested in simplistic statements of support but, rather, actual 
involvement in the engineering discussion.)

What such statements do /not/ provide is any indication that the broader 
Internet community has an interest in adopting this.

First, where are the statements of actively engaged support from an 
interesting set of organizations on the other side of these queries?  In 
general, there has been a track record of limited adoption for anything 
that changes infrastructure services, in the absence of a very 
widespread perception of need, benefit, and tractable operational cost.

Second, there has been a distinct lack of interest in the working 
group's considering the concerns I've raised.  Not none, just not much. 
And the responses have mostly been to merely reject the concerns, such 
as by asserting that an extra DNS query isn't expensive, ignoring the 
architectural issues.  Forgive my indulging in a small lack of modesty 
in believing that I'm raising concerns that are relatively basic, having 
some merit.




6. The 'experiment' has vague goals and criteria

In spite of having explicit language covering this specification as an 
'experiment' the specification does not give me a clear and concrete 
understanding of exactly what will be evaluated, or how, and what 
constitutes satisfactory accomplishment.




I'm posting this primarily to finish an obligation and place it into the 
working group record, rather than from an expectation that it will be 
acted upon.  Absent any indication of serious interest in serious and 
constructive discussion, I won't be pressing this further, other than 
possibly posting a pointer to it during IETF Last Call, as a formality.


d/



-----------------------------


(1) The draft credits me for the term "public suffix".  So I should 
apologize, since it is now clear to me that these suffixes are very much 
NOT public.  They are private or governmental.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net