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