Threat risk: I totally agree the ORG begins with the first label that is not considered to be a PSD, but at least I want to know if that decision is based on contractual obligations from ICANN/IANA or only a business decision by an entity with a very different legal status, compared to the other. And here a DNS based solution would need to be able to transport that information. So, a rectification that DMARC shall only consider the PUBLIC part of the PSL would be enough and easier for most entities.
Complexity: I believe they all are in the same SCOPE as the requirement in all cases is to derive the ORG Domain from any given Domain, because that is essentially the boundary between them, if a PSD for it’s own want to enforce a policy to all it’s ORGs then I would put that under OUT-OF-SCOPE of the DMARC standard, as there are other way’s to enforce the existence of DNS records for a Domain, especially in such a case, because it shall be part of the ORG domain ownership contract, it’s a business decision for a PSD to have this, so let them solve that on the business level. We should not try to solve issues that are not really existing in the first place, or at least not by methods that are introducing new problems. Multiple Policies: I also support “multiple” policies, perhaps I’m stricter in thinking 2 are enough. Because if the ORG is big, a part of that ORG can publish the policy on the 5322.From Domain, and if there is no policy on that level a receiver will check the ORGs policy. No “real” Tree-Walk needed, as the PSL allows a fast method to determine the ORG-Doman and we end up in 2 requests. It's hard for me right now to come up with a sensible reason why I would want to have policies on every level in the DNS, especially below an ORG-domain, as nobody outside of that ORG-domain knows what structure is behind these sub-labels. 5322.From: test@a.b.c.d.example<mailto:test@a.b.c.d.example> -> first look for _dmarc.a.b.c.d.example, if NXDOMAIN lookup _dmarc.d.example, if NXDOMAIN -> no policy I don’t understand why I should also look for _dmarc.b.c.d.example and _dmarc.c.d.example, especially in the context of a very large ORG the responsible entity at a.b.c.d.example is fine with his “local” policy and most likely he has no control over b.c.d.example or higher up the tree, and for the case that he have to send via test@d.example<mailto:test@d.example> then the ORG decided already that they want to have control over every mail stream anyway and therefore have a central entity to control this behavior as well. Von: dmarc <dmarc-boun...@ietf.org> Im Auftrag von Douglas Foster Gesendet: Freitag, 5. November 2021 02:11 An: IETF DMARC WG <dmarc@ietf.org> Betreff: Re: [dmarc-ietf] Organizational Alignment Options I need some clarification. Threat risk --------------- You confirmed that the PSL has many potential uses, which confirmed my suspicions. But your conclusions are different. I have been working from the assumption that "PSL=TRUE" is equivalent to "DENY=(feature1, feature2, feature3, etc). I don't see any benefit to an attacker from disabling an Internet feature on his own domain name. - For email, PSL=TRUE means we are denying that this name can be used for DMARC alignment (or any other email purpose.) This increases the likelihood that email will be rejected. - For XSS, PSL=TRUE means we are denying that this name can be used for website alignment. This increases the likelihood that web requests will be blocked as dangerous. - For certificates, PSL=TRUE means we are denying that this name can be used to issue certificates. This increases the likelihood that fraudulent certificates will be blocked, rather than warning the user and allowing him to proceed. The organization always begins at the first segment down the tree which is not a PSL. So it is not a meaningful statement to ask whether two PSLs belong to the same organization. Complexity --------------- You said that a single PSL=TRUE is all that we need. I infer that all of these features are likely to have different scope, which is why some people want onto the publicsuffix.org<http://publicsuffix.org> list even though we don't want them listed for DMARC purposes. To implement multiple scopes, you need a scope selector that can produce multiple results. So I need help understanding why PSL=TRUE would be preferable to DENY=<featurelist>. Multiple Policies ---------------------- I support multiple DMARC policies because I believe it will increase the likelihood that some portion of the organization will feel free to publish p=reject and/or sp=reject, even if the organization-level policy is trapped at p=none, sp=none. The value of multiple policy layers increases with the complexity of the organization. As discussed in this forum, the decision-making and control structure of universities can be complex, so multiple policies allows an implementation which reflects that complexity. The tree walk stops when a policy is found. Given the apparently flat nature of most email addresses, and the other complexities of email filtering, I don't see that DNS lookups are a significant design consideration. Doug Foster On Thu, Nov 4, 2021 at 9:19 AM Tobias Herkula <tobias.herk...@1und1.de<mailto:tobias.herk...@1und1.de>> wrote: As an entity you want to be on the PSL to declare an organizational boundary, and usage is now for Cookies, Certificates, Domain Reputation and most likely a longer list of more obscure individual use cases. So most of the time a DNS-RR on a DNS label that states “I’m a PSL” is the use-case that would be needed. The Problem that comes with a simple DNS-RR is, that it’s not possible anymore to discern between a PRIVATE decision to be a PSL and a PUBLIC (ICANN/IANA contract obligation) decision to be a PSL. And that would make it much harder to tackle malicious intent. For example: _psl.com<http://psl.com>. IN TXT “true” == This is fine, and therefore for any first DNS label below “.com.” it would be clear to others that there is an organizational boundary between “example.com<http://example.com>” and “domain.com<http://domain.com>”. But what happens if we suddenly encounter: _psl.example.com<http://psl.example.com>. IN TXT “true” == This is not fine as there is no way to know if “example.com<http://example.com>” belongs to the same legal entity as “.com”. The publicsuffic.org<http://publicsuffic.org> list provides a way to transport Registry policies about what DNS labels can be registered in flat format, if that needs to move to the DNS we would need a BI-directional solution similar to DNSSEC to make it “impossible” to fake such records. Why? Especially for Email, and that is what DMARC cares for, a Malicious Actor could use a single domain and generate a PSL DNS-RR and then he can use every subdomain of this domain to spam around with a different SPF/DKIM/DMARC setting, and only manual intervention can group all these mails together by the real org-domain (responsible entity). Could someone explain why wee need a complex policy discovery algorithm? As from my perspective there are 2 places I would look for a DMARC policy right now, thats the 5322.From Domain at-hand and the org-domain of the 5322.From domain and for this, with the help of the PSL, that would be 2 DNS requests, do I miss a very important use case for DMARC that is not solved by these 2 querys? Von: dmarc <dmarc-boun...@ietf.org<mailto:dmarc-boun...@ietf.org>> Im Auftrag von Douglas Foster Gesendet: Donnerstag, 4. November 2021 11:54 An: Alessandro Vesely <ves...@tana.it<mailto:ves...@tana.it>> Cc: IETF DMARC WG <dmarc@ietf.org<mailto:dmarc@ietf.org>> Betreff: Re: [dmarc-ietf] Organizational Alignment Options It would be helpful to understand why people want to climb into the publicsuffix.org<http://publicsuffix.org> list. My guess: An ISP, such as "ISP.TLD" allows customers to create websites under their parent. They need to be able to indicate that website JohnSmith.ISP.TLD is independent of website IvanWatson.ISP.TLD, and therefore cross-site scripting defenses should treat them as two organizations rather than one. This scenario needs a flag that says "No alignment for XSS purposes", and the set of names that need that flag may be very different from the set of names that need a DMARC non-alignment flag. So a set of feature-specific DNS flags will indeed be a better long-term design than a simple "I'm a PSL" flag. I can't answer whether PSLs will cooperate by publishing DNS entries. My original suggestion was to specify the flag syntax in the RFC, so that deployment negotiations can begin, while recommending that implementers use both. For the same reason that I did not see a threat risk, I would place greater trust in the DNS entry when it is present, so I would check DNS first. But I would also check the publicsuffix.org<http://publicsuffix.org> list to handle the problem of DNS non-participation. Can someone explain the private/public distinction in the PSL list? What does the distinction mean as it relates to the four email-related attributes that I have listed? Doug On Thu, Nov 4, 2021 at 4:34 AM Alessandro Vesely <ves...@tana.it<mailto:ves...@tana.it>> wrote: On Thu 04/Nov/2021 04:09:37 +0100 Douglas Foster wrote: > Ale asks: > >> Hm... but PSDs don't seem to gain any extras by letting receivers know >> they're >> a PSD, do they? > > I think they do. They get the benefits of name protection which DMARC > previously afforded only to organizational domains and subdomains, which I > would expect them to consider very valuable. While the > publicsuffix.org<http://publicsuffix.org> > <http://publicsuffix.org> provides some protection, I would think they should > prefer transferring control of their status from the volunteers to themselves. > > "I am a PSD means" four things: > > 1. "If you see a message with an SMTP address that uses my PSD name, it is > fraudulent and should be blocked." > > 2. "If you see a message with a FROM header that uses my PSD name, it is > fraudulent and should be blocked." > > 3. "If you see a DKIM signature that uses my PSD name, it will not verify > because the public key will be missing, but it is not merely unverified > material to ignore, it is positive evidence of a fraud attempt." > > 4. "If you are doing DMARC alignment testing, don't match on my PSD name, > You are not looking at an organization record." I agree those four make for a commendable behavior, but they are not really incentives. IOW, lazy PSD might take years to comply. > A related question is whether there is any incentive for malicious use of the > "I'm a PSD" flag by entities that are not actually PSDs. Since the only > effect of this flag is to cause mail to be blocked, I do not see any such > incentive, so I do not see any risk. I do, because John reported a link to the PSL wiki where they complain of ISPs striving to get on the PSL. Best Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org<mailto:dmarc@ietf.org> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
