Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John Levine]

In article <903acb7d-847e-c87c-f21b-dcfa698bf...@wisc.edu> 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

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Douglas E. Foster]

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 
Sent: 11/12/20 9:24 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On 
splitting documents and DBOUND

On Wed, Nov 11, 2020 at 4:21 PM 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

people would be surprised that the organization domain is

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/13/2020 9:09 AM, Jesse Thompson wrote:

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.



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/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Jesse Thompson]

On 11/13/20 9:03 AM, dotz...@gmail.com wrote:
> 
> 
> On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan  > wrote:
> 
> 
> 
> 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.
> 
> 
> The simple solution is for  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 
> . 
> 
> 
> 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?  

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

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/13/2020 6:46 AM, Joseph Brennan wrote:

The simple solution is for 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 .



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/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dotzero]

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan  wrote:

>
>
>>> 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.
>>>
>>>
>> The simple solution is for  cumc.columbia.eduto 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.
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Joseph Brennan]

>
>> 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.
>>
>>
> The simple solution is for  cumc.columbia.eduto 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.

-- 
Joseph Brennan
Lead, Email and Systems Applications
Columbia University Information Technology
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/12/2020 6:12 PM, Dotzero wrote:


engineering.sun.com 

people would be surprised that the organization domain is

oracle.com 


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. 

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

...> The simple solution is for 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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dotzero]

On Thu, Nov 12, 2020 at 9:24 AM Joseph Brennan  wrote:

>
>
> On Wed, Nov 11, 2020 at 4:21 PM 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
>>
>> people would be surprised that the organization domain is
>>
>> oracle.com
>
>
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.

>
>>
>>
> 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.
>
>
The simple solution is for  cumc.columbia.eduto publish its own record.
Done.

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Alessandro Vesely]

On Thu 12/Nov/2020 10:40:17 +0100 Alessandro Vesely wrote:

On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote:

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.



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



Oops, s/interested/concerned/






















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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

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.




On 11/12/2020 8:30 AM, John Levine wrote:

I asked in DNSOP about tree walks and my take on the response is
that

...

_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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[devel2020]

Hi,

Le 11/11/2020 à 22:33, Seth Blank a écrit :
> 
> 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...

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

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Joseph Brennan]

On Wed, Nov 11, 2020 at 4:21 PM 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
>
> people would be surprised that the organization domain is
>
> 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
Lead, Email and Systems Applications
Columbia University Information Technology
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Alessandro Vesely]

On Wed 11/Nov/2020 18:38:41 +0100 Dave Crocker wrote:

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.



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







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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Doug Foster]

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:dmarc-boun...@ietf.org] 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...

 

 

On Wed, Nov 11, 2020 at 1:30 PM John R Levine  wrote:

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
>
> people would be surprised that the organization domain is
>
>   oracle.com

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

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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




 

-- 

Seth Blank | VP, Standards and New Technologies

e: s...@valimail.com

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.

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Seth Blank]

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


On Wed, Nov 11, 2020 at 1:30 PM John R Levine  wrote:

> 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
> >
> > people would be surprised that the organization domain is
> >
> >   oracle.com
>
> In a DMARC context, that would be quite surprising.  I am aware that
> Oracke bought Sun quite a while ago.
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John R Levine]

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

people would be surprised that the organization domain is

  oracle.com


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


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

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, 
Organizational Domain.  Nothing in the term requires that it be up the 
'current' domain name chain.


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.



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/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John R Levine]

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


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, 
Organizational Domain.  Nothing in the term requires that it be up the 
'current' domain name chain.


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/11/2020 8:50 AM, John R Levine wrote:
The current text says (in many more words), take a list of public 
suffixes, 

...
If you mean that we would punt a potential change this large into a 
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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Seth Blank]

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

On Wed, Nov 11, 2020 at 10:25 AM Dave Crocker  wrote:

> On 11/11/2020 10:18 AM, John Levine wrote:
> > "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.
>
>
> 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/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* s...@valimail.com
*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.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/11/2020 10:18 AM, John Levine wrote:

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



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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John Levine]

In article <03758d8d-a4d7-3f9d-bc0c-3ee404fc5...@dcrocker.net> you write:
>On 11/11/2020 8:58 AM, John R Levine wrote:
>> Except that if we do a tree walk, I don't think we'd call that the 
>> Organizational Domain any more.
>
>What would you call it?

"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

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/11/2020 8:58 AM, John R Levine wrote:
Except that if we do a tree walk, I don't think we'd call that the 
Organizational Domain any more.



What would you call it?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

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/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Murray S. Kucherawy]

On Wed, Nov 11, 2020 at 8:52 AM John R Levine  wrote:

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

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John R Levine]

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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[Dave Crocker]

On 11/11/2020 8:50 AM, John R Levine wrote:
The current text says (in many more words), take a list of public 
suffixes, 

...
If you mean that we would punt a potential change this large into a 
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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

[John R Levine]

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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

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