I beleive that we can and should address the Columbia University problem. Here are some thoughts:
Policy Types ------------=--- We have three types of policies: - "p=" policy for a specific domain - "sp=" policy for subdomains that do not enumerate their own - "sp=" policy for non-existent subdomains Deploying a specific "p=" to every node will provide granular control for subdomains that exist, but it does not solve the problem for non-existent subdomains. Non-Existent Domains ------------------------------ In almost every case, the policy for non-existent subdomains should be stricter than the one for existent subdomains, so sharing one policy for both purposes is problematic. I created ticket #83 last night with a proposal to define a policy option for non-existent domains. Roll-up Policy ------------------ When rolling a security policy up from leaf nodes upward toward higher level nodes, the weakest policy is the one that has to forwarded upward, unless there is a mid-tree override mechanism. By allowing a lower-level subtree to apply a different policy than the parent, we allow the stricter policy to flow upward while the weak subtree retains its carve-out exception. If a subtree needs a weak policy and that setting can only be accomplished at the top of the domain, then the entire organizaiton's security is weakened for the sake of the problematic leaf node. This is exactly the situation that causes sp=none to persist indefinitely. Inheritance --------------- For subdomains that actually exist, one has to ask whether it is reasonable to expect an organization to implement a DMARC policy at every node of its domain tree. In the event that a reporting address changes, the organization has a lot of changes needed to propagate that change everywhere. We would benefit from providing an ability to inherit from an upper-level entry using syntax like "inherit=N", where N is an integer number of domain levels. The evaluator determines the values for sp, rua, and ruf at the referenced domain, and uses the sp result for p and sp on the referencing subdomain. Similarly, the rua and ruf values from the referenced domain are used to supply those values if they are not specified on the referencing subdomain DMARC record. Since the flow is only upward, the maximum number of iterations is limited, even if nested inheritance is allowed. However, nested inheritance could be limited to a maximum number or disaloowed completely. This approach allows subtrees to configure different reporting than the top-level of the organization. Inheritance provides a more efficient method of walking up the domain tree, as compared to sequential iteration, for subdomains that actually exist and have an inheritance record defined.. QueryDown ---------------------- Walking down the tree has some possibilities as well. Assume that the top of the organization is located using the PSL, but as in the Columbia University example, the sp policy at that level is not necessarily determinative. A token of the form "querydown=1" instructs the evaluator to accept the sp policy at this level as a candidate policy, but to check the next level down to see if an override applies. If the token is missing or 0, then this record is determinative and the search stops. - If the next level down is the original domain, then of course the process stops because this domain has already been checked for a p policy and been found lacking. - If the next level down produces a DMARC record, the sp at this level becomes the new candidate policy, subject to checking for another querydown token. - If the next level down does not have a DMARC record, the search stops and the last candidate policy is the effective policy. In most cases, this process will end quickly because it will either exhaust the domain string, encounter a missing DMARC record, or encounter a DMARC record with querydown=0 (or missing). If the querydown parameter is larger than one, the evaluator can jump down that many levels, eliminating intermediate ones. Again, if this positions the match at or below the original domain or below, then the search stops and the last candidate policy is applied. Again, a limit on the number of downward iterations would be applicable. If an "inherit=n" token is being used to walk up the tree, then the querydown parameter would be ignored. Hope this helps, Doug Foster ---------------------------------------- From: Joseph Brennan <bren...@columbia.edu> Sent: 11/12/20 9:24 AM To: IETF DMARC WG <dmarc@ietf.org> Subject: Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND On Wed, Nov 11, 2020 at 4:21 PM Dave Crocker <d...@dcrocker.net> 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
