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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
