Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On 11/12/20 5:06 PM, Kurt Andersen (b) wrote: > On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson > mailto:40wisc@dmarc.ietf.org>> > wrote: > > On 11/12/20 3:23 PM, John Levine wrote: > > 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. > > 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. Yes, that makes sense for a defined policy to override any inherited subdomain policy. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote: On 11/12/2020 1:23 PM, John Levine wrote: 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, 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 -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
In article <4266a992-7064-d8cd-660b-a3d1d4098...@wisc.edu> you write: >On 11/12/20 3:23 PM, John Levine wrote: >> 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. > >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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson wrote: > On 11/12/20 3:23 PM, John Levine wrote: > > 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. > > 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On 11/12/20 3:23 PM, John Levine wrote: > 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On 11/12/2020 1:23 PM, John Levine wrote: 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, 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/ -- 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 menace, was On splitting documents and DBOUND
In article <5bc82960-70a4-3ce2-4e3d-a39dd9743...@wisc.edu> 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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
On 11/12/20 10:30 AM, John Levine wrote: > In article > you > write: >> 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. > > 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. 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 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND
In article you write: >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. 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. By the way: >> engineering.sun.com >> 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. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
