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

[Dave Crocker <[e-mail]>]

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 [e-mail]...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