Why separate namespaces/TLD's for Tor/I2P are a bad idea
Posted: Fri Aug 02, 2013 11:49 pm
Why separate namespaces/TLD's for different resolvers are a bad idea
Recently, there have been proposals for separate namespaces/TLD's for different domain resolvers, e.g. tor/, i2p/, and an unspecified namespace for CJDNS. I think this is a poor engineering practice for several reasons. This post will attempt to discuss these issues.
1. Domains which support multiple resolvers should be able to specify all supported resolvers with a single name. This is not theoretical; WikiLeaks' submission system was available at both IPv4 and Onion addresses. Using a single name allows the owner of the name to prove that he/she considers all of the specified resolvers to be trustworthy (otherwise how would a user know that the owner of wikileaks.bit considers wikileaks.tor to be trustworthy?). It also allows domain owners to switch resolvers as necessary (e.g. a user offering an Onion service might later decide to also offer it on I2P). If tor/ and i2p/ were used rather than d/, the aforementioned domain owner would have to register 2 names before even deciding to use 2 resolvers, or else risk a squatter obtaining the 2nd name. (This becomes an even bigger problem if additional namespaces for extra resolvers are introduced later.)
2. The most common argument made in favor of separate namespaces/TLD's is that it is necessary for the user to be able to see which resolver is being used before clicking on a link, or that it is necessary for a web browser to be able to automatically block certain resolvers. The problem with this argument is that it takes a UI issue and tries to solve it as an backend issue. A proxy server such as Convergence or NmcSocks could easily block certain resolvers, and a browser UI add-on could also display which resolvers are used by a particular .bit domain. There is no reason to sacrifice the flexibility of the d/ namespace's backend engineering to fix a UI problem. If doing so were good engineering, then IPv4 and IPv6 would have separate TLD's, as they have similar issues. I don't see anyone suggesting that IPv4 and IPv6 should have separate TLD's.
3. Even if a tor/ namespace were used, it should definitely not use a .tor TLD. Tor is a trademarked name, and The Tor Project would not be pleased if their name were used as a TLD without authorization. I doubt that they would actually sue Namecoin developers over it, but they might generate negative publicity for Namecoin (as they have done for TorMail and TorChat). Ignoring the legal issues, it simply is not ethical to use a TLD such as .tor which will inevitably result in support requests going to the Tor developers instead of Namecoin developers (wasting the time of the Tor developers). For similar reasons, we should not reuse the .i2p and .onion TLD's for Namecoin, as this will generate user confusion and misdirection of support requests. Doing so would also interfere with the I2P and Tor developers if they later decided to use a different method of human-readable names.
4. The ip6 field in the d/ spec should be restricted to addresses that are resolvable without specialized networking software. This means that OnionCat, GarliCat, Phantom, CJDNS, and any other nonstandard IPv6 addresses should be put in their own field in the d/ namespace. While it is theoretically possible for an implementation to ignore specialized IPv6 addresses, doing so complicates the setup and would probably require the implementation to do a lot of extra work, particularly if a domain is resolvable by multiple IPv6 addresses (remember, round-robin balancing needs to be supported by an implementation too). As new specialized IPv6 schemes are introduced, the implementation requirements for using the ip6 field for this purpose become increasingly complex, while using separate fields within the d/ spec remains simple (implementations simply won't be looking for those extra fields unless they want to use them). I imagine that it might be useful, however, for a resolver utility such as NMControl to offer a "getIp6Any" call, which would rely on user settings in NMControl's config file to control which specialized IPv6 address spaces are acceptable. For example, a user could configure NMControl to permit standard IPv6 addresses as well as Phantom and GarliCat addresses, while excluding anything else (e.g. OnionCat and CJDNS); this way the apps which query NMControl would always be given an IPv6 address that the system is capable of resolving while not requiring individual apps to be aware of those resolution systems.
I think these issues should be discussed sooner rather than later. What are your thoughts?
Recently, there have been proposals for separate namespaces/TLD's for different domain resolvers, e.g. tor/, i2p/, and an unspecified namespace for CJDNS. I think this is a poor engineering practice for several reasons. This post will attempt to discuss these issues.
1. Domains which support multiple resolvers should be able to specify all supported resolvers with a single name. This is not theoretical; WikiLeaks' submission system was available at both IPv4 and Onion addresses. Using a single name allows the owner of the name to prove that he/she considers all of the specified resolvers to be trustworthy (otherwise how would a user know that the owner of wikileaks.bit considers wikileaks.tor to be trustworthy?). It also allows domain owners to switch resolvers as necessary (e.g. a user offering an Onion service might later decide to also offer it on I2P). If tor/ and i2p/ were used rather than d/, the aforementioned domain owner would have to register 2 names before even deciding to use 2 resolvers, or else risk a squatter obtaining the 2nd name. (This becomes an even bigger problem if additional namespaces for extra resolvers are introduced later.)
2. The most common argument made in favor of separate namespaces/TLD's is that it is necessary for the user to be able to see which resolver is being used before clicking on a link, or that it is necessary for a web browser to be able to automatically block certain resolvers. The problem with this argument is that it takes a UI issue and tries to solve it as an backend issue. A proxy server such as Convergence or NmcSocks could easily block certain resolvers, and a browser UI add-on could also display which resolvers are used by a particular .bit domain. There is no reason to sacrifice the flexibility of the d/ namespace's backend engineering to fix a UI problem. If doing so were good engineering, then IPv4 and IPv6 would have separate TLD's, as they have similar issues. I don't see anyone suggesting that IPv4 and IPv6 should have separate TLD's.
3. Even if a tor/ namespace were used, it should definitely not use a .tor TLD. Tor is a trademarked name, and The Tor Project would not be pleased if their name were used as a TLD without authorization. I doubt that they would actually sue Namecoin developers over it, but they might generate negative publicity for Namecoin (as they have done for TorMail and TorChat). Ignoring the legal issues, it simply is not ethical to use a TLD such as .tor which will inevitably result in support requests going to the Tor developers instead of Namecoin developers (wasting the time of the Tor developers). For similar reasons, we should not reuse the .i2p and .onion TLD's for Namecoin, as this will generate user confusion and misdirection of support requests. Doing so would also interfere with the I2P and Tor developers if they later decided to use a different method of human-readable names.
4. The ip6 field in the d/ spec should be restricted to addresses that are resolvable without specialized networking software. This means that OnionCat, GarliCat, Phantom, CJDNS, and any other nonstandard IPv6 addresses should be put in their own field in the d/ namespace. While it is theoretically possible for an implementation to ignore specialized IPv6 addresses, doing so complicates the setup and would probably require the implementation to do a lot of extra work, particularly if a domain is resolvable by multiple IPv6 addresses (remember, round-robin balancing needs to be supported by an implementation too). As new specialized IPv6 schemes are introduced, the implementation requirements for using the ip6 field for this purpose become increasingly complex, while using separate fields within the d/ spec remains simple (implementations simply won't be looking for those extra fields unless they want to use them). I imagine that it might be useful, however, for a resolver utility such as NMControl to offer a "getIp6Any" call, which would rely on user settings in NMControl's config file to control which specialized IPv6 address spaces are acceptable. For example, a user could configure NMControl to permit standard IPv6 addresses as well as Phantom and GarliCat addresses, while excluding anything else (e.g. OnionCat and CJDNS); this way the apps which query NMControl would always be given an IPv6 address that the system is capable of resolving while not requiring individual apps to be aware of those resolution systems.
I think these issues should be discussed sooner rather than later. What are your thoughts?