I remain concerned about the often-stated position that the DMARC specification is OK if it only produces false PASS in rare cases. False PASS is never OK, and our goal should be to prevent the problem rather than ignore it.
In RFC 7489, PASS is a consolidation of 8 different trust indicators, but they do not all warrant the same level of trust. We have not discussed those differences, so I will restate them here: Authentication Method: DKIM vs SPF. DKIM is a much stronger authentication method than SPF. SPF In a multiple tenant environment, SPF assumes that the hosting service has administrative controls in place to prevent one tenant from impersonating the MAILFROM address of another tenant. Therefore, if the IP address authorized to send for the MAILFROM domain, then the message is authorized. This is a sufficiently weak assumption that some domain owners do not publish SPF policies, because they do not want SPF to authenticate for DMARC. DKIM In a multiple tenant environment, DKIM only assumes that the hosting service provides standard operating system features to keep one tenants private keys protected from use by other tenants Authentication Relationship: nominally Strict vs Relaxed, but actually 4 different types STRICT / EQUAL MATCH: The domain authenticates itself. This is always reliable. PARENT-CHILD: The parent domain validates a message which uses a child domain. This is consistent with the inherent powers associated with being a DNS parent node, and with the inherent powers associated with upper layers of a hierarchical organization. CHILD-PARENT: The child domain validates a message which uses a parent domain. Improper action of this type is expected to bring swift retaliation from the parent, so the likelihood of misuse seems low. I think our collective experience with actual mail data is that nobody tries to impersonate PSDs. SIBLING: One part of an organization validates a message for a domain in a different part of the organization. This is a very weak authentication method and has multiple risks. The primary risks are created by private registries, if the registry boundary is undetected. For the PSL, the threat comes from private registries that are not listed. For the Tree Walk, the threat comes from private registries that are not tagged. The secondary risk comes from assuming strong central control where it may not exist, and where the impersonation may be the result of malware. Universities come to mind because we have discussed how they have distributed control structures. Is it wise for us to assume that a message with MAIL FROM of [email protected] is authorized to send messages with FROM [email protected], or [email protected] can send messages for [email protected]? I don't think so. 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. Doug Foster
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
