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
