There is one widely-used private registry which is not in the PSL. For security purposes, I think the name should remain out of the public record, but I suspect that it is the one responsible for the attack mentioned by Michael Hammer. 1) DMARC policies for Private Registry Clients (Registrar not listed in PSL) Under RFC 7489, if you are a client of a private registry that is not in the PSL, and then you create a DMARC policy with relaxed alignment, any client of the private registry can impersonate the domain name associated with your DMARC policy. So the only safe moves are no policy or strict alignment.
Under the Tree Walk, that particular problem is solved. If you create a DMARC policy, and the private registrar does not have a policy, then your policy will be considered the organization domain and other sibling domains will be perceived as having no policy. 2) DMARC policies for Private Registry Organizational Domains Under RFC 7489, if a private registrar is not listed in the PSL, and then it creates an organizational domain policy with relaxed authentication, any domain name within the private registrar's tree can impersonate any other name in the tree. Clients have limited defenses against this problem. They can protect specific names by publishing strict-alignment policies on specific domain names, but they cannot defend all possible names that might be attacked. Under the Tree Walk, if the private registrar creates a DMARC policy for his organization, and does not publish an explicitly-tagged PSD=Y policy for the client registration domain, then the registry's organizational record will apply to all clients. Again, this would allow any domain name to impersonate any other domain name. The defense against this problem is for the client to publish a DMARC policy with the PSD=N tag, to prevent the registrar's policy from being selected. Observations Based on this comparison, the Tree Walk attack surface appears to be smaller, but in an ecosystem with both algorithms in use, the net effect seems to be to increase the options available to an attacker. Evaluators need DMARC PAAS to be reliable, so these scenarios that allow false PASS are concerning. (It seems unwise for an evaluator to assume that all private registries and their client have implemented all necessary tags to prevent a false positive.) To defend against the problem globally, evaluators should accept sibling authentication by exception, essentially as a form of whitelisting for trusted sources, rather than by default for all sources. RFC 7489 has vulnerabilities because it failed to consider all the implications of private registries and an imperfect PSL. Are we obligated to perpetuate vulnerabilities for the sake of upward compatibility? Doug On Mon, Jul 18, 2022 at 5:57 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On July 18, 2022 9:21:33 AM UTC, Alessandro Vesely <ves...@tana.it> wrote: > >On Sat 16/Jul/2022 16:20:09 +0200 Douglas Foster wrote: > >> > >> My proposal: > >> Sibling authentication should be disabled by default, even for policies > that specify relaxed authentication. Those organizations that want > sibling authentication should explicitly request it using a tag (to be > defined) on the Organizational Domain policy. If the tag is not present, > relaxed authentication enables only exact, parent-child, and child-parent > relationships. > > > > > >I'd be in favor of introducing a third mode, adkim=n, say, for > not-so-relaxed. > > > >Since it'd be a new feature, it cannot be the default. Those who don't > recognize it should ignore it and assume adkim=r. > > > > What issue does this address that isn't addressed by using psd=n? > > Scott K > > _______________________________________________ > 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
