[tor-dev] DNS proposal for Tor hidden services

Fri Aug 1 03:40:46 UTC 2014

Can we know a DNS for the normal HTTP of a hidden service?
If the onion hidden name cannot reach from outside of Tor then maybe use that?

________________________________
 From: Jesse Victors <jvictors at jessevictors.com>
To: tor-dev at lists.torproject.org 
Cc: Ming Li <ming.li at usu.edu> 
Sent: Tuesday, 29 July 2014 6:03 PM
Subject: [tor-dev] DNS proposal for Tor hidden services

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello everyone,

I have a proposal for Tor hidden services, which if it's a good idea
    and workable I may be writing my Master's thesis on. My description
    here is very early, and I would like to run it by you guys before I
    continue further. I have already run it past Tor developers, but
    have seen limited response, so I'm opening it up to a wider
    audience. Basically, I propose integrating Namecoin into supporting
    Tor relays, so as to provide a secure DNS service for .onion sites
    within Tor itself. The result is that a human-readable address can
    be translated into its .onion counterpart, analogous to a domain
    name resolving into an IP address on the regular Internet, a square
    of Zooko's Triangle conjecture.

Namecoin has a nearly identical codebase to Bitcoin, but instead of
    currency its primary focus is holding information, with a focus in
    DNS. Domains in Namecoin have the .bit extension, and registrations
    are secured with hashes in a blockchain. Anyone with the Namecoin
    blockchain can look up information in it, and indeed there are
    already Namecoin-supporting DNS servers that use the Namecoin
    blockchain to look up registrations in it. These basic premises are
    at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address
    for the DuckDuckGo hidden service, but it's hard to remember: even
    worse than a traditional IP address. Under my idea, a user could
    type in duckduckgo.tor, would see a secure translation to
    3g2upl4pq6kufc4m.onion transparently and with masking, increasing
    the usability and popularity of hidden services significantly.

My plan is in the context of Tor, to use the .tor domain, so as to
    not conflict with existing Namecoin registrations. The .onion
    address is a hash of the hidden service's public key, so if I own
    the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign
    something (perhaps the Namecoin public DSA key) to prove my
    ownership and set duckduckgo.tor.bit to point to
    3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network
    as usual, (this costs 0.01 Namecoin) so that it becomes integrated
    into the blockchain. So now duckduckgo.tor.bit points to
    3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it.
    Global DNS propagation may take less than 15 minutes. Namecoin
    domain registrations expire after 36,000 blocks (about 200 days) so
    a registration would have to be renewed occasionally for it to still
    remain. This is free to do, but ensures that domains don't endure
    indefinitely.

It's impractical for Tor users to download the Namecoin blockchain
    in order to use this system, (even with Merkle trees) so instead
    supporting Tor relays can hold a copy and the Tor client can send
    out queries to them. At startup, Tor clients build several circuits
    through the network in preparation for use. Now let's say the user
    wants to look up duckduckgo.tor. To avoid spoofing attacks from a
    malicious relay, Tor clients will query multiple relays and gain a
    consensus. To do this, the Tor client generates three nonces, N1,
    N2, and N3. It then picks three random relays, possible trusted
    relays like guards, R1, R2, and R3. These relays have public RSA
    keys K1, K2, and K3, respectively. For each of the three relays, the
    Tor client takes the request for duckduckgo.tor, nonce Nj, and
    encrypts the pair with the relay's public key Kj. Along with a
    special new Tor flag specifying the use of this protocol, it then
    sends the trio through the circuit to the middle relay. The middle
    relay then queries the three relays. Each relay decrypts the request
    using its private key, checks the blockchain for duckduckgo.tor.bit,
    finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the
    nonce, and sends it back, signing the result. The client receives
    the answers, checks the signatures, decrypts the responses from the
    three relays using the nonces, and compares the response. If all
    three match, it then looks up 3g2upl4pq6kufc4m.onion in the
    traditional way. If two or less match, it restarts with a different
    set of three relays. If all three relays return that duckduckgo.tor
    can't be found, it throws the standard DNS error message.

So I am simply building on top of the existing Tor hidden service
    infrastructure, not modifying it. I can write up a proposal for
    torspec.git once I have more details. I've already taken Tor
    0.2.5.6-alpha code, installed Tor from source, and used Chutney to
    set up a mini Tor network on localhost of 5 authorities, 10 relays,
    and 1 client. That seems a good platform for development on this.

What do you guys think about my proposal? Is this a good idea, and
    feasible? Anything I should watch out for as I go forward? What
    security threats exist that I should specifically defend against?

Thank you for your time.

- -- 
Jesse V.
/CS, Network Security/
/Utah State University/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQF8BAEBCgBmBQJT2BouXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB
RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA98MH/ih8VMQ8ZaKInYDDe3HBiU/s
9XBoGUT7ouXqnmtjSLjeTJjDfaNmLYBIRsAJTk8n/mJ7Zz9ld/5FW/QNKd1hAelE
wtL4hKyVhS70fWVkFqZTLLyeVHVbegJx5sF2YdkDD6cJDU//KNbXTCO7A1Bx9vOu
vPFoA+3ytlKcpx8HZn//k0mD7cB/dcS2GwSQmG2C+X0pWooJIsAJCgKyetbAaiHL
ub/sd6Sr0bgkItGOi9vlAdPo+p7nNMWVxQQPfNqzz1zQJzE3WRXpXKmIYAOtngWp
VT6SyrSkOmir/1+LN/s9d22VMaQKAzUVz21gbugBr64moeQW/IWbWBOQSbFA0J0=
=8zWV
-----END PGP SIGNATURE-----

_______________________________________________
tor-dev mailing list
tor-dev at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140731/697e6781/attachment.html>