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