Subject: [dmarc-ietf] org domain and dns-perimeter draft

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

Given the renewed discussion about organizational domain and alternative 
boundaries, I'll suggest that this draft from last year might be relevant:

    DNS Perimeter Overlay

    <https://tools.ietf.org/html/draft-dcrocker-dns-perimeter-01>

> Abstract
> 
>    The Domain Name System (DNS) naming syntax provides no meta-data for
>    indicating administrative transitions through the hierarchy.  For
>    example, it does not distinguish the higher-level portions that
>    operate as public registries, versus those that operate as private
>    organizations.  This specification creates a basic overlay mechanism
>    for defining a logical Perimeter between administrative entities
>    through the naming hierarchy.  The mechanism can then be applied for
>    a variety of independent administrative indications.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 18 Nov 2020 15:44:36 -0500

If we're going to refight the DBOUND battle, here's another entry,
which even has running code. I see no reason to think that we are any
more likely to endorse one of these now than we were a few years ago
so I encourage the group to limit the debate to the existing Org/PSL
kludge and a tree walk.

Draft: https://datatracker.ietf.org/doc/draft-levine-dbound-dns/

Code: https://github.com/jrlevine/bound

Abstract

   The organization that manages a subtree in the DNS is often different
   from the one that manages the tree above it.  We describe an
   architecture to publish in the DNS the boundaries between
   organizations that can be adapted to various policy models and can be
   queried with a small number of DNS lookups.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Nov 2020 12:54:59 -0800

> so I encourage the group to limit the debate to the existing Org/PSL

"and a tree walk" is not a minor 'and'.  neither conceptually nor 
operationally.  assurances to the contrary notwithstanding.

d/

---

From: "John R Levine" <[email-masked]>
Date: 18 Nov 2020 16:33:32 -0500

> operationally.  assurances to the contrary notwithstanding.

I didn't say they were equivalent.  But I do think they are the only 
options that are likely to get much interest from the WG.

I think my DBOUND wildcard implementation is wonderful but I don't have 
much hope of persuading the rest of the world.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 19 Nov 2020 13:39:27 +0100

On 18/11/2020 22:33, John R Levine wrote:
> I didn't say they were equivalent.  But I do think they are the only options 
> that are likely to get much interest from the WG.

I don't think tree walk is a viable option, as it distorts semantics.

But then, we don't need alternatives to the PSL.  The whole point is to detach 
the PSL from the base DMARC spec.  Alternatives can be researched afterwards.

> I think my DBOUND wildcard implementation is wonderful but I don't have much 
> hope of persuading the rest of the world.

And you don't need to persuade it before releasing the base DMARC spec.

AIUI, the purpose of the split is to leave that door opened.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Thu, 19 Nov 2020 15:33:48 -0500

On Thu, Nov 19, 2020 at 7:39 AM Alessandro Vesely <[email-masked]> wrote:

> options
Forgive me, but I don't know what you mean by the phrase "distorts
semantics"; can you please help me understand?

As for the viability of a tree walk, it is possible in complex environments
to have something resembling the following:

   - RFC5322.From domain - a.b.foo.com - _dmarc.a.b.foo.com non-existent
   - _dmarc.b.foo.com record exists, p=x, rua=r1
   - _dmarc.foo.com record exists, p=y, rua=r2

(The actual p= and rua= values for these two records are of no consequence;
in this example it is only required that they differ from each other.)

Let's put aside whether or not such a configuration is the ideal way to do
things, because that's outside the scope of the working group; let's
acknowledge that the "Holy Roman Empire" method of management of DNS and
email does exist, and so centralized control of DNS across all
organizations is just not possible.

With the current DMARC specification, the receiver actions for policy
discovery would look first for a policy record at a.b.foo.com, and finding
none, would then look at the organizational domain, foo.com. This would
result in a policy of y being applied to mail from a.b.foo.com, and
aggregate reports going to r2.

Perhaps the people in charge of DNS and email for a.b.foo.com intended for
this to happen; we can't know their intentions without speaking directly
with them (which obviously doesn't scale) but this is what the
configuration would yield.

On the other hand, one might infer from the DNS records that are published
that their intent was for a.b.foo.com to inherit x for the policy and r1 as
the destination for aggregate reports from the b.foo.com record; this would
be an error on their part, because DMARC does not currently support
discovery of the record at _dmarc.b.foo.com in this case. However, it's not
hard to see that this might be what they intended, especially if the
published policy here is p=none; they may be in the "audit" phase of their
DMARC rollout for their portion of foo.com's namespace, wanting reports
sent to a mailbox under their local control, so that they can effect change
quickly to their mailstreams.

The way I see it, we can choose one of three paths here:

   1. Keep things as they are, where if there is no policy published for
   RFC5322.From, the policy is inherited from the org domain, if a policy is
   published there
   2. Change the spec so that the only policy lookup done is for the
   RFC5322.From domain, and if there's no policy there, then DMARC doesn't
   exist for that domain
   3. Change the spec so that policies published between the RFC5322.From
   domain and the organizational domain can be discovered, in order to support
   the most flexibility across organizations.

Option 2 would cause the most pain for the current install base of domain
owners that publish DMARC policies, because even those who understand DMARC
will have to update DNS for domains below the org domain that are used in
RFC5322.From headers. Meanwhile, options 2 and 3 would both require code
changes for domains that do DMARC validation. The larger point, though, is
that there are plausible scenarios that argue for supporting the ability to
publish policies somewhere in the DNS hierarchy between the RFC5322.From
domain and the organizational domain.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*p:* 703.220.4153

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: Fri, 20 Nov 2020 10:31:04 +0100

On 19/11/2020 21:33, Todd Herr wrote:
>>> options that are likely to get much interest from the WG. >>

The current semantics considers an Organizational Domain to be the expression 
of the organization itself, the organization's master domain.  That's quite 
nearly what the PSL strive for.

Tree walk, instead, discards any organizational boundary.

>     - _dmarc.foo.com record exists, p=y, rua=r2
       - _dmarc.com record doesn't exist, for the time being.

> discovery of the record at _dmarc.b.foo.com in this case.

Without asking them directly, we could also infer that folks at b.foo.com are 
sneakily trying to divert feedback traffic.

>     RFC5322.From, the policy is inherited from the org domain, if a policy is

Easiest and safest option.

>     RFC5322.From domain, and if there's no policy there, then DMARC doesn't

SPF experience shows that large domains don't have the ability to maintain a 
script that defines suitable DNS records for all their subdomains.  This would 
force inconsistent usage of '*' domains.  BTW, as of your example, we have:

ale@pcale:~$ dig _dmarc.b.foo.com txt

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> _dmarc.b.foo.com txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44418
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ab33c1fc9c9860b18b1294575fb788126f7a88216eadcab7 (good)
;; QUESTION SECTION:
;_dmarc.b.foo.com.		IN	TXT

;; ANSWER SECTION:
_dmarc.b.foo.com.	600	IN	TXT	"v=spf1 -all"

;; AUTHORITY SECTION:
foo.com.		250	IN	NS	ns2.digimedia.com.
foo.com.		250	IN	NS	ns1.digimedia.com.

;; ADDITIONAL SECTION:
ns1.digimedia.com.	172450	IN	A	23.21.242.88
ns2.digimedia.com.	172450	IN	A	23.21.243.119

>     the most flexibility across organizations.

Besides making a lot of confusion about where policies and feedback addresses 
might come from, this feature inflates DNS queries more than it is desirable. 
If you have From: DoS <[email-masked]. ... x.y.z> you have to look up each 
subdomain in the required order.  (Maybe you can check if z exists, and in case 
if m.n.o. ... x.y.z exists, and so on in a dichotomic anti-DoS tactic.  Hm...)

Best
Ale
--

---

From: "Doug Foster" <[email-masked]>
Date: Tue, 24 Nov 2020 13:17:59 -0500

I am intrigued by Dave's document.   I have not yet read John's.   John
described this topic as a battle, so I wonder if we need a crash course in
the results of those battles before revisiting the topic.

One of the issues that did not seem sufficiently addressed was split-mode
nodes, where some descendants are public suffixes and some are
organizations.    At that point, the plan becomes dependent on organizations
publishing BEGIN records.     Similarly, if we ask PSL's to put a flag into
their DNS entries, we have to assume that some will comply and some will
not, and some will do so in phases.   TThe document did not provide a
mechanism for the evaluator to assess whether data is complete or missing.
I am attempting to fix those concerns.

Nonetheless, these thoughts are an abstraction inspired from Dave's
document.

Note:  I only know how to make this work if we assume a tree walk that goes
downward.

At each public suffix entry in the DNS hierarchy, we check for these flags:
 
Public suffix flag:  This is a PSL entry, it neither sends nor accepts
email.  You must look for an organization start somewhere below this point.

(Optional)  End flag:  There are no public suffixes below this point.  Every
lower entry is an organization start node.   Entries with a public suffix
flag are stating an organization preference or spoofing.

Deployment flag:   All public suffixes below this point have been tagged.   
- Once this flag is detected, if the search finds a node without the PSL
flag, it is an organization, not a public suffix 
- If this flag has not been detected and the search finds a node without the
PSL flag, use the old PSL to find the organization node.

An evaluator can walk down the tree and can always find one of these:
- an Organization entry, 
- an ambiguous ending which triggers the need to consult the old PSL, or 
- an excessive search depth which is handled as no-data-found and possible
malicious intent.

Spoofing assessment:
We cannot prevent people from mimicking a PSL flag, so we just need to limit
the risk.

As the tree is walked downward, the first entry without a PSL flag stops the
search.    The PSL flag should never be checked based on a walk up the tree.
This eliminates the opportunity for mid-tree spoofing.

I see no great risk if an organization wants the top of its DNS structure to
behave like a public suffix, so I don't know that mimicking a public suffix
is a problem.   The only caveat is that we need a maximum depth to limit
malicious DNS structures intended to waste search effort by evaluators.

Doug Foster

-----Original Message-----
From: dmarc [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Wednesday, November 18, 2020 12:55 PM
To: IETF DMARC WG
Subject: [dmarc-ietf] org domain and dns-perimeter draft

    DNS Perimeter Overlay

d/

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