On 3/11/2020 10:08 AM, Alessandro Vesely wrote:
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.
... For "public suffix", I propose we stick to the definition referred by rfc8499.


OK, let's do that:

     "Public suffix: "A domain that is controlled by a public registry."


I gave three examples of types of domains, like the owner of example.com getting .example.  In each of those 3 cases, these domain names are not controlled by a public registry.  So they are not "public suffix domains".



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.
Having three levels instead of two sounds quite general.


That's nice.  And there is a common computer science view that it can be.  But in this case it isn't true.  Rather, it is a very specialized, purpose-built addendum.  There is nothing general about it at all.



On 3/11/2020 7:00 PM, Scott Kitterman wrote:
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.

It also short circuits the need for a tree walk up to the organizational domain. I think it's also relevant to note that it only addresses queries about non-existent domains below the organizational domain level.


Oh? Perhaps I've mis-remembered or misread my review of the text, but it also covers existing domains that do not have a dmarc record.



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.

That may be true as you have defined terms above, but it's not accurate relative to the current RFC 7489 definition, which is the relevant definition for this document.


Which definition are you referring to?  The one cited in RFC 8499, referenced above? Or the one in  RFC 7489 (Section 3.2) which simply says "a list of DNS domain names reserved for registrations"?

I don't really know what 'reserved for registrations" means, but it does not seem to cover the domain names of interest to this draft.


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.

Given the RFC 7489 definitions that are relevant for this draft, that's not correct. PSD is addressing non-organizational domains based on the current definitions.


Apparently the nature of the 'internal' issue I mean wasn't clear.  I'll try to clarify:

The organization that controls this bit of hierarchy controls the domain name the PSD draft is seeking to identify and use.  It also controls the one below it that is otherwise viewed as the organizational domain.  For some organizations, there will be other administrative boundaries, below this, for subordinate companies or departments, or the like. For large, complex organizations, there can be an extensive administrative hierarchy and it might be reflected in a large, complex domain name hierarchy.

The organization has two internal problems here.  One is that the top of the organizational hierarchy is not getting identified properly through whatever 'public suffix' list it is based on. The other is that it has inadequate control over the domains that /are/ getting identified.  If it had adequate control, those subordinate domain names would have DMARC records.


The burden for dealing with these failures is being placed on receivers, outside of the organization.


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.

I don't think it just seems that way. No one has ever claimed that this PSD is generally appropriate for all domains. It's not. I translate your comment as 'because it is not useful for everyone, we shouldn't standardize it'. I don't think that's a reasonable approach. The IETF publishes documents all the time that have less than 100% applicability. That said, the applicability constraint for PSD is related to policy publishers. It is a generally useful addition for all receivers that check DMARC policy.


First, yes, Internet standards are typically expected to scale.  And they typically seek widespread adoption.


For PSD, please consider who has to implement this, for it to be useful.  Try describing this in some detail, both for domain owners and filtering receivers.


The latter is the more interesting set, since they need added code and execution.


To be useful, a mechanism like this needs very widespread adoption.


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.

This is unrelated to PSD. Your original objection was that PSD should not be published because of this unrelated issue. That did not generate (in my judgement) significant support withing the working group. It's presence in any discussion about PSD is a red herring.


Please explain with some substance.  That is, what is the basis for your conclusion?



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.

I don't think that accurately characterizes the situation for PSD.

That's nice.  Please point to the record of active engagement by both domain owners and those who must implement and run filtering receivers, for this mechanism to be effective.



On 3/11/2020 8:36 PM, Murray S. Kucherawy wrote:
Since we're mentioning a tree walk here, I believe we are ripe for a reopening of that debate.


That's a shame. Besides created additional general cost, it creates an attack vector.


Consider: From f...@bogus.bogus.bogus.bogus.bogus...bogus.bogus.example.com


    > 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.
    >


I suspect the name used derives from the name of the resource to which DMARC attached itself early on, namely the Public Suffix List.  Debating its name is probably out of scope here.


It's not, because the term facilitates a basic misunderstanding about the nature of the domain names involved here.  That's why I am raising a concern about the term's use.



And as Alessandro pointed out, the PSL was made for a different purpose and DMARC simply decide to use it to meet its own goals, which in turn supports DMARC distancing itself a bit.

I believe where this is leading, though, is toward the notion that the use of the PSL should be considered external to DMARC.  I don't think anyone has disagreed with that assertion.


And yet both DMARC and PSD have text tied to the term and its function.



    > 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.


Can you expand on how you see abuse of non-existent domains to be an exploitation of an internal problem? Specifically, what's the internal problem being exploited?


I apologize for not being more clear about what I meant.  I hope that the above effort elaborate on this suffices. Basically it concerns an organization's inability to get its subordinates to publish DMARC records and problems with PSLs that lead to identifying the wrong domain as an OD.  Or somesuch...



    > 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..

    I don't think that accurately characterizes the situation for PSD.


I think there's some validity here at least in the claim that the purported interest has not made itself both visible and enthusiastic.  Such dearth absolutely does not rise to the level of supporting something on the standards track, to be sure, but that wasn't the goal here either.


Heh.  An IETF-approved 'experiment' is not a casual activity. A lack of a substantial and wide base of support normally has been significant, even for an IETF-track experimental RFC.


d/

--

Dave Crocker

Brandenburg InternetWorking

bbiw.net

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to