Including requirement of _psl TXT leaf for domain of section owner

[dnsguru]

Problem:

How do we know a person changing or adding a sub-section is connected to it?

Was fielding #1199, and looking at it, it represents an entry that is desired to be added within the list of domains they either do or do not have a relationship with.

Have had a number of submissions come through like this, but have wanted to have this more tightly validated.

PRIVATE section (mostly) issues:

A New / Different party can submit change to an existing sub-section that they didn't initially submit if they validate the specific domain they are including/removing/modifying. How do we trust this was submitted by appropriate party?

This is also the case where a new sub-section is added. Because the domain(s) listed in the sub-section header or the responsible party email address are not held to the same validation requirement that the affected domain name is.

Example:
Assuming CompanyA is a real company and COMPA.FOO is a real URL and company address. New entry from party unaffiliated to CompanyA adds section by validating DNS on two unrelated domains:

// CompanyA COMPA.FOO section managed by Jennifer Scoundrel <[email protected]> 
companya.phishtld
companya.otherbogus

A person could create a new github account, submit this as a PR, validate the domain names companya.phishtld and companya.otherbogus by setting up the appropriate _psl.companya.phishtld and _psl.companya.otherbogus txt records, and be seen as associated with CompanyA.

Similarly, they could have done so with an existing CompanyA section.

Solution

To close the loop on all this, I propose that the section domain must be included in the _psl txt review

[sleevi]

@dnsguru I agree, it's a problem, but considering that previously, the section identifiers were primarily useful for maintaining a list of domain contacts, when things were done manually, and that's less an issue now, I'm more interested in understanding if there is any practical impact.

That is, if sketchy-domain.example is added to // Awesome Company Inc, what is the issue? The comments have no semantic meaning, and anyone relying on them (other than us) is already in for a world of hurt, so ... it's not clear to me why it should matter.

I realize that sounds dismissive, which isn't my intent; I'm more trying to understand the threat model a bit more.

[dnsguru]

The impetus on this one was borne from seeing recent requests originate from new or recently created github accounts seeking to affect an existing section within the PRIVATE section of the list. I have had to send private emails to double-check on them having some (even if loose) connection to the section.

I am little hamstrung on being specific due to some (perhaps over-cautious on my part) respect of NDA, but I am thinking of quite a few of the derivative use / integrators of the PSL that do use that commented section header for stuff.

That stuff does use the header of the sub-sections as to a bit of forensic, troubleshooting or other purpose tied to the names below it.

I am not looking to add more cycles for us maintainers, because we're volunteering our time, but I am always looking for ways to ensure that this resource is trustworthy where there is the opportunity to do so.

We have in place the TXT leaf record for the domain being added, so, sure... that adds more integrety and a verifyable connection to the specific domain itself. I there are uses (even ours as maintainers) for the commented subsection headers.

I am more thinking of this issue/change as a reasonable guard against rougue third parties, ex-employee, poor ethics competitor, etc scenarios doing something unexpected or bad, like social engineering... later removing a different entry from the subsection.

I am mostly thinking of larger industrial companies such as Oracle, Google, Microsoft, Amazon, Centralnic, Github (just off the top of my head) where they may have different divisions, staff turnover, or even different subcontractors or orgs that work with the section changes.

Maybe, to avoid it getting too much of a burden for us to maintain or extra steps, we could make this into something like a special opt-in by the opener or maintainer of the subsection. Perhaps something like they add a special character like a poundsign/hash ("#"), or perhaps an extra "please validate subentries" on their subsection header to indicate they want to have subsection changes validate the domain in the subsection header? Clearly, this would require setting zero expectations on it being followed, and be more of a request, but it would help it be a more trusted resource.

Just mostly socializing the concept.... I like the 'why care' approach as it is resource-lean and faster, and compatible with our staffing levels (and salaries :) as volunteers).

[Mstandastote]

#1199

[Mstandastote]

#1497

[Mstandastote]

Duplicate of #1497

[simon-friedberger]

Given that @wdhdev and @groundcat have been trying to use this information to ask for removals it might be worth reconsidering this.

[wdhdev]

If submitters want, they could just add a note to email the email address listed to confirm any entries being added from unknown/new parties.

[dnsguru]

We end up with a lot of scenarios whereby the org "manager" or submitter moves on or is no longer with the org. Basically, in theory, a bad actor being able to assert nexus with a domain name different than those listed in their entry might be possible. The objective is to close the opportunity window on that, while also adding integrity to the request by verifying the requestor section org domain.

[simon-friedberger]

1. I think this is a reasonable idea but I would like to avoid the complexity for now. If we actually want to associate domains with organizations the best strategy seems to be to require email verification when a domain gets added. That way the _psl records stay only on domains which want to be on the PSL and we are also validating the email addresses. (I'm not against DNS verification or .well-known or whatever but since we want email to work anyway, it makes sense to use it.)

2. However, we are currently saying in the PR template.

   Submitter will maintain domains in good standing or may lose section.

   Which means when we start enforcing this, we have to pay attention to who modified the section.