[dmarc-ietf] Comment on draft-ietf-dmarc-psd

[Dave Crocker <[e-mail]>]

Review of:    DMARC (Domain-based Message Authentication, Reporting, and
               Conformance) Extension For PSDs (Public Suffix Domains)
I-D:          draft-ietf-dmarc-psd-06
Reviewer:     D. Crocker
Review Date:  12 August 2019



The draft specification's intent is to address a basic operational 
limitation in the current use of DMARC. There are domains in the 
upper-reaches of the DNS space that are not accessible for obtaining 
organization-wide policy records, but which need to become accessible. 
Per the PSD draft:

> For domains listed in a public suffix list, i.e. TLDs and domains
> that exist between TLDs and organization level domains, policy can
> only be published for the exact domain.  No method is available for
> these domains to express policy or receive feedback reporting for
> sub-domains.



Background
----------

The operational history is that the upper reaches of the Domain Name 
System have been restricted to administration by organizations that all 
strictly served as constrained registries. Their domain names were 
allocated by ICANN or by another public agency (such as a government). 
They all were distinct as organizations registering sub-domain names for 
other, independent organizations.  Unfortunately there is no algorithm 
that can distinguish between these public registries from their 
sub-domains; hence they must be manually determined.  In the DMARC 
specification, the aggregation of these registries is referred to as a 
"public suffix list", after the primary Internet service offering such a 
list.  The term 'public' here is mostly taken to mean that the registry 
for such a domain operates as a public service.(*)

DMARC's use of a public suffix is to permit finding the "organizational 
domain", which is the domain name that is delegated from a public suffix 
registry and is the name highest up a branch while having the same 
administrative authority as the full (DMARC "aligned") domain name being 
evaluated by DMARC. The next-higher domain name above the organizational 
domain -- a public registry -- is under separate operational authority.

DMARC needs to know the organizational domain so that the organizational 
authority can assert a DMARC policy for all subordinate domains, notably 
those that do not publish their own DMARC record and domains that do not 
exist.  This capability overcomes a downgrade attack on DMARC, where an 
organization's intent to have all of its subdomains subject to DMARC 
evaluation can be bypassed by using a name that does not have an 
associated DMARC record.


      The focus on these two terms is important to highlight. They refer
      to the operational role of the domain name.

      A Public Suffix serves as a public registry.

      An Organizational Domain operates as a 'master' authority over a
      branch of related names.


While the popular public suffix listing example is cited, a specific 
public suffix list is not normatively incorporated into the DMARC 
specification:  That is, there is normative use of 'some' public suffix 
list, but no normative details for choosing it.  Determination of what 
is a public suffix and what is not is, therefore, outside the scope of 
the DMARC specification.  This is a very useful separation of functions, 
especially given operational concerns about the status quo for public 
suffix determination.  Decoupling moves those concerns away from DMARC, 
per se.  This both simplifies the DMARC specification and improves its 
stability, since it does not have to change when details of the public 
suffix functionality changes.

However there is now a requirement to extend DMARC's ability to assert 
an organizational policy record to include names in the upper levels of 
the DNS, which have classically been viewed as public suffixes.

Indeed, the draft specification calls them public suffixes.

Historically, domain names listed in these upper levels did not 
participate in the assertion of DMARC policies for their sub-domains. 
Now, some of these domains want to.

Specifically, some upper-level domain names need to be able to publish a 
DMARC record that asserts a policy for all sub-domains under them, in 
particular to cover domain names that do not exist or that have not 
published a DMARC record. This requirement even applies to some 
top-level domains.

That is, names that are typically classed as 'public suffix' names need 
to operate as 'organizational domains' for DMARC.



Draft PSD Specification
-----------------------

The PSD draft seeks to address this requirement.  Within the DMARC 
sandbox, it is important to have a way to communicate a domain owner's 
DMARC policy, for sub-domains that do not exist or do not publish a 
DMARC record directly.

For upper-level domains, the draft does this by introducing an 
additional query, to the domain name that is one level higher than the 
determined organizational domain.  The perspective of the draft is that 
it is adding a query into a portion of the public suffix list.

This approach is problematic in several ways.

It is a substantial increase in DMARC's operational overhead.  It adds a 
query that will often be needed -- especially in the face of limited 
DMARC adoption.  If a domain is not already a 'popular' DMARC reference 
-- that is, frequently encountered by the querying site -- it is likely 
that there will be no DMARC record for any of the three needed queries. 
That means a 50% increase from two (failed) DNS queries to three 
(failed) queries.

By it's nature, this mechanism will succeed for only a tiny percentage 
of domain names that are used.  (Given common locality of reference, a 
particular site might see quite a bit of name re-use, so that the 
statistics for their actual traffic might be quite a bit better than the 
theoretical 50% increase.)  So PSD it will likely provide at best a tiny 
benefit, relative to overall DMARC use.

Note: all receivers must support this feature and incur its relatively 
large overhead, while virtually never seeing the extra query be 
successful.  So the cost/benefit incentives are quite poor for receivers.

 From a design standpoint, the specification also is problematic.  Added 
mechanism is added complexity.  And the reality of Internet standards is 
that the cost of added mechanism is disproportionately large.  Think 
exponential rather than linear, due to the accrued cost of 
implementation, testing and deployment.

Besides adding complexity, it breaks the technical separation between 
DMARC and public suffix, by diving into that space.  Hence the PS in PSD.

Remember that the reason for wanting to query the organizational domain 
is to check for a policy record that applies to all sub-domains.  That 
is, the record being sought is authoritative for the branch below it.

The proposed enhancement seeks to look for a 'more authoritative' domain 
name above the one that has been classed as an organizational domain.



Adjusting Perspective
---------------------

Of the new set of domain names being targeted for publication of a 
covering policy record, there really are two types of administrative 
roles they serve.

One is exactly the same as the classic organizational domain:  A 
top-level domain that is registered for an organization, to be used by 
the domain owner directly for itself. This really is exactly the same as 
DMARC's classic construct of organizational domain.  For example, 
*.example.com and *.example can both be classic (private) organizational 
domains.  It doesn't matter that one might be delegated by a classic 
public registry and the other by ICANN.  The actual use of the allocated 
name is as an organizational domain.

The second use can be called as "association domain".  The containing 
name covers a set of sub-domains referring to member organizations. 
Besides applying to groups that might be obviously classed as 
associations -- such as industry trade groups -- some large 
organizations are operated with enough independence among its 
subordinate departments or subsidiaries to make tight control 
unrealistic.  A salient example of this is a government and its 
'subordinate' departments.

Arguably for DMARC purposes, an association domain can be treated the 
same as an organization domain, since the scope of the domain's 
authority over its sub-domains is an internal matter, to be determined 
by its agreements with association members.

What this means is that the real requirement here is to improve the 
mechanism for identifying the organizational domain, and that 
requirement is outside of DMARC.  This does not reduce the necessity of 
identifying these domains; rather it moves the task to where it belongs: 
This requires modification to the public suffix list operation, possibly 
with a parallel "private TLD" registry.

An added benefit to this alternate view is that it eliminates the 
privacy concern about the draft specification:  only upper-level domains 
operating as organizational domains will be able to publish a 
domain-wide DMARC policy record.  Domains that really are classic public 
suffixes won't be able to.



(Merely for completeness I'll note:  Some upper-level domains have 
ICANN-based restrictions on what records they can publish.  As has been 
discussed in the working group, although obviously essential to resolve, 
this issue is entirely outside direct work on DMARC.)



Summary
-------

    Independent of DMARC, develop a method of identifying the 
upper-level domains that need to be treated as organizational domains. 
The "public suffix" for these domains is whatever portion of the name is 
to the right of this, as usual. (The current draft's Appendix B might 
seem reasonable for this, but note that it formally has nothing to do 
with DMARC, per se, and it probably has some interesting administrative 
challenges.  In any event, it is augmenting the existing Public Suffix 
List rather than DMARC.)

   The modification to DMARC, then, is to allow this 'suffix' part to be 
empty, in order to support top-level domains that operate as 
organizational domains.

   This produces zero change to DMARC's lookup behavior and almost no 
change to its specification.



d/


(*) Public Suffix List <https://publicsuffix.org/>

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net