Subject: [dmarc-ietf] On splitting documents

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Nov 2020 17:06:10 -0800

Not to lob monkey wrenches around, but at one point we were talking about
putting the determination of the Organizational Domain into a separate
document.  I think it was Dave who suggested it.  This would allow for
simple augmentation of DMARC implementations when something better than the
current PSL-type mechanisms came along, without having to spin up a full
"Updates" pass over DMARCbis itself.

I ask because this came up during IESG Evaluation of a document from
another working group[1] recently, where that working group was doing
something that mandated a DMARC "pass".  Since DMARC is currently
Informational (and not an IETF product in any case), it might be beneficial
for DMARCbis (the core of it) and things like the OD algorithm's evolution
to progress, and be reference-able, independently.

[1] See Barry's DISCUSS position on draft-ietf-acme-email-smime.

-MSK, participating

---

From: Dotzero <[email-masked]>
Date: Tue, 10 Nov 2020 20:48:22 -0500

> "Updates" pass over DMARCbis itself.

This actually makes sense because there are other potential documents/uses
besides DMARC that could reference PSL-type mechanisms.

> [1] See Barry's DISCUSS position on draft-ietf-acme-email-smime.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2020 21:24:43 -0500

>besides DMARC that could reference PSL-type mechanisms.

Remember that this is a well-known swamp of despair. We had a whole
DBOUND working group that failed to define a PSL-like thing.

I am inclined to do nothing at this point, and if someday we actually
succeed in doing DBOUND, whateever we define can update 7489bis to say
to use it.

R's,
John
 
PS: https://github.com/jrlevine/bound is ready when you are

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 05:43:03 -0800

> succeed in doing DBOUND, whateever we define can update 7489bis to say

There is a difference between "splitting out existing text, on topic x" 
from "revise text on topic x".

The current suggestion is to take the org domain text that is current in 
the DMARC spec and to split it out, so that the core DMARC spec does not 
contain specification language about organization domain, other than 
"find the organizational domain".

That's a documentation hack, making later changes easier, rather than a 
current attempt to devise better OD specification.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Douglas E. Foster" <[email-masked]>
Date: Wed, 11 Nov 2020 09:00:27 -0500

Can we eliminate the PSL problem simply by adding some DNS queries?

Isn't there a maximum depth to the PSL, so that the evaluator can simply walk up the top N levels of the domain tree to find either an organizational DMARC entry with sp= or a PSD DMARC entry with sp=?   It looks like currently, n=4, because the published suffixes appear to extend to 3 levels.

DF

----------------------------------------

From: Dave Crocker <[email-masked]>
Sent: 11/11/20 8:43 AM
To: John Levine <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [dmarc-ietf] On splitting documents and DBOUND

d/

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 11:50:19 -0500

On Wed, 11 Nov 2020, Dave Crocker wrote:
> There is a difference between "splitting out existing text, on topic x" from 
> "revise text on topic x".
>
> The current suggestion is to take the org domain text that is current in the 
> DMARC spec and to split it out, so that the core DMARC spec does not contain 
> specification language about organization domain, other than "find the 
> organizational domain".

The current text says (in many more words), take a list of public 
suffixes, find the longest match, and the Org domain is one below that 
match.  If we consider the Org domain to be found via a list of public 
registration points, that won't change.  We might change where the list 
comes from, and perhaps some hackery like my DNS wildcards to make the 
implementation of the search faster.  This tells me the separate document 
is on the order of one sentence saying where the list is.

The other alternative is forget public suffixes and walk up the tree until 
you find a _dmarc record or you hit the root.  That has a lot of 
advantages: it's easy to describe, everyone gets the same answer, and 
Scott automatically gets his superdomain check.  I believe the main 
argument against it is that the DNS crowd has has been allergic to tree 
walks, but the cost of potentially malicious tree walk names like
a.b.c ...  x.y.z.example.com is not a big deal any more since RFC 8020.

If you mean that we would punt a potential change this large into a 
different document, that seems like a stretch.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 08:55:07 -0800

On 11/11/2020 8:50 AM, John R Levine wrote:
> suffixes, 
...
> different document, that seems like a stretch.

It's not.

    The entire topic is a mess.  In pretty much every possible way.

    Even reliance on the construct of 'public suffix' is problematic. 
(cf, .google, etc.)

So, DMARC should punt the entire topic.  It should have some text, along 
the lines of:

    Find the Organizational Domain.  The means of finding the 
Organizational Domain are outside the scope of this specification.

Full Stop.

d/

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 11:58:46 -0500

On Wed, 11 Nov 2020, Dave Crocker wrote:
> So, DMARC should punt the entire topic.  It should have some text, along the 
> lines of:
>
>   Find the Organizational Domain.  The means of finding the Organizational 
> Domain are outside the scope of this specification.

Except that if we do a tree walk, I don't think we'd call that the 
Organizational Domain any more.

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Nov 2020 08:58:59 -0800

> different document, that seems like a stretch.

The proposal is, I think, to change the main document to leave a pointer,
and the pointer can be changed much more easily than the actual method.  So
the new DMARC document would say: "Determine the Organizational Domain.
The legacy way to do this can be found in [other-RFC], but other better
methods are anticipated."  Then when something better than PSL (maybe a
tree walk, maybe something else) comes along, the IETF publishes that
specification and DMARC implementations and operators switch to that
method.  The base document doesn't need to change at all.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Nov 2020 09:01:39 -0800

On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster <fosterd=
[email-masked]> wrote:

> Isn't there a maximum depth to the PSL, so that the evaluator can simply
> walk up the top N levels of the domain tree to find either an
> organizational DMARC entry with sp= or a PSD DMARC entry with sp=?   It
> looks like currently, n=4, because the published suffixes appear to extend
> to 3 levels.
>

That's been proposed, and I think it's a future topic for this WG.  (A
ticket might be open about it already.)

As John just said in another thread, the DNS crowd has been largely
allergic to the notion of a tree walk in the past, but the last time this
was given serious consideration was when DKIM was young (2007) and it might
be ripe for revisiting now.  It certainly would make our lives simpler.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 09:35:29 -0800

...

It's not.

Full Stop.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 09:38:41 -0800

On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote:
> The proposal is, I think, to change the main document to leave a 
> pointer, and the pointer can be changed much more easily than the actual 
> method.  So the new DMARC document would say: "Determine the 
> Organizational Domain.  The legacy way to do this can be found in 
> [other-RFC], but other better methods are anticipated."

wfm.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 09:37:31 -0800

> Organizational Domain any more.

What would you call it?

d/

---

From: "John Levine" <[email-masked]>
Date: 11 Nov 2020 13:18:37 -0500

>> Organizational Domain any more.

"Parent default" or something like that. There's no claim that it is
or isn't in the same organization, just that it's a parent name of the
target name.

For Scott's _dmarc.BANK. thing it would deliberately *not* be the same organization.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 10:24:43 -0800

On 11/11/2020 10:18 AM, John Levine wrote:
> For Scott's _dmarc.BANK. thing it would deliberately*not*  be the same organization.

Where is such generality discussed in DMARC?  I don't recall seeing it.

DMARC has had a consistent construct, which is 'the domain name that is 
at the top of the organization's administrative hierarchy".  Hence, 
Organizational Domain.  Nothing in the term requires that it be up the 
'current' domain name chain.
]
"Parent default" is an example of a more generic term that actually has 
the same meaning, but less intuitive.  For one thing, it's likely to be 
quite a bit higher than the parent domain name.

d/

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 11 Nov 2020 13:31:37 -0500

I was trying to address the tree walk objections and denial-of-service objections by starting at the upper end of the tree, so that an evaluator cannot be tricked into trying 100 possibilities for a single email message.

An additional protection would be to specify a few TLDs, (particularly .COM.  .EDU, .NET, and .ORG) which will never be used for PSD DMARC entries, so an implementer MUST NOT look for a DMARC entry there.    Those TLDS would be the ones at most risk of performance problems if saturated by a DMARC TXT lookups during tree walk.   A short don’t-look-here list is much more sustainable than what we have right now.

DF

From: Murray S. Kucherawy [mailto:[email-masked]] 
Sent: Wednesday, November 11, 2020 12:02 PM
To: Doug Foster
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] On splitting documents and DBOUND

On Wed, Nov 11, 2020 at 6:01 AM Douglas E. Foster <fosterd=[email-masked]> wrote:

That's been proposed, and I think it's a future topic for this WG.  (A ticket might be open about it already.)

As John just said in another thread, the DNS crowd has been largely allergic to the notion of a tree walk in the past, but the last time this was given serious consideration was when DKIM was young (2007) and it might be ripe for revisiting now.  It certainly would make our lives simpler.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Wed, 11 Nov 2020 10:53:56 -0800

I believe the core of this is referenced in
https://trac.ietf.org/trac/dmarc/ticket/68 and can be discussed in detail
when the chairs or relevant editors open that ticket.

The further discussion seems to be if "org domain" (or whatever new name
its given) definition and discovery mechanism should live in a separate
I-D, and DMARC should simply reference this for discovery purposes.

If we believe a new document is in order, we'll need an editor. I believe
Scott Kitterman expressed interest in this previously, and it's also a
natural extension of some of the work he's already done with PSD.

Is anyone interested in volunteering to be an editor for this draft and
bringing an -00 to the group?

Seth, as co-Chair

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Seth Blank <[email-masked]>
Date: Wed, 11 Nov 2020 10:57:57 -0800

The ticket in question is https://trac.ietf.org/trac/dmarc/ticket/68

(as an individual)

If we go the tree walk route, I believe the realistic hack needed will
simply be to add a max depth for the walk. The longest PSL suffix is only 4
labels deep, so a max depth of 10 seems generous without opening crazy
abuse vectors through maliciously long and well constructed domain names.

(as Chair)

let's hold on ticket 68 until we come to consensus on whether this work
should be done in a separate document, and if so, who the editors are.

Seth

On Wed, Nov 11, 2020 at 10:31 AM Doug Foster <fosterd=
[email-masked]> wrote:

> I was trying to address the tree walk objections and denial-of-service
> objections by starting at the upper end of the tree, so that an evaluator
> cannot be tricked into trying 100 possibilities for a single email message.
>
>
>
> An additional protection would be to specify a few TLDs, (particularly
> .COM.  .EDU, .NET, and .ORG) which will never be used for PSD DMARC
> entries, so an implementer MUST NOT look for a DMARC entry there.    Those
> TLDS would be the ones at most risk of performance problems if saturated by
> a DMARC TXT lookups during tree walk.   A short don’t-look-here list is
> much more sustainable than what we have right now.
>
>
>
> DF
>
>
>
> *From:* Murray S. Kucherawy [mailto:[email-masked]]
> *Sent:* Wednesday, November 11, 2020 12:02 PM
> *To:* Doug Foster
> *Cc:* IETF DMARC WG
> *Subject:* Re: [dmarc-ietf] On splitting documents and DBOUND
>
>
>

--

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 14:24:30 -0500

> Where is such generality discussed in DMARC?  I don't recall seeing it.

That's draft-ietf-dmarc-psd

> DMARC has had a consistent construct, which is 'the domain name that is at 
> the top of the organization's administrative hierarchy".  Hence, 

I think a lot of people would be quite surprised to hear that the Org 
domain might not be a parent of the original domain.  I sure would.

I realize you could fake it with CNAMEs but that's different.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Nov 2020 13:20:54 -0800

On 11/11/2020 11:24 AM, John R Levine wrote:
>> DMARC has had a consistent construct, which is 'the domain name that 
>> is at the top of the organization's administrative hierarchy".  Hence, 

Just to invoke a bit of ancient history, here, you are saying that if 
there was the domain name:

    engineering.sun.com

people would be surprised that the organization domain is

    oracle.com

?

d/

---

From: "John R Levine" <[email-masked]>
Date: 11 Nov 2020 16:30:40 -0500

On Wed, 11 Nov 2020, Dave Crocker wrote:
> Just to invoke a bit of ancient history, here, you are saying that if there 
> was the domain name:
>
>   engineering.sun.com
>

In a DMARC context, that would be quite surprising.  I am aware that 
Oracke bought Sun quite a while ago.

Regards,

---

From: Seth Blank <[email-masked]>
Date: Wed, 11 Nov 2020 13:33:47 -0800

This use case is actually the intention of (the extremely poorly worded)
https://trac.ietf.org/trac/dmarc/ticket/59

To the earlier conversation, this is all simplified dramatically if we
define organizational domain (or whatever it's renamed) discovery in a
separate I-D that DMARC just inherits...

--

---

From: "Doug Foster" <[email-masked]>
Date: Wed, 11 Nov 2020 16:42:15 -0500

It appears that these tickets are all related to this issue:

#24         objection to maintaining registry for all participating public suffixes

#34         Define the term "Public Suffix" referencing RFC8499

#46         Separate org domain definition from core DMARC

#58         Add third lookup for public suffix domains

#59         Add third lookup for organizational home

#68         Do away with the PSL and Org Domain entirely; just walk the tree

From: dmarc [mailto:[email-masked]] On Behalf Of Seth Blank
Sent: Wednesday, November 11, 2020 4:34 PM
To: IETF DMARC WG
Cc: John Levine; Dave Crocker
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

This use case is actually the intention of (the extremely poorly worded) https://trac.ietf.org/trac/dmarc/ticket/59

To the earlier conversation, this is all simplified dramatically if we define organizational domain (or whatever it's renamed) discovery in a separate I-D that DMARC just inherits...

Regards,

 

-- 

Seth Blank | VP, Standards and New Technologies

e: [email-masked]

p: 415.273.8818 

  <https://lh5.googleusercontent.com/_vs__6iRjfmT2Ae5LLNBb8nEopl2M5Tl5QlpS6LS0Lh0vv4TYnZu-Mff2kDFOqe0LhbnSXprAx4yoaTvq_Tc_7n1b8yzGIqoxuhedthDxYQansg8ChT2x5EcZV3rjz19-Dx9rESL> 

This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 Nov 2020 10:40:17 +0100

On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote:
>> The proposal is, I think, to change the main document to leave a pointer, and 
>> the pointer can be changed much more easily than the actual method.  So the 
>> new DMARC document would say: "Determine the Organizational Domain.  The 
>> legacy way to do this can be found in [other-RFC], but other better methods 
>> are anticipated."
> 
> wfm.

+1,  Perhaps we could say "Organizational Domain or a domain thence delegated" 
rather than anticipating unspecified methods.  I think DMARC will require the 
(implied) consent of the interested domain for the foreseeable future.

Best
Ale
--

---

From: Joseph Brennan <[email-masked]>
Date: Thu, 12 Nov 2020 09:23:36 -0500

> people would be surprised that the organization domain is
As another case, would people be surprised that email for the medical
center cumc.columbia.edu is a separate system managed by a separate IT
group from columbia.edu, and that any authentication for one should not be
applied to the other?  I don't think this is unique in large decentralized
universities. The real email world is a complicated place.

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology

---

From: [email-masked]
Date: Thu, 12 Nov 2020 09:49:17 +0100

Hi,

> separate I-D that DMARC just inherits...

Let me point out, though, that sending reports to "organizational
domain" or to "ancestor domain" have different privacy implications.
Which is an argument for defining at least the semantics (and name) of
that domain in the main document.

Cheers,
BC

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2020 11:30:54 -0500

>universities. The real email world is a complicated place.

Good point, and those aren't boundaries that the PSL et al will show.
On the other hand, if you don't want your nominal parent organization
stealing your reports, you can fix that by publishing your own dmarc
record regardless of how we find the org domain.

I asked in DNSOP about tree walks and my take on the response is that
they are OK, perhaps with some advice about how to limit the effect of
long malicious domain names. The CAA record has required a tree walk
since 2013 and the sky hasn't fallen in.

I guess if we're planning to consider a tree walk, it could make sense
to put the org domain stuff in a separate rather short draft.

>>     oracle.com

_dmarc.sun.com. CNAME _dmarc.oracle.com.

Since nothing else is going to be at the _dmarc label, CNAMEs work fine for
cross-tree references.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 2020 08:42:36 -0800

On 11/11/2020 8:58 AM, Murray S. Kucherawy wrote:
> So the new DMARC document would say: "Determine the Organizational 
> Domain.  The legacy way to do this can be found in [other-RFC], but 
> other better methods are anticipated."  Then when something better
> than PSL (maybe a tree walk, maybe something else) comes along, the
> IETF publishes that specification and DMARC implementations and
> operators switch to that method.  The base document doesn't need to
> change at all.

...
> _dmarc.sun.com. CNAME _dmarc.oracle.com.

Tree-walking is unacceptable.  Tree-walking is now acceptable.

Use CNAMES.  Don't use CNAMES.

The issue is not whether a bit of mechanism might work, but that this
realm of activity is both complicated and has a history of controversy,
as well as a history in the PSL case of not working all that well.

All of which should strongly encourage isolating this topic from DMARC
as much as possible.  Make sure that changes to this do not require
changing the core DMARC spec.

Murray's proffered text does this nicely.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 Nov 2020 17:44:57 +0100

On Thu 12/Nov/2020 10:40:17 +0100 Alessandro Vesely wrote:
>>> the new DMARC document would say: "Determine the Organizational Domain.  The 

Oops, s/interested/concerned/

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 12 Nov 2020 13:20:54 -0600

> record regardless of how we find the org domain.

Assuming this is obvious - it's also a challenge for sp.  It would be nice to get to the point that we could publish more than sp=none at our organizational domain.  Without tree walking, or some other ability to define sp for 3rd-level domains (such as the one that is the parent of our high throughput compute cluster of 4th level domain named machines that send email - shocker, I know), we'll never achieve any meaningful org-level sp due to the complexity of our organization.

If tree walking is a thing that comes to fruition, what does it mean for a domain to be an organizational domain (in reference to the idea that the DMARC spec will just point to another doc to determine the org domain)?  Aren't all parent domains org domains of their children?  Or is there something special about the "top" org domain that I'm not understanding?

Jesse
UW-Madison

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2020 16:23:22 -0500

In article <[email-masked]> you write:
>If tree walking is a thing that comes to fruition, what does it mean for a domain to be an organizational
>domain (in reference to the idea that the DMARC spec will just point to another doc to determine the org
>domain)?  Aren't all parent domains org domains of their children?  Or is there something special about
>the "top" org domain that I'm not understanding?

If we switch to a tree walk I would expect that rather than a formal
org domain we'd call it parent default or something like that, meaning
the next name up the tree that has a DMARC record.

The semantics are definitely not the same. You now can put a DMARC
record on a name below the org domain to shadow a subtree, but I don't
think that is a problem that needs to be solved.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 2020 13:31:25 -0800

On 11/12/2020 1:23 PM, John Levine wrote:
> record on a name below the org domain to shadow a subtree,

that's why the group should first focus on the semantics it 
wants/doesn't want, independent of how the semantics are achieved.  The 
statement of what is wanted should be administrative/authority language, 
not technical language.

d/

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 12 Nov 2020 16:47:22 -0600

On 11/12/20 3:23 PM, John Levine wrote:
> You now can put a DMARC

I'm confused by this statement.  Are you saying that you can "now" do subtree shadowing with sp?  as in the following language is being changed "now"?

"Note that "sp" will be ignored for DMARC records published on subdomains of Organizational Domains due to the effect of the DMARC policy discovery mechanism described in Section 6.6.3."

Or that you meant to say "not" instead of "now" - which is more accurate to current state, I think.

I would assert that for "sp" to be realistically achievable (i.e. the policy coverage for the non-existant and long tail of domain/host names that *shouldn't* be sending unauthenticated email) for a complex organization this is a problem that needs to be solved.  

To further clarify the use case for walking the tree: it allows us to put sp=reject on the org domain (backstopping the problem) and contain legacy environments to solve through reconfiguration/attrition by setting sp=none on the applicable 3rd/4th-level domains.

Jesse

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 12 Nov 2020 15:06:01 -0800

On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson <jesse.thompson=
[email-masked]> wrote:

> I'm confused by this statement.  Are you saying that you can "now" do
> subtree shadowing with sp?  as in the following language is being changed
> "now"?
>

I think that John was referring the potential future state where tree-walks
were being done, but even then I don't think it would work quite that
easily. A record at "a.b.example" would not shadow "x.y.a.b.example" if "x"
or "y" chose to express some policy.

--Kurt

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2020 20:26:33 -0500

In article <[email-masked]> you write:
>I'm confused by this statement.  Are you saying that you can "now" do subtree shadowing with sp?  as in
>the following language is being changed "now"?

Poor choice of words.  "now" -> "if we switch to a tree walk"

R's,
John

---

From: Dotzero <[email-masked]>
Date: Thu, 12 Nov 2020 21:12:52 -0500

>> people would be surprised that the organization domain is
This just isn't that interesting. I would expect (hope?) that Oracle has
enough of a clue to publish records for all it's domains. In my previous
work incarnation we did that for roughly 6,000 domains. We also automated
generating DKIM keys and signing of emails as well as SPF records. My point
is that we are straying from interoperability into the realm of telling
people how to do their implementations. Either they know how to do these
things or they need to outsource it.

It's one thing to to come up with something for subdomains. It's quite
another to try and associate random domains (names) with each other.

> group from columbia.edu, and that any authentication for one should not
> be applied to the other?  I don't think this is unique in large
> decentralized universities. The real email world is a complicated place.
>
>
The simple solution is for  cumc.columbia.eduto publish its own record.
Done.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Nov 2020 18:22:57 -0800

On 11/12/2020 6:12 PM, Dotzero wrote:
> 
>         engineering.sun.com <http://engineering.sun.com>
> 
>         oracle.com <http://oracle.com>
> 
> 
> enough of a clue to publish records for all it's domains. 
...
> another to try and associate random domains (names) with each other.
...> The simple solution is for cumc.columbia.edu
> <http://cumc.columbia.edu>to publish its own record. Done.

+10

This goes to the heart of a very basic challenge, when producing 
standards:  try to solve a narrow, clear, entirely pragmatic and 
immediate issue, versus try to provide a more general solution that 
covers appealing issues which might not have immediate need (or that can 
be satisfied with approaches that have less appeal, in terms of 
engineering aesthetics.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 13 Nov 2020 13:24:58 +0100

On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote:
> that's why the group should first focus on the semantics it wants/doesn't want, 
> independent of how the semantics are achieved.  The statement of what is wanted 
> should be administrative/authority language, not technical language.

Agreed.  And I don't think that a tree walk would match DMARC semantics.

AIUI, the Organizational Domain must be a domain recognized by all "subdomains" 
as authoritative on policies.

Of course, if every organization had the ability to generate DNS records for 
each domain, there would've been no need to use the PSL.  SPF experience taught 
that even "smart" organizations may lack the ability to do so.  Hence, the 
Organizational Domain must be such that its admins are entitled to generate 
those records if they wanted to.

Best
Ale
--

---

From: Joseph Brennan <[email-masked]>
Date: Fri, 13 Nov 2020 09:46:23 -0500

> The simple solution is for  cumc.columbia.eduto publish its own record.

I don't think I have the right to force the owner of another domain to
publish dmarc. The owner of the other domain may want to allow users in
their domain to contribute to lists and groups without having their
messages rejected, or mangled by well-intentioned workarounds. This is not
simple. This is a real-world case with the domains ending columbia.edu.

---

From: Dotzero <[email-masked]>
Date: Fri, 13 Nov 2020 10:03:35 -0500

> simple. This is a real-world case with the domains ending columbia.edu.

If CUMC publishes a DMARC record for cumc.columbia.edu, how is it forcing
another domain to do anything? As far as "owner of a domain", If Columbia
University registered the domain columbia.edu, then CUMC is using the
subdomain because Columbia University is allowing it to, presumably through
some sort of written agreement. A technical standards body cannot address
business and contractual arrangement in the manner you appear to be asking.
If Columbia University stopped delegating the subdomain cumc.columbia.edu,
would you turn to the IETF for redress?

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Nov 2020 07:17:06 -0800

On 11/13/2020 6:46 AM, Joseph Brennan wrote:
>     The simple solution is for cumc.columbia.edu
> messages rejected, or mangled by well-intentioned workarounds. This is 
> not simple. This is a real-world case with the domains ending 
> columbia.edu <http://columbia.edu>.

I'm not sure how 'forcing' is involved here, but let's make sure we have 
the same foundation for discussion:

A domain name falls under an administrative authority.  Names above or 
below this domain name might fall under the same, or a different, authority.

An administrative authority has the responsibility for setting policies 
for the domains over which it has authority.

The discussion, here, concerns finding a domain that is the 'top' of an 
administrative authority hierarchy, in order to discern a possible, 
default dmarc record.

While there has sometimes been discussion about whether that default in 
fact can override a specific domain's DMARC record's attributes, I 
believe the accepted view is that it is applied only in the absence of a 
specific domain's dmarc record, rather than being applied to selectively 
modify one.

An administrative authority might set a strict default, such as 
d=reject.  Any subordinate domain, within that authority, can override 
this by merely publishing its own record with a different set of 
parameters, such as d=none.

d/

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 13 Nov 2020 10:52:14 -0600

On 11/12/20 5:06 PM, Kurt Andersen (b) wrote:
> On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson <jesse.thompson=[email-masked] <mailto:[email-masked]>> wrote:
> 
> I think that John was referring the potential future state where tree-walks were being done, but even then I don't think it would work quite that easily. A record at "a.b.example" would not shadow "x.y.a.b.example" if "x" or "y" chose to express some policy.

Yes, that makes sense for a defined policy to override any inherited subdomain policy. 

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 13 Nov 2020 11:09:27 -0600

On 11/13/20 9:03 AM, [email-masked] wrote:
> 
> 
> On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>             As another case, would people be surprised that email for the medical center cumc.columbia.edu <http://cumc.columbia.edu> is a separate system managed by a separate IT group from columbia.edu <http://columbia.edu>, and that any authentication for one should not be applied to the other?  I don't think this is unique in large decentralized universities. The real email world is a complicated place.
> 
> 
>         The simple solution is for  cumc.columbia.edu <http://cumc.columbia.edu>to publish its own record. Done.
> 
>         Michael Hammer
> 
> 
>     I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain may want to allow users in their domain to contribute to lists and groups without having their messages rejected, or mangled by well-intentioned workarounds. This is not simple. This is a real-world case with the domains ending columbia.edu <http://columbia.edu>. 
> 
> 
> If CUMC publishes a DMARC record for cumc.columbia.edu <http://cumc.columbia.edu>, how is it forcing another domain to do anything? As far as "owner of a domain", If Columbia University registered the domain columbia.edu <http://columbia.edu>, then CUMC is using the subdomain because Columbia University is allowing it to, presumably through some sort of written agreement. A technical standards body cannot address business and contractual arrangement in the manner you appear to be asking. If Columbia University stopped delegating the subdomain cumc.columbia.edu <http://cumc.columbia.edu>, would you turn to the IETF for redress?  

You can't think of universities as single entities with central management authority.  For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it for campus-wide email.

Yes, 3rd level domains should be encouraged to publish DMARC records for their domains to reflect how they are being used, and putting p=none not a big ask of them.  

The departmental IT who understand DMARC immediately ask: "How do I publish a subdomain policy?  Oh, I can't?  Well, you better not ever change sp=none at the org domain."

Jesse

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Nov 2020 09:25:10 -0800

> You can't think of universities as single entities with central management authority.  For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it…

This highlights that the example that was provided was of a university 
that might be asserting 'global' policy under its domain that isn't 
really valid.

That is, the problem with a component group's being affected by a 
higher-level domain's default record is, really, a problem that is 
internal to the organization, not one that should entail accommodation 
by, and the considerable costs of, a public standard.

d/

---

From: "Douglas E. Foster" <[email-masked]>
Date: Fri, 13 Nov 2020 13:31:36 -0500

I beleive that we can and should address the Columbia University problem.  Here are some thoughts:

Policy Types
------------=---
We have three types of policies:

- "p=" policy for a specific domain
- "sp=" policy for subdomains that do not enumerate their own
- "sp=" policy for non-existent subdomains

Deploying a specific "p=" to every node will provide granular control for subdomains that exist, but it does not solve the problem for non-existent subdomains.   

Non-Existent Domains
------------------------------
In almost every case, the policy for non-existent subdomains should be stricter than the one for existent subdomains, so sharing one policy for both purposes is problematic.   I created ticket #83 last night with a proposal to define a policy option for non-existent domains.

Roll-up Policy
------------------
When rolling a security policy up from leaf nodes upward toward higher level nodes, the weakest policy is the one that has to forwarded upward, unless there is a mid-tree override mechanism.  By allowing a lower-level subtree to apply a different policy than the parent, we allow the stricter policy to flow upward while the weak subtree retains its carve-out exception.

If a subtree needs a weak policy and that setting can only be accomplished at the top of the domain, then the entire organizaiton's security is weakened for the sake of the problematic leaf node.   This is exactly the situation that causes sp=none to persist indefinitely.

Inheritance
---------------
For subdomains that actually exist, one has to ask whether it is reasonable to expect an organization to implement a DMARC policy at every node of its domain tree.   In the event that a reporting address changes, the organization has a lot of changes needed to propagate that change everywhere.     We would benefit from providing an ability to inherit from an upper-level entry using syntax like "inherit=N", where N is an integer number of domain levels.    The evaluator determines the values for sp, rua, and ruf at the referenced domain, and uses the sp result for p and sp on the referencing subdomain.   Similarly, the rua and ruf values from the referenced domain are used to supply those values if they are not specified on the referencing subdomain DMARC record.   Since the flow is only upward, the maximum number of iterations is limited, even if nested inheritance is allowed.   However, nested inheritance could be limited to a maximum number or disaloowed completely.  This approach allows subtrees to configure different reporting than the top-level of the organization.  

Inheritance provides a more efficient method of walking up the domain tree, as compared to sequential iteration, for subdomains that actually exist and have an inheritance record defined..

QueryDown
----------------------
Walking down the tree has some possibilities as well.    

Assume that the top of the organization is located using the PSL, but as in the Columbia University example, the sp policy at that level is not necessarily determinative.    A  token of the form "querydown=1" instructs the evaluator to accept the sp policy at this level as a candidate policy, but to check the next level down to see if an override applies.   If the token is missing or 0, then this record is determinative and the search stops.  

- If the next level down is the original domain, then of course the process stops because this domain has already been checked for a p policy and been found lacking.
- If the next level down produces a DMARC record, the sp at this level becomes the new candidate policy, subject to checking for another querydown token.   
- If the next level down does not have a DMARC record, the search stops and the last candidate policy is the effective policy.   
In most cases, this process will end quickly because it will either exhaust the domain string, encounter a missing DMARC record, or encounter a DMARC record with querydown=0 (or missing).

If the querydown parameter is larger than one, the evaluator can jump down that many levels, eliminating intermediate ones.   Again, if this positions the match at or below the original domain or below, then the search stops and the last candidate policy is applied.

Again, a limit on the number of downward iterations would be applicable.   If an "inherit=n" token is being used to walk up the  tree, then the querydown parameter would be ignored.

Hope this helps,

Doug Foster

From: Joseph Brennan <[email-masked]>
Sent: 11/12/20 9:24 AM
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

engineering.sun.com

oracle.com

As another case, would people be surprised that email for the medical center cumc.columbia.edu is a separate system managed by a separate IT group from columbia.edu, and that any authentication for one should not be applied to the other?  I don't think this is unique in large decentralized universities. The real email world is a complicated place.

--

Joseph Brennan

---

From: "John Levine" <[email-masked]>
Date: 13 Nov 2020 13:52:39 -0500

In article <[email-masked]> you write:
>You can't think of universities as single entities with central management authority.  For the longest time our CS department owned
>wisc.edu and central IT had to ask them for permission to use it for campus-wide email.

I believe you, and I am quite aware that UW is not the only university
with a governance model based on that of the Holy Roman Empire. (I
went to Yale which was like that, too.)

On the other hand, whether or not we like it, the DNS is a tree, and if an
organization's DNS structure doesn't match their management structure, there
is no way to tell from the outside and it's up tp them to sort it out.

R's,
John