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 <[email protected]> Im Auftrag von Douglas Foster Gesendet: Donnerstag, 4. November 2021 11:54 An: Alessandro Vesely <[email protected]> Cc: IETF DMARC WG <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
