[tor-dev] Special-use-TLD support
burdges at gnunet.org
Tue Sep 29 07:39:43 UTC 2015
On Tue, 2015-09-29 at 00:59 +0000, Jeremy Rand wrote:
> Do I infer correctly that the main intention of this is to decrease
> the possibility of attack by a Sybil attack on the Namecoin network,
> by making the Namecoin peer selection process have similar properties
> to Tor relay selection (which is relatively Sybil-resistant)? (And I
> guess this would also eliminate issues where a Tor client connects to
> a Namecoin peer who also happens to be his/her guard node.) If so, I
> think I cautiously agree that this may be a good idea. (I haven't
> carefully considered the prospect, so there may be problems
> that I haven't thought about -- but from first glance it sounds like
> an improvement over what Namecoin does now, at least in this
I have not thought specifically about Namecoin's threat model. If the
DNS providing peer runs on the exit node then it reduces the threat
model to the same threat model as DNS.
> The issue I do see is that SPV validation doesn't work well unless
> ask multiple peers to make sure that you're getting the chain with
> most PoW. So I gather that this would require connecting to Namecoin
> peers running on multiple exit nodes. I don't think that's
> problematic, but it would have to be taken into account.
This is no different from validation for existing DNS results. Tor
attempts to prevent this by building a list of bad exits, but it's
challenging to catch an exit that attacks only one website.
You could check multiple peers but that costs you some anonymity. If
you use many .bit names, this might expose the fact that you use
Namecoin to your guard.
There are many Tor programs like Ricochet and Pond, and many websites,
that should be detectable by a sufficiently dedicated guard, so that's
not a compelling reason not to check multiple exits, but it requires
One could maybe design the Namecone shim to check obtain general-but
-relevant information from multiple exits running the Namecoin client,
but only obtain the actual result from one exit. Or maybe that's
reinventing the SPV client.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the tor-dev