I am working on more specific language, but here is a statement of the approach that I believe will provide an appropriate solution:
Design Requirements and Implications: 1) DMARCbis must provide protection for PSO-registered organizations, Private Registrar clients, and organizational subunits that wish to be evaluated as if they were a Private Registration client. This feature represents a significant security improvement over RFC 7489 and is the primary incentive for abandoning the PSL. 2) DMARCbis must support PSD policies, including PSDs with variable depth. PSDs that publish DMARC policies can be required and expected to use the “psd=y” term. However, to mitigate the risk of a misconfigured PSD policy, organizations should be encouraged to use the “org=y” term to explicitly identify their top-of-organization domain name. A DMARC policy may contain both “psd=y” and “org=y”, because a single domain may be PSO-registered and also act as a Private Registrar to all of its subdomains. When both exist, the “psd=y” flag takes precedence when walking up the tree, while the “org=y” applies when starting the walk at exact-match. In all other cases, an “org=y” policy will be below any “psd=y” policy, and “org=y” will take precedence during the tree walk upward. 3) DMARCbis must be able to identify “same organization” for relaxed alignment with an accuracy very similar to that of the PSL, albeit with different sources of risk. I assert without proof that most DMARC-participating organizations will have an organization-level policy, as the design of RFC 7489 causes publication of an organizational policy to be natural and desirable. Therefore, in the absence of a policy tagged with either “psd=y” or “org=y”, the topmost DMARC policy can be treated as the organizational domain, without consulting the PSL. If the top-most policy found is actually below the organizational domain, relaxed alignment will be applied on this more restrictive scope. An organization which is unhappy with this result will be incented to publish a DMARC policy at the organizational domain level, so that relaxed alignment will be performed correctly. 4) DMARCbis should implement two tests for non-existence, organizational existence and From domain existence. Organizational existence is satisfied if any resource record is found in the organization’s domain subtree. If a DMARC policy is found anywhere within the organization structure, this also proves organization existence. If the policy search ends with only a “psd=y” policy, then the organization must be tested by doing a DNS query on the organizational domain. A result of NXDOMAIN means that the organization is not registered and the DMARC result is the special-case result of FAIL-UNREGISTERED. The NP clause is redundant when the “psd=y” flag is present, because the NP clause of a "psd=y" policy is only applied to the organizational domain. Relaxed alignment permits a FROM domain to have no presence in DNS. However, a domain owner may publish an NP policy which asserts that the FROM domain will and must exist in DNS. When the NP policy is present on an organization’s DMARC policy record, a DNS lookup is performed on the FROM domain. It it returns NXDOMAIN, then the DMARC result is the special case of FAIL-NONEXISTENT 5) The tree walk must produce the equivalent of a complete walk from the FROM domain to the TLD. A walk upward can end as soon as the first "org=y" or "psd=y" term is found, while a walk down cannot exit early. Therefore, the technical advantage is on the side of a walk up. The Subdomain default policy and the Relaxed Alignment boundary occur at the same point, which is the organizational domain. Therefore these attributes are determined together, on the first tree walk. 6) Determining whether the authenticating domain is in the same organization, including absence of any Private Registrar boundaries, is usually determined with a second tree walk. Sometimes, a domain mismatch can be detected without the cost of a second tree walk. Examples: PSO-registered domain example: "subdomainpath.example.bank" DMARCbis must always be able to find the DMARC policy at example.bank, regardless of name depth, if it exists. DMARCbis must always be able to find the DMARC policy at .Bank if none exists at example.bank Private-registrar domain example: " subdomainpath.MyDomain.Clients.PrivateRegistrar.com" DMARCbis must be able to find the policy at MyDomain if it exists, and should be able to find a lower level policy if the depth is not excessive. Private Registrar clients may provide sufficient reason to use a depth limit slightly greater than 5. Doug Foster >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
