The problem DMARC solves is different than the problem the PSL solves, though. DMARC prevents a 3LD from pretending to be a different 3LD on the same 2LD. But the PSL handles things like what it means to make a "cross-site request" or how to handle cookies.
I mean now I'm thinking if DMARC _could_ solve that... but I don't think it could, unless I'm missing some extension or rare use case.
Yes, DMARC isn't solving the same problem — but DMARC is showing how the category of PSL problems can be solved with DNS. With HTTP/3 now fully expecting browsers to be able to benefit from transparent-upgrade record responses, i.e. `www IN HTTPS 1 . alpn="h3,h2"`, then it is possible for the style of solution shown by DMARC to be applied to other problems that PSL solves today.
CAA isn't a good fit as-is either, because the subdomain has top precedence over the parent domain — precisely the inverse relationship needed here. But having worked with the PSL for quite some time operationally and seeing the direction of trends away from it and towards structural DNS declarations rather than a centralized list, I think the 3LD-2LD-CRSF problem would be far better off solved with DNS than PSL.
Basically, just adding `co.uk. IN TLD subs=independent` as an SVCB record would fully deprecate the need for the PSL versus cross-site and other such ownership-changes-hands boundary problems with both A.co.uk being allowed cross-site with B.co.uk, and with co.uk being treated as equivalent to B.co.uk by password managers, cookie repositories, and so on. It would also benefit CAA by defining whether the boundary exists — if TLS is hosted by the provider, then any CAA records published by the subdomain should be disregarded; if the subdomains are fully independent, then any CAA records published by the parent should be disregarded — which simply isn't possible today without either referring to the PSL or implementing DMARC-style DNS solutions.
(I don't formally suggest that exact record as structured or written but it's sufficient a napkin sketch of what I mean by gesturing at that RFC to be considered.)
I think DMARC works well because email tends to blindly trust DNS (opportunistic encryption). On the web we expect authenticated TLS, often strictly enforced (organization policy, HSTS). So it would feel weird if a website changes how it handles HTTPS cookies based on an insecure DNS record, perhaps delivered by the resolver on an untrustworthy WiFi router.
Specifically, if I register subdomain attack.co.uk and set up a malicious WiFi router, I trick some *.co.uk cookies to get set on co.uk and then steal them from attack.co.uk by tampering with the (proposed) SVCB record.
I think the signal needs to be secure, which means DNSSEC. Adding a hard requirement for DNSSEC validation in all web browsers is a huge change from where we are now.
And essentially boils it down to ‘either the client implements wire-security to a known dns server using DoH or DoT, implements dnssec to verify the untrusted response as legitimate, or the client risks being mitm’d to attacker addresses’. They ultimately sidestepped the problem by structuring it to be hints rather than guarantees and thus allowing DNSSEC to be optional, and so as of today, it’s definitely not sufficient to implement this.
I think that adding a CORS rejection to DNS — declaring subdomains independent of a TLD, that is — does not require DNSSEC, so long as clients adhere to the steps to prohibit attacker interference described. But it still asks a great deal of DNS that I’m unsure is possible today, not just in DNSSEC but in ripple-subward records that somehow tie into client responses.
More likely, I assume browsers will simply permanently end all service to the concept of subdomains at all; no cookie sharing across domains at all, no inherent cross-origin just because tld and www.tld share a few characters, etc. rather than either depending on the PSL or having to implement strange and complex DNS anything. Admins will throw their hands up about it, but the net is no longer a place where control of a TLD defines the trust of its subordinates, so it’s certainly time to rip that bandaid off if they haven’t yet.
The problem DMARC solves is different than the problem the PSL solves, though. DMARC prevents a 3LD from pretending to be a different 3LD on the same 2LD. But the PSL handles things like what it means to make a "cross-site request" or how to handle cookies.
I mean now I'm thinking if DMARC _could_ solve that... but I don't think it could, unless I'm missing some extension or rare use case.