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

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Mar 2020 15:16:41 -0700

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

---

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 11 Mar 2020 00:24:27 GMT

Dave raises some interesting points.

For my part, I am troubled by issues that are created by the DMARC specification itself.    The fallback rule says we jump directly from the domain name to the organization name, which creates the need for a special list to know how to find the organization.   As I think you have discussed, there is no fully acceptable mechanism for publishing the list and keeping implementations of the list current.

If the fallback rule simply told implementations to walk up the domain tree until a policy was found, the need for a special list would go away.

The other need for organization knowledge is the domain alignment rule which allows for sibling relationships between the signing domain and the From domain.   From a technical standpoint, this is unfortunate becomes it complicates implementations with the need to determine the organization.

>From the viewpoint of a receiving system, it is not obvious to me why I should assume that division1.divisonA.example.com should be accepted as having administrative authority to send messages on behalf of divisionB.example.com.  This is an administrative control issue for the sending organization, and the whole point of DMARC was to help sending organizations improve their administrative control over email.  However, it is a trust issue for the receiving organization, and I have no desire to assume every DMARC-participating organization has perfect administrative control.

But I suppose the DMARC train has left the station, even if the deployment process has been slow.

Doug Foster

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 Mar 2020 18:08:35 +0100

Dave and all,

On Tue 10/Mar/2020 23:16:41 +0100 Dave Crocker wrote:
> 
> This is offered as summary comments, focusing on some basic concerns, rather
> than providing a detailed review of the specification.
> 
> 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.

After so many years of SPF, I would call it lazy adoption, not slow.  It is
apparent that domain owners don't want to clutter their DNS zones with tons of
TXT records.

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

Please, let's not speculate on the multifaceted term "public".  For example,
"public school" means something completely different in the US than the UK.
What about "public enemy" in the 1930s and now?  For "public suffix", I propose
we stick to the definition referred by rfc8499.

>    *  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.
> 
> ..association, the latter is not a public domain.  It's private.
> 
> 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.

I agree that the term "organizational domain" should cover an administratively
cohesive unit.  To forge a good definition will be a nice topic to discuss.

IMHO, pushing toward having DMARC distance itself from the PSL is the most
important contribution of this series of posts.  Indeed, since we don't control
how the PSL might evolve, doing so seems to be required.

BTW, the PSL itself has varying interpretations.  For example, publicsuffix2[*]
provides a get_public_suffix() function featuring two optional Boolean
parameters, wildcard and strict, which tweak the semantic quite a bit (well, two).

[*] https://pypi.org/project/publicsuffix2/

> responsibilities have been delegated.  In general, there can be many levels of
> such delegation.  Not just two.
> 
> 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.

Correct.  The existence of often-abused suffixes derives right from their
specialization.  I think we should favor that different suffixes differ.

> A difficulty within the organization is being externalized to a burden for
> everyone else on the net.

The burden of filtering is on "external" mail receivers, obviously.  The same
is true for DMARC and email in general.

> 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.  A very large
organization, such as gov.uk, needs to delegate to many branches, and each
branch uses a number of domain names.  Simply removing gov.uk from the PSL
—that is, considering it a private suffix— would prevent branches from
specifying their own policy.  How would we define a 3rd layer in that case?

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

Fully agreed.  Some kind of statement will have to measure how much the
(current) PSL fits, though.

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

I'd reckon avoiding [email-masked] is every mailbox provider's interest.

Statements by large mailbox provider are welcome!

> understanding of exactly what will be evaluated, or how, and what constitutes
> satisfactory accomplishment.

I'd let Scott illustrate Appendixes A1 and A2.  They look quite clear to me.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Mar 2020 22:00:32 -0400

Comments in-line.

Scott K

>     https://mailarchive.ietf.org/arch/msg/dmarc/ESSp7DJ_Ij0tCzAvJws-b4lLurg

I have certainly reviewed those in detail.

> 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.  This draft 
provides for an equivalent for non-existent organizational domains where 
appropriate.  It also provides for a mechanism to express a different policy 
for non-existent and existent sub-domains.

> 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.  Additionally, the term public suffix as used in this 
document matches current common usage.

In any case, the term public suffix is not baked into the protocol by this 
draft.  If we want a different term if/when we fold this functionality into RFC 
7489bis, we can use it.  It's usage here won't constrain that decision.

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

> new, special case, rather than because it represents a considered,
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.
> 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.
> widespread perception of need, benefit, and tractable operational cost.

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

> in believing that I'm raising concerns that are relatively basic, having

I think you are confusing lack of agreement with lack of interest.  I, for 
one, certainly paid close attention to them, but I remain unconvinced.  I have 
no doubt your perspective is genuinely held and you wouldn't have raised them 
if you didn't believe they had merit, but I don't agree.
> constitutes satisfactory accomplishment.
I won't argue it's clear, because I wouldn't have written it the way I did if 
I didn't think it was.  It apparently seems to be reasonably straightforward 
to others based on WGLC and previous replies to your note.  I'll leave it at 
that.
> possibly posting a pointer to it during IETF Last Call, as a formality.
Fair enough.  I'm replying for essentially the same reasons.  I don't expect 
you to agree, but I don't want it said no one paid attention.  I certainly 
did.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Mar 2020 20:36:53 -0700

As a participant:

> for non-existent and existent sub-domains.

Since we're mentioning a tree walk here, I believe we are ripe for a
reopening of that debate.  It's my understanding that the DNS community has
softened its position on the impact of such a mechanism as a way of finding
nodes of interest.  I could be wrong, but there's one way to find out.
Perhaps that is the case, and that a tree walk renders many of these issues
moot.

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

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

> > constitutes satisfactory accomplishment.

As we're now under AD Evaluation and there's still an IETF Last Call to go,
this is still on the table for being fixed if it appears by further
reviewers to be unclear.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Sun, 15 Mar 2020 05:49:26 -0700

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

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

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:
>> reopening of that debate.

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

Consider: From [email-masked]...bogus.bogus.example.com

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

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

>>     > widespread perception of need, benefit, and tractable
>>     operational cost..
>>
>> 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

bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 15 Mar 2020 19:56:35 +0100

Hi,
I changed the subject as I only reply to that part of the original post.

On Sun 15/Mar/2020 13:49:26 +0100 Dave Crocker wrote:
>>> externally-imposed operational policies.  For want of a better
>>> term, these operations are regulated.  The domain suffixes that PSD
>> ... For "public suffix", I propose we stick to the definition
>> referred by rfc8499.
> 
> OK, let's do that:
> 
> 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".

I agree that that definition is not all that well reasoned.  Are there
private registries?  Rfc8499 also talks about "public DNS", where the
adjective bears a slightly different meaning.

We need to define Operational Domain.  Debating about the semantic
meaning of "public" doesn't seem to help much.

>>> 3. DMARC wants the Organizational Domain The existing DMARC model
>>> is a) look under the full domain, and then b) look under the
> 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.

It would certainly be more general if there was a way to specify it
independently of the public suffix list.  Let me quote another
paragraph of yours, which describes the problem well:

> [...]

> 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 non-general way to define a 3rd level is to have the top suffix be
"public" (in the sense of the PSL) and then have the organization
participate in PSD DMARC.  According to the experiment, that allows
subordinate companies or departments to publish their own policy, and
still have an top-level policy as a default and for non-existent domains.

I agree that having to call "pubic" an organization just because it is
so wide as to require three levels doesn't seem to be semantically
consistent.  The mechanism works, though, and covers known use cases.

The general way would allows example.com to behave like .example
without disturbing the registries and the PSL.  However, to work out
what mechanisms are needed is daunting.  Any suggestion on how to
shape that?  To me, it seems it would likely require more radical
changes to DMARC than the low hanging fruit at hand.  In addition, we
would then have the problem of how to define "private" the relevant
TLDs, despite their ICANN agreement.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Mar 2020 16:29:41 -0700

> Consider: From [email-masked]...bogus.bogus.example.com
Yeah, I'm familiar with the nature of the attack.   But based on what
amounts to the hallway track, it feels like the perspective of the DNS
community these days is that the currently deployed DNS infrastructure
could easily deal with such an attack, to at least the extent that it's not
a blocker for something potentially useful like resolving the
Organizational Domain problem for DMARC.

Tim might be able to elucidate here.

> And yet both DMARC and PSD have text tied to the term and its function.
My point here is that I believe we've already agreed that you're correct,
and this separation should happen, but there's no apparent urgency that
MUST be done before the PSD experiment can proceed.  Indeed, I'm fairly
certain the amount of code change in my own implementation in order to be
compliant with such a change in the specification is around zero.  The
audience for the experiment, by my read, also agrees, so they understand
the need, but this won't change the experiment either.

> 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...
>
The issue PSD is attempting to address is mail sent as a nonexistent
subdomain.  For example, irs.gov doesn't have a subdomain called
auditors.irs.gov, so irrespective of any irs.gov DMARC policy, I could send
email as [email-masked] without limitation.  The goal here is to come
up with a mechanism to prevent this.  Obviously the maintainers of irs.gov
can't anticipate all possible nonexistent names that might be used, so
either something like PSD is needed, or some kind of wildcarding mechanism
is needed by which the domain owner can block any name they're not actually
using.  What such mechanism could be developed?  Don't wildcard TXT
records, for example, have some other side effects?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 18 Mar 2020 21:17:03 -0400

In article <CAL0qLwZwz+R52ydEgn7Qpu8t4=[email-masked]> you write:
>could easily deal with such an attack, ...

The DNS crowd is finally admitting to themselves that Sturgeon's Law
applies to the DNS, too, and a little more crud will be lost in the
large amoung ot noise.  I gather than people are implementing RFC 8020
which makes this attack less effective.

>email as [email-masked] without limitation. ...

I have less sympathy for that argument.  I do a hard reject of any
mail with a nonexistent bounce address which I don't think is unusual.

PSD as I understand it is to address the same issue the organizational
domain does, but a level up, in a group of organizations that have
some administrative connection.  The issue is people who publish A and
MX records without covering DMARC records.  They're not supposed to do
that but they do, and PSD is one way of figuring out who needs to fix what.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Mar 2020 12:41:03 +0100

On Thu 19/Mar/2020 02:17:03 +0100 John Levine wrote:
> 
> I do a hard reject of any mail with a nonexistent bounce address which I
> don't think is unusual.

How about nonexistent From: address domain?  Rejecting these is less usual (IME
because of [email-masked]) although DMARC shifted the accent here.

> that but they do, and PSD is one way of figuring out who needs to fix what.

It also covers From: [email-masked].  That way we can reject on
nonexistent From: addresses for a subset of PSDs.

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 20 Mar 2020 15:38:26 -0400

On Wed, Mar 18, 2020 at 9:17 PM John Levine <[email-masked]> wrote:

> In article <CAL0qLwZwz+R52ydEgn7Qpu8t4=
> [email-masked]> you write:
+1 to what John says here.   I mean, I was still seeing a non-trivial
number of A6 queries.

tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 21 Mar 2020 18:31:14 -0700

> that but they do, and PSD is one way of figuring out who needs to fix what.

Sorry, yes, my example was faulty.

-MSK