Add a generic public-service namespace suffix for sandbox testing / lab use

[sirdarckcat]

It happens (apparently often) that people request a public suffix to the PSL (see #1272 and #1241) for a use-case of a one-time "lab" type of usecase (eg, trigger behavior that browsers/clients/libraries/servers use the PSL for). This is particularly important for some security applications because "Site" is a first-level concept of the browser security model (so, subdomains don't work).

The proposal would be to have a domain name (name TBD) added to the PSL of the form: *.psllabs.com where a custom DNS server is running on something.com that returns to SOA requests with the value of the domain being requested. For example 1-2-3-4.psllabs.com could respond with 1.2.3.4 (this is an example).

The cost of running a service like this would be modest, and a large company could sponsor it (I could seek Google to run this), and the advantage would be that people that just need one-off PSL additions can use this service.

I can experiment with something similar to this (there seems to be expired suffixes in the PSL I could use), but it probably makes sense to agree to do this first.

[dnsguru]

Is this kind of like a sandbox type system ? Wonder if it is worth getting something under .arpa via the IETF formally?

[sirdarckcat]

it's kindof like a sandbox, yes for testing, development, demos, etc.. the 2 PRs I showed are for "demo vulnerable apps" and how they would behave with different browsers.

I'm not sure what's the process with .arpa - but yea, I guess something like in-addr.arpa but that resolves to SOA instead of A

[dnsguru]

@sirdarckcat Would you mind typing up something that I could review with the ICANN Office of the CTO so that we can get their recommendation ? I believe you are largely describing that there be the creation of some form of a general purpose namespace solve for the lab user types who want to poke around with example domains to test cookie horizons, DOM, etc.

I like this idea because it allows for the type of CTF or lab scenarious that help make things safer for users, and the proposed concept preserves the ambition of filesize modesty.

[sirdarckcat]

Would the idea be that ARPA would run it? Or they would just provide the TLD.

Anyway, I can write something up, although what format and how detailed does it need to be? Is this a one-pager or a RFC type of thing.

[dnsguru]

arpa

Some undelegated name within .arpa or peraps example.com - I don't want to constrain or limit the idea early on.

There are other proposals heading to or under discussion within IETF that this might mix in with.

I vaguely recall a proposal that created some rfc1918-ish private test namespace, and was tracking a lot of this before the March to June ios/fb cycle suckered me out of time

The team at ICANN OCTO follow this stuff closely and I would alert them to this issue with some context around the benefits of cookie/etc etld+1 affectation

On Wed, Jun 9, 2021, 11:09 PM sirdarckcat @.***> wrote:

Would the idea be that ARPA would run it? Or they would just provide the TLD.

Anyway, I can write something up, although what format and how detailed does it need to be? Is this a one-pager or a RFC type of thing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/publicsuffix/list/issues/1349#issuecomment-858336381, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJIIXQSGLILGAYJ3K6LTSBJLNANCNFSM46MKBUDQ .

[dnsguru]

I had a chance to confer with some experts in the DNS space on an approach to use with this and in reviewing this:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/

It seems as though there is a block of space that was set aside for private use.

We could conceivably use two of these for the purpose of a private namespace to let folks sandbox the affectation from PSL presence.

.xp and .qp were suggested (maybe the P is PSL?).

// xp, qp private PSL sandbox or testing // xp as top level entry, qp as wildcard entry // https://datatracker.ietf.org/doc/draft-ietf-dnsop-private-use-tld/ *.qp xp

[mozfreddyb]

This internet draft provides a great building block and explicitly carving out those various top level domains sounds very useful for private testing. I'd sure use them.

However, it doesn't quite meet @sirdarckcat's proposed goal, in which he suggested a global name that can be shared and reused for close collaboration and sharing research results. I want to acknowledge that standardizing a global domain name that allows a unique 1-1 mapping for for every IP address has significant ramifications for DNS operations globally, but it's also very, very useful for those who "just want to get a name".

[sirdarckcat]

About the private use TLD

It's a very interesting proposal! However, as Freddy mentioned it doesn't quite does the same thing. In our case we need a public domain too, not just a private one.

That's not to say that the proposals are incompatible. I think we can come up with a solution that resolves both concerns, however they'll need each a different line in the PSL. One for private internet, and one for public internet.

About the public use TLD

I started experimenting with a bad (more on why it's bad below) version of this on http://www.nom.gd/ using an expired domain in the PSL (by the way, an easy way to reduce the size of the PSL is to remove expired domains). It's a bit of work, as I need my Registrar to be onboard forwarding me abuse reports (if they don't, I'll change registrars). Unsurprisingly, most of the work on running this service is likely going to be dealing with abuse :-). If ARPA was willing to manage this (like they manage in-addr.arpa) that would make it a long-term solution that isn't at risk of breaking if I forget to respond to a phishing report and my Registrar undelegates the domain so they don't get slapped in the hand by ICANN for not dealing with abuse promptly.

So, I think, nom.gd is not going to be good enough as a long-term solution. Not just because the name and provenance is sketchy (at the very least), but also because it can break at any moment (not based on the DNS server owner as I assumed but rather based on the Registrar).

Also, nom.gd isn't quite enough. It would be a lot better if one could control the zone of a TLD, so one can experiment with more than A records. Having an entry so that we can delegate zones on the PSL would be more future proof, and allow for a wider use.

[sleevi]

but it's also very, very useful for those who "just want to get a name".

Can you explain?

I see significant security downsides in this, including those we explicitly call out in the Guidelines, namely:

We do not accept entries for use as DNS wildcards, such that e.g. 1-2-3-4.foo.tld resolves as IP address 1.2.3.4. This basically projects the security properties of the IP address space onto the domain name space, and we don't feel that is safe.

I haven't really seen a compelling discussion about the use cases here, and this makes it difficult, as PSL maintainers and as browser vendors, to evaluate the security implications and tradeoffs of this proposal. It'd be very useful to make sure we have a clear articulation about "Why does this need to be on the PSL" from a problem statement, because it's hopeful that we can find alternatives.

For example, based on the limited information provided, it seems browser vendors' offering a header and/or developer tools flag could fully address the use case here. Of course, that may be a very short-sighted view, but that's the issue with the lack of information.

[sirdarckcat]

no, I think a flag for browsers would work fine. as in, it would need to exist on all places that use the PSL, but still it would work.

hadn't seen https://github.com/publicsuffix/list/wiki/Guidelines#validation-and-non-acceptance-factors :)

[dnsguru]

I was focused on the name part of this in my suggestion.

Part of what allows folks to trust this resource is that we don't add things that are non-standard.

The challenge here is finding something top-level that also respects our policies on ICP-3 or i* vetted requirements on inclusion to the PSL.

• Someone could write a DRAFT through the ietf for subspace under arpa which takes time and energy (-2ish years).
• Someone could form a company and apply for .psl once ICANN opens the subpro application round (-185k usd ++)
• Someone could use the naming convention in that draft (-resolves only in sandbox dns)
• pick up expired and existing psl entries (-not top-level)

[dnsguru]

an easy way to reduce the size of the PSL is to remove expired domains

Folks in the private section tend to be casual and not return once they get their entry

Identifying and removing unregistered domains was actually something I got started before #1245 hoovered all my cycles and then some.

Ultimately, automation needs to be written to deal with that, because it is tedious. I think it has been on our to-do list since 2009.

But, yes, you are correct.

The hope was that the issue we are discussing would at least fit the purpose of the labs scenarios, capture the flag, etc.

[sirdarckcat]

For the lab/CTF case, I think the #1272 and #1241 usecases would have been solved also by having flags on browsers that add a fake entry to the PSL.

[dnsguru]

Sure; however, like all things PSL, we do not have any control or influence over what browsers do.

On Wed, Jun 16, 2021, 8:50 AM sirdarckcat @.***> wrote:

For the lab/CTF case, I think the #1272 https://github.com/publicsuffix/list/pull/1272 and #1241 https://github.com/publicsuffix/list/pull/1241 usecases would have been solved also by having flags on browsers that add a fake entry to the PSL.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/publicsuffix/list/issues/1349#issuecomment-862493766, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACQTJIJNHO6QUVIUHRI2A3TTDB35ANCNFSM46MKBUDQ .

[sirdarckcat]

@sleevi would you mind elaborating a bit more about the risks of the IP space? I'm trying to understand the difference between a self-service 1-2-3-4.tld and a $(curl https://nic.tld/api?ns=1.2.3.4).tld.

If I was to change the nom.gd to do a roundtrip like that, it would behave the same as .tk so I assume it's ok.

[sleevi]

I’m not sure I understand your question? What are you trying to accomplish with the question? I realize this is a bit direct, but I’m just trying to make sure this isn’t a “We’d like you to justify the policy, so we can relitigate the policy,” because, frankly, we don’t want to waste time with these requests - or explaining them repeatedly 😅

It should be obvious that 1.2.3.4.TLD would be fundamentally insecure for things like document.domain and cookie separation. However, we’ve seen several requests that do exactly this. It’s no different than running an open proxy as www.google.com.myproxy.example, sure - an equally dumb and insecure idea.

1-2-3-4.myservice.example avoids that, but simply introduces a new problem: holder A gets a TLS cert for that, then holder B obtains the IP, but that host can be MITM’d by A for a year (and heaven forbid C gets that IP…). So that’s another bad idea.

We’ve seen a cluster of requests that try to use this approach as a means of bypassing CA’s rate limits. That’s a hard strike against.

You can address this need with myservice.TLD, with the third subordinate label being a unique user identifier (mitigating the cross-user attacks obtaining the same IP), and the fourth subordinate label being the IP. This is, fundamentally, what Plex does, and the eTLD+1 is always {user}.myservice.example

Anyways, like I said: part of the policy exists so we don’t have to continually spend time explaining or justifying, especially given that every request we’ve seen would introduce security risks to browser users (which is what motivated the original policy).

[sirdarckcat]

The reason I ask is because I would like to find a solution for #1241. I understood it's a bad idea to add every lab/test environment to the PSL, so I assumed #1272 would be generic enough (it's not just 1 time but rather a more generic service). It seemed like #1272 wasn't generic enough so that's why I proposed #1349 (this issue) which was even more generic, hopefully reducing the issues introduced by the filesize modesty concern.

However in addition if the file modesty concern, you pointed out that the proposal being discussed here is very similar to that explained in the guidelines as an anti-usecase for the PSL.

We do not accept entries for use as DNS wildcards, such that e.g. 1-2-3-4.foo.tld resolves as IP address 1.2.3.4. This basically projects the security properties of the IP address space onto the domain name space, and we don't feel that is safe.

The example works differently from what I would like to have (I'm thinking of NS/SOA rather than A records) but it's close enough that it seems it's also an anti-usecase of the PSL. However I would still like to find a solution that doesn't suffer from the downsides explained in the guidelines (in specific the concern about projecting the security properties of the IP space to the domain name space), so I was wondering what that meant to see if there was a solution to be found that didn't suffer from the same issues.

I think your latest response mostly answered that question. In that when someone is given an IP address it might come with its own set of potential issues (you don't know who owned that IP before you, and they might have backdoored your domain), which could be an issue also for the proposal here.

I don't think this issue is a proposal to change the policy though. It's been since the beginning (including the previous issues) as a discussion about how to find a solution for these constant requests that fit within the policy. In other words, I am trying to find a solution that helps the PSL maintainers stop having these constant discussions by rather than rejecting people that ask, instead offer them a solution that fulfills their goals and don't have the security or abuse issues that these services would otherwise introduce. That said, in order to accomplish that I would need to at least understand what those issues are.

I'm trying to help you all by exploring solutions to these problem, that I just happened to stumble on while working on a 20% project (https://github.com/google/kctf). I think the use case that triggered my original request could be resolved with a flag on browsers (as suggested above), but since I had some time this weekend I thought maybe I could first explore if there was a way to solve the issues presented by this path before exploring the browser flag option.

I understand that it's difficult to maintain critical parts of the web infrastructure like the PSL, and that having the same conversation every day is tiring, so I can understand why you wanted to ask the question on whether I was just here to make you change the policy, but in this case I was trying to understand it so I could propose something that fits the policy goals in practice (and in spirit) so you don't have to have the same discussion every day.

[sleevi]

I mean, the flag is eminently preferable, especially because the use cases here remain unarticulated.

You seemed OK with the flag, and that’s why I was trying to understand why the new, non-flag exploration, since we’re still missing base use cases. I appreciate you trying to help, but I think for that to be useful, a more compelling explanation of why is needed.

[dnsguru]

There is an addendum / modification to RFC 6761 being discussed at the IETF which could define a bit more structure within special use domains which might lead to what was saught here.