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 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> 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. 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” and “domain.com”. > > > > But what happens if we suddenly encounter: > > > > _psl.example.com. IN TXT “true” == This is not fine as there is no way to > know if “example.com” belongs to the same legal entity as “.com”. > > > > The 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> *Im Auftrag von *Douglas Foster > *Gesendet:* Donnerstag, 4. November 2021 11:54 > *An:* Alessandro Vesely <ves...@tana.it> > *Cc:* IETF DMARC WG <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 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 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> 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> 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 > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
