On 04/04/2017 12:50 AM, Nick Mathewson wrote:
On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@torproject.org writes:
Section 2.1 and elsewhere:
I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end with .onion too.
I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion.
I2P has been doing this for years with *.b32.i2p for unique identifiers vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P proposal to create a formal registry of 2LDs that implementations need to know about, so we have the ability to expand in future under the .i2p TLD. So I don't think it's a stretch for users to understand (although I have other concerns, see below), and I'd be keen to have a common standard for specifying subdomains that we can use for interoperability :)
I have mixed feelings about keeping the .onion suffix.
One one hand it seems like The Right Thing to do, since we managed to get .onion standarized in the IETF which comes with various benefits. Also, starting to squat other tlds arbitrarily seems like a silly thing to do.
This is the safest space for Tor to work in from a technical perspective. More specifically, I've been following discussion in DNSOP ever since the original special-use names draft (containing .onion, .i2p etc) was posted, and there is no way that the IETF is going to standardise any new TLD for non-DNS (see below). It's increasingly unlikely that the non-.onion TLDs in the draft will either (without industry support like .onion had), so no CA-supported SSL certs for I2P :(
However, I also dislike asking users to visit something.bit.onion instead of something.bit, since people are not used to the second tld having a semantic meaning, and I can imagine people getting very confused about what it means.
There's also the problem of transport-agnosticism. Assume there's some FOOnet that is created for naming that we all decide we want to use. Users would probably expect that FOOnet names all exist in the same space, which would not be the case if we had *.foo.onion, *.foo.i2p, etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a DNS name delegate to both via A and AAAA records; you wouldn't want the name changing just because the underlying transport changed.
Indeed. And I'm not only concerned about people becoming confused: I am also worried about confused programs.
Right now, it is easy to answer the question "will Tor handle this address specially" -- the only special addresses are the ones ending with ".onion", and the legacy suffices ".exit" and ".noconnect" as documented as address-spec.txt. But if we allowed arbitrary TLDs in this proposal, then _any_ hostname would potentially be an address that Tor would handle specially.
There is a draft currently in working-group last call that will specify a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that future non-DNS names will have to be under. Part of the proposed benefit is that with a standard TLD, DNS resolvers can just stub out that entire namespace, ie.
if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn)
Presumably, browsers would do so as well. So it's possible that you could have *.foo.alt as the URI, but only *.foo is displayed in the browser (along with some chrome indicating it is non-DNS), similar to how only the base domain name is shown for some URIs (IIRC that's an SSL cert verification thing).
The question then is how a browser would handle *.foo being typed in. You wouldn't want to query DNS and then try *.foo.alt afterwards, as that would be terrible for privacy, but if they tried *.foo.alt first, and didn't have FOOnet installed, should they try *.foo in the DNS? The browser either needs to know the full contents of *.alt (which is not possibly because by design it will have no official registration), or every registered TLD in DNS (which won't ever be added as a restriction because of various legacy local-net vendor TLDs like *.home). So with this approach, it's likely that .alt would need to stick around.
Lots to think about here...
str4d
[0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08 [1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html
-
str4d