-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add .onion #374
Comments
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
|
I think it makes sense to add it, although it's true that it doesn't fit neatly into the definition of either section. |
Please also https://en.wikipedia.org/wiki/Emercoin
|
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.
|
@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. |
I apologize for the delay, I was travelling. I don't have any specific objections to add 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 @sleevi @dnsguru as far as I understood, you are suggesting to add it to the PRIVATE section. Is that correct? |
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?
|
@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 As a library maintainer, I think @rockdaboot may also have some feedback. |
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.
|
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. |
@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). |
@rockdaboot that's fine, it is actually a feedback 😉 |
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. |
While "onion" does not appear within the root zone database, per RFC 7686, it is set aside as a special-use domain name, and explicitly called out as suitable for inclusion by IANA within the root zone database. Unlike other special-use domain names at this time, onion names that comply with RFC 7686 meet the definition of ICP-3 for both community process and a globally unique namespace (through being bound to keys in a process that ensures two clients end up with the same resolution). Closes #374
While "onion" does not appear within the root zone database, per RFC 7686, it is set aside as a special-use domain name, and explicitly called out as suitable for inclusion by IANA within the root zone database. Unlike other special-use domain names at this time, onion names that comply with RFC 7686 meet the definition of ICP-3 for both community process and a globally unique namespace (through being bound to keys in a process that ensures two clients end up with the same resolution). Closes #374
In the last weeks we made some large changes to the list of .RU and .SU domains in the PSL, due to some very old policy changes at the registry (2009) and more recent follow up. Given the amount of pressure about these changes from certain users, most certainly because LE limits, I figured out you'll soon have people asking you to merge the changes. I've packaged a new release of publicsuffix-go, and updated the dependency in this PR. $ git show master commit c5490f26d8f43b84857ac54e23387b8ed9b100dd Author: Simone Carletti <[email protected]> Date: Tue Feb 7 23:26:14 2017 +0100 Release 0.3.2 ➜ publicsuffix-go git:(master) go test ./... ? github.com/weppos/publicsuffix-go/cmd/load [no test files] ok github.com/weppos/publicsuffix-go/net/publicsuffix 0.023s ok github.com/weppos/publicsuffix-go/publicsuffix 0.039s Please note this release also includes the .ONION as per publicsuffix/list#374
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
The text was updated successfully, but these errors were encountered: