[tor-dev] GSoC: Support all kinds of DNS queries

[Jeremy Rand]

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

Daniel Achleitner:
> On 2017-04-02 05:22, Jeremy Rand wrote:
>> (Thinking out loud.)  It would be interesting to have some kind
>> of algorithm agility here.  For example, a Tor client could send
>> a request for a Namecoin domain name, and the exit relay would
>> return a Namecoin merkle proof in the same way that it would
>> return a DNSSEC signature if were a DNS doman name.
> 
> It certainly seems to be a good idea to design the cell format to
> be agnostic as to what kind of "proof data" is attached to the DNS 
> response. As prop219 just wraps around the existing DNS-packet 
> wire-format, it should already allow that, provided that Namecoin
> has a wire-format for the proof.

Awesome, that's great to hear.  Namecoin doesn't have a "canonical"
wire format for those proofs, but we have one implementation that made
up a format for its own use (with the intention of standardizing later).

> Certainly out of scope for GSoC, but I'm wondering: Apart from
> running a full Namecoin node (and storing the whole blockchain) on
> every client/exit node/whatever, is there a privacy-preserving way
> to resolve a .bit domain, i.e. without an upstream node/resolver
> learning/logging exactly which domain was resolved?

I can think of 3 ways.

(1) We have a client right now that only downloads the full blocks
from the most recent year (which means it has all the transactions
that correspond to unexpired names); it also downloads the block
headers going back to the genesis block (so that it can verify PoW).
This requires around 10 minutes to do initial sync, and around 400 MB
of storage.  This client generates no network traffic for lookups, so
no one learns anything about what was resolved.

(2) It should be possible in theory to do a softfork that has a
coinbase commitment to a merkle root of all the unexpired names and
their values.  This merkle tree could be constructed such that you
could retrieve a subtree from another Namecoin node, and verify that
all the names in that subtree are authentic, while not revealing to
the node which name within that subtree you were looking up.
(Choosing the tradeoff between subtree size and privacy is up to the
user.)

(3) We could, hypothetically, hardfork to store only the hash of a
name in the blockchain rather than the name itself.  The value of the
name could be encrypted with a key derived from the preimage of the
hash.  This would hide the name being looked up unless the node being
queried already knew of a specific name or hash to be looking for.

I don't foresee (2) or (3) happening very soon, but maybe in the future.

Cheers,
- -- 
- -Jeremy Rand
Lead Application Engineer at Namecoin
Mobile email: jeremyrandmobile at airmail.cc
Mobile PGP: 2158 0643 C13B B40F B0FD 5854 B007 A32D AB44 3D9C
Send non-security-critical things to my Mobile with PGP.
Please don't send me unencrypted messages.
My business email jeremy at veclabs.net is having technical issues at the
moment.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJY5uamAAoJELPy0WV4bWVwfCUP/3aHWVoqiA2/ClnHFeogIftP
xD8iUX+c8+vpy9IwqSnF/UUVg2Sg6tlJ1RxebrCO2CvBRGXWVZyBQoGWSWrTwIcC
1QIfXqGrTU7dBJzk578Rwz4K6TaqblWpDIJQ9dV0FwMttighVD62jaDiJiFqqmVN
TLFBjHBSanyxqnZ4g1fWS0baKVnzR2TgpaJiTaHNDhqv/FCKeR4Gnj3mGuxreO1z
w7FrvFYSF9esCcqYtMB0zkPFyXbuaYg2tinnlx6TdmzhsLIMHIZVOlVbY32CFeee
ZM3q9gogX0581rNF5oVfSxDVnD99n+1GMYpmpWoq0dQEnrK4AQoLumXqmlFmEr/6
85pNcm+gETs0TH3vT8Cnbkc5tchd0wejLOdGFFjQgPu6iIcHQy8bd1xAyWIO2Ygl
6dbuOvc72vCoqc2HuM0cRkJXqnToiZHtJx5jdRYImFMubWqLaVVB4shkHMCVUBGm
7FySsjWYU4vHsD74R8mrT79Gde3vOpqVFdsJQMoYAojWLk2Vzn9/wC/DayMDyO//
PKm2ET3iYefLil/fo1s7+JuAAUco1vGNvLkOf+0/3PTGsWi7QbWAOznvykOd6OmT
ap+rRdQfGTvEc+/m1q4fTCyRL/EaSyxNNgYBjKFfHyLHZJqP/CLXG49lruuQr9sH
9tJ8BCGpH8tEDHJUZb3l
=tnyY
-----END PGP SIGNATURE-----