[tor-dev] The Onion Name System (OnioNS)

Tue May 19 11:24:34 UTC 2015

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xE29FC3CC.asc
Type: application/pgp-keys
Size: 14034 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150519/fb7eab50/attachment-0002.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xE29FC3CC.asc
Type: application/pgp-keys
Size: 14032 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150519/fb7eab50/attachment-0003.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150519/fb7eab50/attachment-0001.sig>