I am pretty content with your text. I am still see a security vulnerability without something like the OrgsBelow token. DMARC is all about verified data. Since the tree walk can be compromised by omitting psd=n, the selected organization domain needs a verification method. I don't understand why you think it is already handled by the existing text.
On Sun, Apr 24, 2022 at 11:57 PM Scott Kitterman <[email protected]> wrote: > On Sunday, April 24, 2022 9:16:04 PM EDT Douglas Foster wrote: > > 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. > > I think you have a reasonable issue in here, but this is not all security > considerations. I also think the point that it's independent of how the > organizational domain is determined is appropriate. > > My assessment is that this is an issue that it is appropriate to document > in > this text: > > > > 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. > > I think it needs some work though and can be substantially shorter. The > same > potential exists for both public and private registrations. > > Org domain too low in the tree causing an incorrect rejection isn't a > security > issue though, that's a protocol problem. > > How about something like this: > > 9.7 Determination of the Organizational Domain For Relaxed Alignment > > DMARC evaluation for relaxed alignment is highly sensitive to errors in > the > determination of the organizational domain if the RFC5322.From domain does > not > have a published policy. If an incorrectly selected organizational domain > is > a parent of the correct organizational domain, then relaxed alignment > could > potentially allow a malicious sender to obtain DMARC PASS. This potential > exists for both the legacy [RFC 7489] and current [Section 4.8] methods > for > determining the organizational domain. > > This issue is completely avoided by use of strict alignment and publishing > DMARC records for all domains/sub-domains used as RFC5322.From domain in > an > organization's email. > > For cases where strict alignment is not appropriate, this issue can be > mitigated by periodically checking the DMARC records, if any, of PSDs > above > the organization's domains in the DNS tree and (for legacy [RFC 7489] > checking > that appropriate PSL entries remain present). If a PSD domain publishes a > DMARC record without the appropriate psd=y tag, organizational domain > owners > can add psd=n to their organizational domain's DMARC record so that the > PSD > record will not be incorrectly evaluated to be the organizational domain. > > > I think that captures in a more compact form the issue you are (I think > rightly) concerned about as well as appropriate advice to protocol users > on > how to avoid or mitigate the issue. > > Scott K > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
