Add .onion

[sleevi]

RFC 7686 officially passed through the IETF, which lists .onion as a Special-Use Domain Name

Unlike those names specified in the IANA Special Use list ( https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml ), the set of .onion domains extend beyond local resolutions. That is, two clients, both configured to recognize .onion names, both resolve the name to the same party. This is different than, say, .localhost or .example, which will resolve to the local machine.

At present, .onion is captured by the existing implicit '*' in the algorithm, and so adding .onion would not have a meaningful change to the PSL, except in that it will recognize it as a domain 'blessed' by IANA/ICANN, for applications which use the PSL for that purpose.

As noted, "Note that the registration of .onion names does not prohibit IANA from inserting a record into the root zone database to reserve the name."

I'm hoping to use this bug to capture any reasons why it may be desirable to not add .onion

[sleevi]

@gerv @weppos @dnsguru Any thoughts?

[dnsguru]

Tl:Dr response is I have no resistance to adding it, but suggest we put it in second section with subdelegations and be sure to reference to the RFC in the comment line above it. Extended dance mix response: Now that it got I* "blessed", I would see it as a special case exemption to the rigid adherence to ICP-3 like .Example or .Local might enjoy. Technically .Onion is not a TLD in the root zone from the IANA, or within a subordinate of one of then, which has been a basis to keep the list pure and to avoid the "energy" around adding alternative root tld zones. Thinking through some of the derivative use cases of PSL, such as anti-spam recognizing return addresses, and how those might be affected, we may want to annotate .Onion with reference to the RFC and place it in the != ICANN section and add notations about it to our wiki.

…

-Jothan

[gerv]

I think it makes sense to add it, although it's true that it doesn't fit neatly into the definition of either section.

[galeksandrp]

Please also

• i2p https://en.wikipedia.org/wiki/I2P
• bit https://en.wikipedia.org/wiki/Namecoin

https://en.wikipedia.org/wiki/Emercoin

• bazar
• coin
• emc
• lib

[sleevi]

As captured and discussed, none of these have gone though a consensus-based standardization consistent with the principles of ICP-3. .onion has been officially set aside by the IETF process, and is the only one that meets any such criteria.

[dnsguru]

@galeksandrp Totally appreciate that you're wanting to help us maintain a complete list and that is most certainly appreciated.

Perhaps to build on sleevi's comment regarding ICP-3, the only reason that .onion is being considered as a valid candidate for PSL in exception to flowing through ICANN / IANA (the ICP-3) is that .Onion did go through the IETF vetting process and was published as an Internet RFC.

This is a necessary step to avoid arbitrary creation of conflicts with potential future TLDs, to allow appropriate review and vetting processes to reduce the likelihood of causing technical or security issues.

Those TLDs which suggested for inclusion would need to flow through the next ICANN round of TLDs or be vetted in a similar manner to .Onion (or .Example or .Local as other examples) at very least to be considered.

[weppos]

I apologize for the delay, I was travelling.

I don't have any specific objections to add .onion. However, I'd be interested to know if it may introduce any possible edge cases as I know some consumers are using the PSL to validate ICANN/IANA TLDs.

I specifically recall a discussion involving Let's Encrypt, hence it may be interesting to get a feedback from them. @jsha would the addition of a TLD like .onion add any side effect to the current use of the PSL in Let's Encrypt? I'm not saying that this will be used as the sole feedback to include or reject it, but I'd like to get some extra external feedback.

@sleevi @dnsguru as far as I understood, you are suggesting to add it to the PRIVATE section. Is that correct?

[sleevi]

I have a slight preference to ICANN, but am happy to live with either and wanted to solicit feedback. I'm not aware of any practical issues, and for those implementations that integrate the PSL for things like certificate checks, the ICANN section seems slightly more desirable (e.g. `*.onion` should not be accepted). What issues would we anticipate where adding to PRIVATE might be more desirable?

[weppos]

@sleevi one of the possible advantages I can see of using the PRIVATE section, is that most libraries exposes the ability to disable the use of the private section. That would provide an extra compatibility layer that makes it possible to ignore .ONION if needed.

It's also true that .ONION domains are currently already implicitly defined by the * rule, but again clients may treat that rule differently and having an explicit .ONION entry in ICANN could possibly result into side effect.

As a library maintainer, I think @rockdaboot may also have some feedback.

[sleevi]

Considering that the reservation of .onion explicitly allows it to be added to the root zone database as a hold, wouldn't that issue manifest if it was? Should we explicitly filter out .onion from any RZD syncing? Like I said, I have a weak preference, and I suspect it's a fair point that if downstream consumers are relying on the PSL to contain the RZD (which it, unfortunately due to lapses and deregistration, includes other domains no longer present in the RZD), then it might cause issues. Any thoughts on how we go from superstition to safety though? I'm just curious how we'd ever get the info, short of making the change and waiting for implementors to join the mailing list to have a more nuanced discussion? But I'm also appreciative of the impact the .RU cleanup is having - technically correct but unanticipatedly disruptive.

[weppos]

Any thoughts on how we go from superstition to safety though?

I'd wait a couple of days for @jsha and @rockdaboot to chime in, to see if they have any specific feedback. After that, I'm fine to go ahead and then deal with that if anything specific will came out.

[rockdaboot]

@weppos Currently, I do not know of any real usage of sections. I implemented cookie domain checking with libpsl for curl, wget and wget2 with section==ANY (ICANN or PRIVATE).
So, for all the real use cases I know of, it would not matter where you put .onion. It wouldn't even matter if you don't put .onion into the PSL (* rule).
Sorry for no being much of a help.

[weppos]

@rockdaboot that's fine, it is actually a feedback 😉

[jsha]

Adding .onion in either section is fine from Let's Encrypt's perspective. We will add .onion to our explicit list of domains never to issue, just as a second check on top of the fact that no .onion domain should resolve on the non-Tor Internet. There's no timing constraint here since we vendor the PSL.

[weppos]

Thanks for the feedback @jsha.

@sleevi at this point, it's a 👍 to me too. I don't have strong arguments for now to have it in PRIVATE vs non-PRIVATE.

I would be ok to add it to ICANN and then move it PRIVATE if needed.