Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

[Jim Fenton <[e-mail]>]

On 30 Mar 2024, at 7:43, Alessandro Vesely wrote:

> On Sat 30/Mar/2024 04:09:10 +0100 Jim Fenton wrote:
>>
>> [...]
>>
>> I’m concerned that some (admittedly rare) public suffixes with multiple components are not well served by this algorithm, such as pvt.k12.ma.us.
>
>
> Is there something peculiar with this domain?  Please expand.

It’s an example that appears on https://publicsuffix.org that I cited because it has many components. I’m not sure there is really a problem with this, though.

>> What happens if a domain that is not a public suffix publishes psd=y, either accidentally or maliciously?
>
>
> The interesting point of the Tree Walk is that it allows any domain to self appoint itself as PSO or org domain, without going through PSL bureaucracy.
>
> By publishing psd=y, a domain cannot use relaxed alignment, and may prevent some receivers from issuing failure reports.  By not publishing psd=y, a PSO does a disservice to its independent subdomains, forcing them to publish psd=n.

I didn’t follow all of the DMARC discussion about the tree walk, so I don’t understand the psd tag fully. I understand what the algorithm does with it, but it would be nice if the document described what happens if a PSO fails to publish psd=y or if a non-PSO publishes psd=y. Does the tree walk fail in some way (e.g., fails to find a policy it should) or does it just cause additional DNS lookups?

At first glance, it seems that a domain that is under a public suffix that doesn’t publish psd=y might be vulnerable to subdomain-exhaustion attacks (a.b.c.d.e.f.g.h.i.j.k.l.example.org if .org doesn’t publish one). It doesn’t seem like a PSO has a particular incentive to publish a record, and there are many public suffixes that would need to be covered.

In any case, it would be good for the document to describe these things, perhaps under Security Considerations.

-Jim