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

[Doug Foster]

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

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

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



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

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

[Dave Crocker]

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

   



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

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