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

Tue May 19 17:11:02 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 05/19/2015 03:20 AM, tor-dev-request at lists.torproject.org wrote:
> Subject:
> Re: [tor-dev] The Onion Name System (OnioNS)
> From:
> Christian Grothoff <grothoff at gnunet.org>
> Date:
> 05/19/2015 03:24 AM
>
> To:
> tor-dev at lists.torproject.org
>
>
> 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. ^_^.
I will put that on the to-do list.

> Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph).
Thanks, I'll make those corrections. Good to hear from someone who is part of that system.

> 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.
My scheme is better than Namecoin in several key ways:
1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network.
2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor.

The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs.

> 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?
I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot.

> 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.
I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data.

> Why do you limit names to 128 characters, when DNS supports 253?
For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain.

> 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'.
I think you may misunderstand. Computational power (PoW) here has nothing to do with Zooko's Triangle. With Namecoin, the network is assumed to have more CPU power than adversaries and thus they can achieve all three properties. Here, PoW is only used to increase the difficulty of claiming a domain name, and I get the uniqueness property because I assume that Tor routers are generally honest. This is a safe assumption as if Tor routers weren't honest, Tor circuits would not provide privacy and again the whole system breaks and becomes moot. So, I assume that Tor routers follow the rules and reject duplicate domain names, therefore the network as a whole prevents collisions. An attacker could win here by Sybil attack by spinning up many new Tor routers and gaining control of the Quorum by placing the statistics in their favor. My analysis shows that this is extremely unlikely for L_Q >= 127.

> 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).
Glad to have your support. I agree that the Internet DNS is broken. It was never designed with security in mind in the first place; there was no need to because originally everyone knew each other. :)

> 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.
Yawning mentioned this. It's easy enough to create a spec that defines the protocol for handling other pseudo-TLDs. Currently Tor writes "*.tor" to a named pipe, reads "*.onion", and finishes the lookup. It's easy to use that protocol for any alternative DNS. It's outside Tor's scope to care how the *.tor -> *.onion map is accomplished.

Jesse V.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCAAGBQJVW26lAAoJEK2XNk/CC+yA+1MH/3HNANFFzhCs567B8XkcHu0M
VijH8dD6f+ClxuxVFmjKb5c9jlgK5vW9E+LsFiUFbT3vHdjZxh4nH4zNv1FnVIxc
RnkNvuhXGYpDCSRFNtvqa1ZPwOj3ENBvB8++wB/M2DM3KN4B6dKXdHNgjfMDNfji
L62o23ApQaKOu8vi0wr9VNLTCbji9LS0GerR5G7mUMAUo194WjBGhNwhBQknCeze
RACjHnRjfqDWSyszgI7e0xKNK3rGOzQWIPwlScqnl1LEh6tWaxMZDmzN+FHr2QbG
C5Sb1fDywKeVCQdBSAjAS++WvzvYNbiFExaJ9ucVWMPMdjrxjDzpHrVM8P/xWaY=
=6kyi
-----END PGP SIGNATURE-----