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 menace, was On splitting documents and DBOUND

[John Levine]

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

[Kurt Andersen (b)]

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

[Jesse Thompson]

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

[Dave Crocker]

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

[John Levine]

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

[Jesse Thompson]

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 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 menace, was On splitting documents and DBOUND

[John Levine]

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

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

[dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting 
& Conformance WG of the IETF.

Title   : DMARC Aggregate Reporting
Author  : Alex Brotman
Filename: draft-ietf-dmarc-aggregate-reporting-00.txt
Pages   : 14
Date: 2020-11-12

Abstract:
   DMARC allows for domain holders to request aggregate reports from
   receivers.  This report is an XML document, and contains extensible
   elements that allow for other types of data to be specified later.
   The aggregate reports can be submitted to the domain holder's
   specified destination as supported by the receiver.

   This document (along with others) obsoletes RFC7489.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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