I have attempted to capture the security-related content of recent discussions:
Security Considerations Determination of the Organizational Domain DMARC evaluation is highly sensitive to errors in the determination of the organizational domain, as the organizational domain is used for the default policy (when the RFC5322.From domain does not have a published policy) and for determining relaxed alignment. If an incorrectly selected organizational domain is actually a parent of the correct organizational domain, then relaxed alignment will allow a malicious sender to obtain DMARC PASS while impersonating either the parent domain or sibling domains. If an incorrectly selected organizational domain is actually a child of the correct organizational domain, then relaxed alignment will produce an incorrect DMARC FAIL when the message is actually authorized by either the correct organizational domain or siblings of the incorrectly chosen domain. When the RFC5322.From domain does not have a policy record, the organizational domain policy is needed to demonstrate DMARC participation and to provide the default policy. In this case, when an incorrect organizational domain is selected, and it does not contain a DMARC record, then the domain will be treated as not participating in DMARC and the domain owner will not receive reports. If the incorrectly selected domain does have a DMARC policy, the applied policy may be different from the domain owner’s intended policy, and reporting will go to whatever destination is specified by that policy. A DNS path may contain a private registration, where a PSO-registered domain owner makes subtrees of his domain available to independent organizations. This behavior complicates DMARC organizational determination. Clients of the private registration will have two organizational domains in its DNS tree, one at the boundary between the private registration client and its private registrar, and another between the private registrar and its PSO. If a private registry is unknown or undetected during organizational domain selection, then the registrar organizational domain may be incorrectly selected as the client’s organizational domain, allowing the client to obtain DMARC PASS while impersonating the parent domain or sibling domains. Reliance on an externally-authored public suffix list, as specified in RFC7489, creates stability problems for domain owners and evaluators. An organization may have their DMARC configuration fully deployed and successfully tested, then suddenly develop unexplained and difficult to detect problems if the PSL used by evaluators adds an entry which fragments the domain’s intended organizational boundaries for email. Even if the domain owner manages to detect the problem, getting it corrected may be difficult or impossible. Since every evaluator operates on an independent copy of one or another PSL list, updated at intervals determined by the evaluator, the domain owner has no certainty about when or if a correction will be replicated to all evaluators. Domain owners can minimize the need for determination of an organizational domain by publishing a DMARC record for each RFC5322.From domain, and applying a DKIM signature which provides strict alignment. When this practice is followed, the organizational domain is only referenced when a non-mail subdomain is impersonated by a malicious actor. This configuration allows the SP clause on all policies to be confidently set to REJECT.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
