So I'm going to let someone inject DNS entries into a local /etc/hosts hijack, based on information from a 3rd party over a distributed network?
You know, I'm not actually against that so long as I can verify the end site in some way. Perhaps all traffic over this .p2p network should be SSL? And perhaps someone somewhere can hold a verifiable list of certs.
Basically, who in this arrangement can I trust to route my request to the right site? How do I know they won't lie? I know that applies now too, but DNS is based on trust and that generally means the roots are trusted and they won't risk that trust. In this decentralised world, who can be trusted?
The local application would ensure that only .p2p DNS requests would get handled by this system. Presumably this would be open source, so you can verify yourself that it's not going to intercept your bankofamerica.com requests.
Also, I think the intent is that any solution to this would include a cryptographic web of trust. However, it's probably still going to be the case that by visiting any .p2p site you are accepting risk--just as visiting many seedy torrents on an unpatched browser is risky now.
Also, there is really nothing protecting "normal" DNS against spoofing right now. Sure, djbdns and the latest version of BIND are hard to attack (65536 source ports * 65536 transaction ids). But who knows what DNS software your ISP is using? Who knows how your Windows workstation handles forged responses?
Incidentally, I think that if DNSSEC ever gets deployed, you'll be able to verify records even after they have been removed from the "real" DNS. That will solve both problems at once... but of course, the Internet always chooses workarounds in favor of clean solutions, so don't count on this happening any time soon. (My house has IPv6. But nothing else does...)
So it'd be impossible to ever log in to an account at any .p2p site because at any point it may suddenly be in the control of an attacker? Seems rather limiting.
You have to be careful. To be more sure you'd need another means to verify their authenticity (for example a SSL certificate).
And preferably use a SSL certificate to authenticate yourself as well instead of a user/password pair.
Sure, most websites still live in the 90's where it concerns security, but with P2P it suddenly starts to become much more important to have proper authentication for both sides :)
SSH also checks public keys, without relying on any central signing authority. You could generalize this to SSL easily.
You do need to be able to publicize your public key somehow with as little risk of MiTM as possible, but every secure communication method has this problem.
Tor solves this by making a hash of the public key part of the URL. Of course, there might be more user-friendly solutions.
Nothing would be preventing you from accessing the site with their regular ___domain name. This system is meant for when that isn't possible, for the vast majority of websites this is better than nothing.
Obviously you should use discretion when using it, but that doesn't mean it isn't a good idea.
Sure, except the surface area for a man in the middle attack has expanded from, roughly, someone on the same network as you to anyone anywhere on the Internet.
Presumably you would only have to trust the network in full. Similar to how bitcoin operates. You might have to trust the 'tracker' to give you a legit network, but once you are in the swarm, it is easy to tell if any of the nodes are lying to you.
This is a very interesting project. However, I think in order for something like this to succeed, it needs to be founded in a truly altruistic goal such as education, research, or some form of free information.
"By creating a .p2p TLD that is totally decentralized and that does not rely on ICANN or any ISP’s DNS service"
Sadly, the acronym p2p is tied with media piracy. If this alternate DNS system relies on the .p2p TLD, ISP's will have an easy way to filter this traffic. Beyond simple blacklist blocking, similar to what Comcast is doing to Level 3, it would make more sense for ISP's to simply charge extra (a lot extra) to access the .p2p side of the Internet.
A similar conversation was had years ago around the .xxx TLD discussion. In the end, the Internet needs to be open and priced at a level where everyone can access the information contained within it. If the US, China, etc start to impose drastic, unresonable restrictions then we will have no other choice except to create alternate systems. Eventually, this will create a fragmented, disjointed Internet completely different from the one we are using now.
This doesn't use $ISP's DNS resolver -- it's totally based on your own machine (essentially /etc/hosts shared by BitTorrent as trotsky notes below) and appears as encrypted BitTorrent traffic.
Certainly, $ISP could block all BitTorrent traffic if they wanted to prevent this, but that would be a much different situation.
It's also worth noting that there are a number of alternate roots [1] out there right now (that use DNS, not BitTorrent) and AFAIK ISPs aren't trying to block them, either.
Really encrypted or "BitTorrent encrypted"? It should be noted that what most BT clients call "encryption" is really only protocol obfuscation to attempt to bypass filtering or throttling of the BitTorrent protocol. The packets are still transmitted in the clear and the content of the torrent is not obfuscated at the metadata level either.
In short, "encryption" was a really bad thing to call this, because many people believe encrypted BT connections are safe and encrypted in the traditional "you can't tell what I'm doing" sense.
The encryption part of this whole thing is useful and very interesting.
This line of thinking is very similar to what happened when the Gnutella network itself was formed. It was created as an alternate system to the FastTrack network. Nervous of the legal system, the decentralized network was built with a (still increasing) number of clients available.
In the same way that the Gnutella network further fractured the web, alternate DNS systems have the same capability, on a much larger scale.
In my mind, there is nothing wrong with creating alternate systems that work beyond the view of government agencies and the public in general. However, every time we do this, we create yet another fracture in the Internet that we know and love.
> In my mind, there is nothing wrong with creating alternate systems that work beyond the view of government agencies and the public in general. However, every time we do this, we create yet another fracture in the Internet that we know and love.
"The Net interprets censorship as damage and routes around it." -John Gilmore
See the comment I left on the parent -- usually, "encryption" when referring to BitTorrent does nothing to prevent the public or government from being able to see what you're doing, it is merely protocol obfuscation, installed to bypass BitTorrent protocol filtering or throttling.
... Only when using the ISP's DNS. The point of the project is to locally catch .p2p requests before they hit a DNS server and do the lookup locally. (So they can't be filtered, categorized and reported.) The local table would be provided by what appears to be force-encrypted BitTorrent traffic.
"According to the project’s website, the goal is to “create an application that runs as a service and hooks into the hosts DNS system to catch all requests to the .p2p TLD while passing all other request cleanly through. Requests for the .p2p TLD will be redirected to a locally hosted DNS database.”"
The encryption part of this is perhaps the most interesting. However, even without breaking the encryption, I have to think that there will be ways to identify requests base on pre and post data.
We know what encrypted Torrent traffic looks like. We don't need to know exactly what is being transmitted, only that an encrypted torrent session has been started. Similarly, I'm guessing that we would be able to draw conclusions based on size, timing and flow?
Considering they haven't been able to successfully block the downloading of quite plainly illegal material, I seriously doubt they'll be able to block simple text files. When there's a will, there's a way.
I wonder about the security of this kind of a solution, and how they'll respect/protect owned ___domain names. I'm assuming the idea of ownership of a ___domain name becomes somewhat grey using this solution.
For example, how will they protect against ___domain poisoning by someone hacking their client to send out fake entries which redirect a ___domain to something they own?
The problem of ___domain ownership was what jumped to my mind. How would the system protect from ___domain hijacking etc?
The only system I can see has to do with polling multiple hosts, taking the most popular response for a ___domain and routing that way, but then it is still something that can be overcome with enough machines on the network.
The Bitcoin approach that I've mentioned looks basically like the following:
Basically, you use Bitcoin's block chain described here: http://www.bitcoin.org/wiki/doku.php?id=block_chain However, instead of using the chain for monetary transactions, you store new ___domain registrations in each individual block.
Now you just need a mechanism to fend off the ___domain squatters. Again, we can use an approach similar to Bitcoin (and to Hashcash): If you want to store your registration in a block you need to "pay" for this with some CPU power. So if you want to register a given ___domain you need to calculate SHA-256(domainname + data), where data is chosen in a way that the first X bits of the resulting hash are zero. So basically you need to use a brute-force mechanism to find appropriate data. If it, e.g., takes on average 1 week to find this data, this is acceptable for an individual who wants to register a ___domain, but (hopefully) too expensive for a squatter.
However one problem with this approach is that there's no incentive for someone to participate in the block generation. In bitcoin participation gives you Bitcoins which have a real monetary value. But I think creating some incentive shouldn't be too hard. E.g., it should be possible to couple the block chain to Bitcoin, so that generating blocks for the secure ___domain system also gives you Bitcoins (as a side effect).
The incentive that has been proposed by BitDNS is that awarding blocks is equivalent to registering domains. So using the current protocol of awarding 50 bitcoins for every block generation would translate to awarding 50 name registrations. Plenty of incentive for early adopters to build a strong network.
Most people don't enter authentication credentials they use elsewhere or conduct financial transactions on torrented software, like they do on websites.
IANAE but I imagine ___domain verification will require a certain ratio of trackers to all point the ___domain at the same IP. Random poisoned trackers would be ignored, perhaps flagged.
That still would leave the system vulnerable to massive botnets where a blackhat can 'flip a switch' and point a ___domain at a different IP on hundreds of thousands of nodes.
It's an interesting idea and problem. The DNS system has always felt pseudo-distributed to me - not exactly centralized, but still limited in its redundancy.
The idea of making a torrent-based DNS seems akin to a starfish - you can cut off every limb at the root and not only will it not die, it will completely regenerate.
According to the project’s website, the goal is to “create an application that runs as a service and hooks into the hosts DNS system to catch all requests to the .p2p TLD while passing all other request cleanly through. Requests for the .p2p TLD will be redirected to a locally hosted DNS database.”
I'm not sure if you mean that as just an aside or in context of this .p2p tld, but I'm pretty sure an "application that runs as a service and hooks into the hosts DNS system" would need elevation too.
I had a similar idea some days ago and planned to write a simple prototype.
However, instead of supporting standard registrations my idea was more similar to Tor's .onion namespace:
You first generate a RSA keypair and build a hash of the public key. This hash is your domainname.
Then you timestamp your zonefile and sign it with your private key. Afterwards, you store the result in a DHT under the key of the hash generated earlier. DHT nodes responsible for your data verify that your signature corresponds to your public key and that your public key corresponds to the hash.
As a last step you need a way to retrieve the data: The first possibility is to use your own local resolver on your PC that queries the DHT. An alternative would be to have several public resolvers that make this data available under different subdomains.
Supporting non-hash domainnames is somewhat harder due to security problems (if you want to have a fully decentralized solution). However, it might be possible to do this with an approach similar to Bitcoin's, where a block-chain is used to store transactions.
Why not replace DNS names with public keys? Anyone can generate one - removing the need for centralized namespace authority for key->ip mapping - and any lookup can easily be verified as only the server at the correct IP would have the private key.
Would be interesting if by the time Senate hearings get around to looking at this (if they ever do) that a simple demo will show how useless the actions were in the first place...
Won't matter. They care about hitting the average user who won't know what the hell this special p2p dns lookups are. If the power users get away with it fine, as long as 99.9% of the population comply.
Nobody uses DNSSEC, so it's still easy to poison DNS caches. Power users know how to do this, and can "poison" the DNS caches with the correct entries instead of the government-sanctioned alternatives.
I'm getting some popcorn. This will be fun to watch.
Nobody uses DNSSEC, so it's still easy to poison DNS caches
I'm not sure if that's accurate - I believe source port randomization has made it extremely difficult to poison recursive DNS servers. I think a recent "successful" attack on source port randomizing showed it took them 7 hours on a 10Gb/s link to poison one A entry.
Think about how much bandwidth is used every day for downloading porn. Use 1% of that for poisoning DNS, and DNS points wherever the poisoners want it to.
The average user doesn't need to know about special p2p dns lookups. He just has to be able to download a bittorrent client which knows how to do a p2p dns lookup.
Maybe I'm not understanding correctly, but the dns lookups will be built into torrent apps, which everyone uses. So rather than go to piratebay.org the user would open utorrent and use the utorrent browser.
No, he means when you open your browser and type "www.piratebay.p2p", some program under the hood will 1) connect to a tracker, 2) get the ip from the tracker in a similar fashion to what bittorrent does to get seeds and 3) continue with the navigation as always.
By connecting to this tracker, the translation from "www.someplace.com" to 12.13.14.15 (what the machine really understands) is done regardless what the ICANN dns says. No way to redirect to a "this page is closed" server, no web page can be cut off the internet. Check mate.
This game is far from over. Filtering web requests based on the requested host is enough to disrupt this, and even SSL requests send cleartext hosts (sadly).
You are right, this war is far from over. Just I wasn't considering the whole war, but this battle, this game in particular. We'll see how the next battle starts, and then we'll play our moves the best we can, but this time, in this game to be precise, I think is a check mate. And a speedy one, too. Maybe.
So, this has happened before, with not much success: http://en.wikipedia.org/wiki/AlterNIC - of course the guy that started that also cache poisoned InterNIC so that might've had something to do with it...
I'd assume that anything of this nature needs critical mass more than anything else. Like Google Public DNS/OpenDNS supporting it on day one, or the next version of BIND (whenever /that/ happens!) having it built in.
I envision future where individuals and companies are free to buy/sell services and goods from each other, without government sticking in its nose.
Also, I envision p2p marketplaces, where online ads and other goods are sold and bought. Can anyone come up with an open source p2p AdSense killer? Do we really need Google to do it for us?
This could finally mean freedom from ICANN and any other controlling authorities. Somehow this needs to have ___domain identity verifying mechanisms as well.
I was thinking about a sort of reverse Tor this morning, so that sites can hide their IP from users, as opposed to the other way around. Trouble is, you want it to work with existing browsers - users aren't going to install a new piece of software or a special browser to access masked domains.
> Does this mean I can access a .onion address from within firefox when I've got the Tor plugin enabled?
Yes.
You will however need to run the Tor software -- Privoxy or Vidalia bundle or... something. I don't think the plugin can do the routing itself.
I haven't used Tor in a while, but there used to be wikis, forums, even shell account servers and search engines available as hidden services. Don't expect anything interesting though.
You know, I'm not actually against that so long as I can verify the end site in some way. Perhaps all traffic over this .p2p network should be SSL? And perhaps someone somewhere can hold a verifiable list of certs.
Basically, who in this arrangement can I trust to route my request to the right site? How do I know they won't lie? I know that applies now too, but DNS is based on trust and that generally means the roots are trusted and they won't risk that trust. In this decentralised world, who can be trusted?