Please write an IETF draft asking for ".tor" to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's ".onion" draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^.

Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph).

I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names.

I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys?

It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone.

Why do you limit names to 128 characters, when DNS supports 253?

With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'.

All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS).

So maybe Tor can plan to incorporate ".tor", ".bit" (namecoin), ".onion" and ".gnu". After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with ".gnu" and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well.

On 05/19/2015 01:48 AM, OnioNS Dev wrote:

Hello everyone,

I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation.

Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name.

I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow.

To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list.

Recommended readings: http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review I no longer recommending reading my original thesis, please use the above links instead.

My prototype can be found here: https://github.com/Jesse-V/OnioNS It's a bit unstable, but it does work once and sometimes twice. Please contact me (kernelcorn on IRC) before running the prototype, I need to ensure that the name server is up before you can try it out. You can also send me registrations over IRC and I can add them in.

I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. All other lookups should load as normal. I've never used Stem before but I understand using it will be a lot easier than hacking Tor. I have Stem up and running now. Any recommendations for what I'm trying to do here?

---

tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev