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

[Christian Grothoff]

On 05/23/2015 06:26 PM, OnioNS Dev wrote:
> My design also assumes
> that there is no dynamic compromise of Tor routers (there's no
> incentive for an attacker to target Tor routers because of OnioNS)

I can live with explicitly stated design assumptions, but the claim that
there is "no incentive for an attacker to target Tor routers because of
OnioNS" is rather wild.

>> With Namecoin, you have an inherent limit on the rate at which
>> names can be registered.  Now, once people start squatting tons of
>> .tor names, maybe even your bandwidth advantage disappears as the
>> consensus may become rather large.
> That's a fair point. It's a hard problem to solve. It's subtle, but I
> also put in a requirement that the network must also ensure that the
> registration points to an available hidden service. Thus it forces
> innocent users and attackers to also spin up a hidden service. It's
> not foolproof, but it's better than nothing.

Interesting. Is a powerful adversary able to prevent registration by
somehow denying/delaying access to the new ".onion" service and
concurrently submitting a competing registration for the same name? I
remember such attacks being discussed for DNS, where a candidate's
search for available names might cause those to be quickly reserved by
some automatism as a means to extort name re-assignment fees.  Just
wondering if you considered this possibility. (IIRC Namecoin defends
against this by having an additional commit-and-reveal process where the
name is first reserved without the name itself being revealed).

> I've also been thinking
> about a proof-of-stake solution wherein the network only accepts a
> registration if the destination HS has been up for > X days.

Can a HS have more than one name?

> Another
> idea is to have the Quorum select a random time during the week, test
> for the availability of the hidden service, and then sign whether
> they saw the HS or not. Then the next Quorum could repeat this test,
> check the results from the previous Quorum, and void the Record if
> they also observed that the hidden service was down. I like both of
> these ideas, but I have not yet solidified their implementation so I
> was not ready to announce them in the paper.

Sure, good time to discuss them then ;-).

>> Well, I prefer my hidden services to be really hidden and not
>> public. I understand that this weakness is somewhat inherent in the
>> design, but you should state it explicitly.
> Too late, your hidden services are already leaking across Tor's
> distributed hash table.

Today, yes. Tomorrow, who knows; I'm still hoping that the next
generation of HS will fix that, and hope try to get Tor to accept the
GNS-method for encrypting information in the DHT. Which, btw, is pretty
generic (we also use it in GNUnet-file sharing, and I have other plans
as well). In fact, I think if you look at the GNS crypto closely, it
might offer a way to encrypt most information in any DHT (and offer
confidentiality against an adversary that cannot guess the
name/label/keyword / perform a confirmation attack).

> There are even Tor technical reports and
> graphs on metrics.torproject.org which count them, which I assume
> also implies that they are enumerated. 

You are totally right about the status quo. I just would point out that
this may not be true in 2020 ;-).

> It's not about CPU power, it's
> about the honesty of nodes in the Tor network.

I understand that. But whether you do it on IPs, bandwidth or CPU, you
did lower the bar on the adversary.

> That gives me the
> globally collision-free property. Perhaps I have lowered the bar, but
> I do think it's a bit higher than Namecoin because OnioNS is only
> dependent on the distribution of identities, and not the distribution
> of CPU power.

I agree that it is probably easier to mount a 51% CPU-attack against
Namecoin than an attack against the OnioNS quorum.

>> Could we please make the protocol a bit more general than this?
> Yes, I will look into it. Your description is helpful, but if you
> want to write up a protocol describing what you want on your end,
> I'll merge it into my protocol, and then we'll have a protocol that
> is compatible with both of our needs. I would be happy to modify my
> software accordingly.

I agree that we should have a write-up, but have to add that I hope to
delegate most of the writing to Jeff ;-).

Happy hacking!

Christian

-------------- 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/20150523/12c89308/attachment.sig>