Why separate namespaces/TLD's for Tor/I2P are a bad idea

[biolizard89]

1. .bit --> clearnet (ipv6/ipv4 and everything else)
2. .tor/.t --> evrything intended to be seen on tor (a. all .onion addresses and b. may be some clearnet addresses also intended to be seen on tor in an oppressive country)
3. .i2p/.i/.2 --> i2p only
-----------
But I am not sure if 2b wouldn't create confusion and create a negative impression so best would be:
1. .bit --> all clearnet addresses(ipv6/ipv4 and everything else)
2. .tor/.t --> all onion addresses
3. .i2p/.i/.2 --> all i2p addresses
may be additionally
4. .mix -> here can be all mixed and the TLD denomination is suggestive

But as we distance from the most clear (and surfer safe) implementation that could lead to the dismemberment of the namecoin DNS system. (one proxy would interpret in a way, another in a different way)

Is there a practical advantage to having .bit be IP-only, as opposed to using .bitip for that? I suppose some users may be unaware that .bit could resolve to Onion or I2P addresses; is that what you're addressing? Using the word "mix" is ambiguous though; the word "mix" has a specific meaning in anonymity which is not the same as what this spec is defining. Maybe .bitany? Also, I think .bittor/.biti2p would be preferable over .tor/.i2p for the trademark and user confusion reasons outlined earlier.

[virtual_master]

Is there a practical advantage to having .bit be IP-only, as opposed to using .bitip for that? I suppose some users may be unaware that .bit could resolve to Onion or I2P addresses; is that what you're addressing?

Exactly. The users should clearly know when they are clicking on a tor or i2p address.
No other major advantage. But this is very important and not respecting this would under-grab the sense of tor.

Using the word "mix" is ambiguous though; the word "mix" has a specific meaning in anonymity which is not the same as what this spec is defining. Maybe .bitany? Also, I think .bittor/.biti2p would be preferable over .tor/.i2p for the trademark and user confusion reasons outlined earlier.

bitany and bit2ip are too long for a TLD extension but they are still much better than using .bit for everything

[phelix]

.bitip and the like is too long imho, too. why not simply .ip / .ip4 / .ip6

[biolizard89]

.bitip and the like is too long imho, too. why not simply .ip / .ip4 / .ip6

.bitip is the same length as .onion. .bittor and .bitip4 are only 1 character longer. There are other TLD's such as .museum and .pirate which are as long as .bittor. I think readability and meaningfulness should take precedence over saving a couple of bytes. Googling for the TLD should result in Namecoin results (bitip / bittor will do this; ip / ip4 / ip6 will not).

I'm not sure how I feel about using .bit vs .bitip for IP-only. I guess .bit is fine for IP only, then use .bit4 and .bit6 for IPv4/IPv6, and .bittor/.biti2p for Tor.I2P, and .bitany for automatically choosing resolver?

[biolizard89]

So going back to domob's suggestion of .tor.bit, I think that that proposal as-is may not be optimal, since right now tor.bit is the IP domain specified at d/tor.

However, how about "._tor.bit" or ".-tor.bit"? The underscore character is banned from valid domain names, but in my testing it does successfully get passed to the Convergence proxy, so we could specify that a 2nd-level domain starting with an underscore specifies a resolver. We could also use a hyphen, since they are also banned from the beginning of valid domain names. Either of these possibilities would make the spec unambiguous, not infringe on trademarks, not generate a bunch of new TLD's for every new resolver we add, and not pollute the blockchain with extra namespaces.

So:

.bit: IPv4/IPv6
._tor.bit: Onion only
._i2p.bit: I2P only
._any.bit: user client chooses based on user preference

(Hyphen could be used instead of underscore in above examples, I kind of prefer underscore but I don't feel particularly strongly about which gets used.)

Thoughts?

[biolizard89]

Hey guys,

So I was talking with some people and I think we need to revisit this.

This is a very strong argument in favor of the TLD separation. Let me expand it in more details.
- a. I begin with an example. An ordinary user in a country with an oppressive regime is reading sometimes the news from the opposition propagated via tor. He/she clicks on a opposition.bit link which is via tor and is private but forgets to start the browser in a tor environment. The request cannot be solved by the browser but he will be revealed as user of this site by the ISP which is giving the information to the regime and he will be put in jail for 20 years. It could be even worse if a total unaware user will click this link without knowing what it is.
Having opposition.tor the user will know/will be reminded to click this link only in a tor enabled environment.
-b. I am sure the most people have never used Convergence or NmcSocks. I also never used them. For the most people it is complicated enough to browse .bit domains. Now asking them to configure an extra proxy just to know which domain is for tor, I2P and usual it would be to much.
-c. IPv4 or IPv6 is not an issue for an ordinary surfer. He/she can surf them without knowing the difference because both serve the same purpose and they are not hidden services.

Okay, let's go through the various scenarios:

Scenario 1: The user is using Firefox and Tor Browser, with Convergence in both. He accidentally opens a Tor-based .bit link in Firefox.
Result: Convergence in Firefox won't touch Tor resolvers without getting authorization. Unless the user has intentionally fucked up the config of Convergence, Convergence will block the connection and there will be no DNS leak.

Scenario 2: The user is using Firefox without Convergence and Tor Browser with Convergence. He accidentally opens a Tor-based .bit link in Firefox.
Result: DNS will leak, but DNS would also leak if he opened an IPv4 .bit link in Firefox.

Commentary: There is a misconception that .onion links are inherently dangerous to be detected *viewing*. This is not true. .onion is designed to protect the site owner, not the viewer. The Tor Project is implementing a built-in Tor2Web mode where the viewer is not anonymous but the .onion site owner is anonymous. As 2 examples, viewing The Zyprexa Files on an .onion doesn't have to be anonymous; only the site owner is worried about legal threats. Meanwhile accessing an IPv4 site like Cryptome/WikiLeaks might attract unwanted attention. So any policymakers of .bit should keep in mind that .onion domains are desiged to protect the site owner. Protecting the visitor via Tor is optional for both IPv4 and .onion.

Scenario 3: The user is using Firefox and Tor Browser, both without Convergence, and is instead using a DNS server like nmcontrol.
Result: DNS servers ignore Tor resolvers. Firefox will not leak DNS because the local DNS will return that the domain doesn't exist. Tor Browser may or may not make the .bit request depending on whether its DNS settings were changed by default, but if it makes a .bit request it will be via Tor.

Are there any security/privacy issues specifically caused by .bit pointing to a .onion/.i2p that come up in scenarios other than the above 3?

I'd like to start implementing some of this area of the spec soon, but obviously I'd like a good technical discussion before implementing anything.

[virtual_master]

Hey guys,
Scenario 2: The user is using Firefox without Convergence and Tor Browser with Convergence. He accidentally opens a Tor-based .bit link in Firefox.
Result: DNS will leak, but DNS would also leak if he opened an IPv4 .bit link in Firefox.

Sure. But it is not the same if it leaks a clearnet link or a tor link.
I agree that clearnet links can be also compromising and tor links can be also without harm but it is still better to have a distinction for the user security.
There is another argument also for a separated domain. If you want to browse a tor or i2p link you need a started proxy or TBB.
If you didn't started it it doesn't have sense to click on darknet links.

Commentary: There is a misconception that .onion links are inherently dangerous to be detected *viewing*. This is not true. .onion is designed to protect the site owner, not the viewer. The Tor Project is implementing a built-in Tor2Web mode where the viewer is not anonymous but the .onion site owner is anonymous. As 2 examples, viewing The Zyprexa Files on an .onion doesn't have to be anonymous; only the site owner is worried about legal threats. Meanwhile accessing an IPv4 site like Cryptome/WikiLeaks might attract unwanted attention. So any policymakers of .bit should keep in mind that .onion domains are desiged to protect the site owner. Protecting the visitor via Tor is optional for both IPv4 and .onion.

May be it is only optional to protect the users but I think we should use this option.

Let's see another possibility:
1. .bit for clearnet links (which doesn't need any resolver usually - to transform .bit to ipv4 they may need)
2. something else ( .h or .hidden, .dark, .dk) for links which need a special resolver or proxy (tor, i2p, gnunet .... and anything else)
- User is protected against DNS leakage by surfing on a clean browser.
- User is aware that he needs to start a resolver in order to browse that link. Mostly is a tor link. By clicking for ex in TBB on an i2p link it will not be resolved but he will know from the link what he see that is not a tor link. Then he can start the i2p resolver.
The user is protected against DNS leakage even if he uses for surfing the wronge resolver.

I would say .bit should be restricted only to clearnet links and the second domain (whatever is - for ex .dark) should be open for anything but intended to tor, i2p, gnunet, and all clearnet links where the domain owner considers it would be better to view his domain with tor or VPN.

[biolizard89]

Hey guys,
Scenario 2: The user is using Firefox without Convergence and Tor Browser with Convergence. He accidentally opens a Tor-based .bit link in Firefox.
Result: DNS will leak, but DNS would also leak if he opened an IPv4 .bit link in Firefox.

Sure. But it is not the same if it leaks a clearnet link or a tor link.
I agree that clearnet links can be also compromising and tor links can be also without harm but it is still better to have a distinction for the user security.
There is another argument also for a separated domain. If you want to browse a tor or i2p link you need a started proxy or TBB.
If you didn't started it it doesn't have sense to click on darknet links.

Commentary: There is a misconception that .onion links are inherently dangerous to be detected *viewing*. This is not true. .onion is designed to protect the site owner, not the viewer. The Tor Project is implementing a built-in Tor2Web mode where the viewer is not anonymous but the .onion site owner is anonymous. As 2 examples, viewing The Zyprexa Files on an .onion doesn't have to be anonymous; only the site owner is worried about legal threats. Meanwhile accessing an IPv4 site like Cryptome/WikiLeaks might attract unwanted attention. So any policymakers of .bit should keep in mind that .onion domains are desiged to protect the site owner. Protecting the visitor via Tor is optional for both IPv4 and .onion.

May be it is only optional to protect the users but I think we should use this option.

Let's see another possibility:
1. .bit for clearnet links (which doesn't need any resolver usually - to transform .bit to ipv4 they may need)
2. something else ( .h or .hidden, .dark, .dk) for links which need a special resolver or proxy (tor, i2p, gnunet .... and anything else)
- User is protected against DNS leakage by surfing on a clean browser.
- User is aware that he needs to start a resolver in order to browse that link. Mostly is a tor link. By clicking for ex in TBB on an i2p link it will not be resolved but he will know from the link what he see that is not a tor link. Then he can start the i2p resolver.
The user is protected against DNS leakage even if he uses for surfing the wronge resolver.

I would say .bit should be restricted only to clearnet links and the second domain (whatever is - for ex .dark) should be open for anything but intended to tor, i2p, gnunet, and all clearnet links where the domain owner considers it would be better to view his domain with tor or VPN.

It's trivially easy for a .bit resolver to notify the user when it attempts to resolve a .bit domain that doesn't support the enabled resolvers.

Examples of how this could be done:

1. Display an appropriate error in Convergence, same process as what it does now to notify the user that NMControl is unreachable.
2. Have NMControl display an error in the OS's notification bar.
3. Make the .bit domain resolve to localhost, and have a web server there which shows an appropriate error.

Regarding your other comment, protecting the user by default is fine -- but in that case IPv4 should also be protected since it is also potentially dangerous. The way to go about this is to use TorBrowser as the browser base rather than Firefox, and have everything go through the Tor SOCKS proxy. Discriminating between IPv4 and Onion for this question doesn't make sense, as I discussed earlier. The fact is that .bit is simply not safe if you open it in a browser environment that isn't aware of .bit and your threat model considers DNS leaks to be dangerous. There's a really easy way to deal with that -- set NMControl as your DNS server. This has nothing to do with .onion sites, it's simply a problem with system-wide DNS resolution which has a simple solution.

[virtual_master]

I have spoken with somebody in RL and he was also convinced that d/ should resolve all cases.
That means that if you registered a d/example namespace entry you control with it all associated domains ?
(like example.bit, example.tor, example.i2p, example.gnu, example.ipv6, ...)
Wouldn't be to much for 0.02 NMC ?

I think we would need a new fee model with this.
(with dynamically rising network fee for more asked domains)

[biolizard89]

I have spoken with somebody in RL and he was also convinced that d/ should resolve all cases.
That means that if you registered a d/example namespace entry you control with it all associated domains ?
(like example.bit, example.tor, example.i2p, example.gnu, example.ipv6, ...)
Wouldn't be to much for 0.02 NMC ?

I think we would need a new fee model with this.
(with dynamically rising network fee for more asked domains)

(Are you replying to my previous message or making a new point? I can't tell.)

If you register a d/ name, you would be controlling multiple resolvers, but you would be making a guarantee that all resolvers will point to the same content. This is one reason to use .bit for all resolvers (because if I change settings to make I2P preferred over Tor resolution when it was the opposite previously, the .bit domain should load the same content, just over a different resolver). Same thing as using multiple IPv4 addresses in a domain, or both IPv4 and IPv6 addreses.

I do think fees need to be reworked because 0.02 NMC is a ridiculously low price for a domain, but I don't think multiple resolvers have much to do with the fee issue.