In the dustup generated in my article on DNSChain’s broken security model, some argued that there is a need for a trusted solution. I agree with this, my criticisms of DNSChain are that it misrepresents its security model and introduces the worst kind of third party trust without any gains in usability or interoperability. I’m working on a more secure trusted server solution that provides backward compatibility with the existing domain name system.
After I posted this, DNSChain adopted distributed trust as well, in that it will contact multiple DNSChain servers. If you reject DNSChain’s claim that users will run their own trusted server, the security of a DNSSEC validating local resolver approaches DNSChain while maintaining backwards compatibility with existing infrastructure. Remember: lightweight resolvers have equivalent usability and better security than DNSChain. The DNSSEC compromise gives up some security in exchange for a realistic path to universal resolution. When it comes to domain name resolution, DNSChain compromises the blockchain security model without gains in usability1.
Crank Like Behavior
Despite Greg’s claims, DNSChain is a trusted server solution: the general populace will either trust “friends” or their router manufacturer. We will get to a better trusted model in a moment, but it’s important to note that DNSChain is sold as a solution which eliminates MITM attacks and does not rely on third party trust – both of these assertions are clearly false.
Their falsehoods are compounded by the fact that DNSChain’s authors go out of their way to avoid admitting that they rely third party trust, using euphemisms like “friends” or “second party trust”. I spent a lot of time trying to explain this to Greg, DNSChain’s lead developer. Eventually, he switched from claiming “friends” would run servers to everyone relying on remotely connecting to a home server (maybe a router or a plug-pc). After I knocked that down as infeasible, DNSChain’s author didn’t address those weak points but changed the conversation, stating that it’s still “early days” and then making additional outlandish claims such as, “DNSChain’s censorship circumvention is in many ways superior to Tor’s!”
As far as I can tell, DNSChain is planning on selectively performing DNS hijacking; forwarding blocked sites to a transparent proxy. Of course, the user has to have a proxy that hasn’t been blocked and we are back to trusting “friends” to run this for you. As for comparing the project to Tor in terms of detection and the security model … I’ve learned that cranks don’t need to be correct, they just have to outrun the fact checkers. DNSChain isn’t doing anything special here, just making grandiose claims about some very vanilla technology.
No Usability Gains
Using DNSChain requires either installing software locally or altering your operating system’s DNS settings. The problem is that DNSChain’s client/server model will always be more complex than the equivalent scenario for a lightweight resolver:
- Effort required to manually install a lightweight resolver < effort required to maintain a DNSChain server + install and configure client software.
- Effort required to use a lightweight resolver bundled with browser/operating system < effort required to configure a DNSChain client software to use router that bundles DNSChain.
DNSChain throws away all of the security benefits of a lightclient without ANY gains in usability. However, I’m working on full an interoperability solution for .p2p (and hopefully .bit) that does not require altering any system settings or installing software. It’s not as secure a lightweight resolver (the preferred method) but the compromise is for major gains in terms of usability: anyone can link to and visit these sites!
Ideal Third Party Trust
By moving the trust mechanism outside of the local environment, you must introduce some form of third party trust. The essence of arguments against third party trust can be found in Ken Thompson’s classic Reflections on Trusting Trust, in which Thompson showed that an attacker can modify a compiler to produce malicious programs, including a rigged compiler that perpetrated the attack,
The moral is obvious. You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
The counter to this argument came decades later in the form of deterministic build environments. Deterministic binaries enable us to compare the output of multiple compilers, increasing the attack cost. The exact security offered is a bit more robust than my summary, but the lesson forms the basis of modern information security: we cannot prevent all attacks, but we can make them very expensive.
I call this type of trust distributed trust, as the trust is distributed across independent entities. This is distinct from the type of trust offered by the CA system, unsigned DNS, or DNSChain – which I call siloed trust. Siloed trust accumulates vulnerabilities as more organizations are added, whereas distributed trust becomes more secure as more organizations are added. By distributing the trust across independent organizations, we increase the cost of an attack.
We are planning on setting up multiple publishers and using threshold signatures to produce DNSSEC secured zone exports. We will initially use a DNS suffix, for political reasons I can’t elaborate I can’t elaborate beyond the DNS suffix but anyone can use our signed zone exports2. Interoperability with existing DNS infrastructure and the limitations of DNSSEC forces some compromises. However, we can revoke trust in any of the publishers at any time and custom client side software can even add additional publishers.
This solution is more censorship resistant and at least as secure as what is offered by other TLDs. While we will have to rely on the certificate authorities until we can convince browser vendors to embrace DANE, we’ve architected the encryption component so that we can seamlessly transition to DANE3. Eventually, I believe that we can offer something that is more secure than what the other TLDs provide. Site operators who decide that they need greater levels of security can opt out of the system and rely on lightweight clients that are more secure and robust against censorship.
DNSChain has responded to my critiques by advertising multi-chain compatibility and paying lip service to collaboration. This is frustrating because DNSChain is diverting resources from Namecoin’s lightweight resolvers, NMControl, and my own interoperability work.
Both NMControl and the backwards compatibility solution are “multi-chain” efforts: I’ve been hired by BitShares, the only other major blockchain committing serious resources to a decentralized TLD. I know because I talked to Vitalik Buterin about potential collaborations and Ethereum isn’t interested in working on a decentralized TLD. In addition to the zone exports, we are working on harmonizing standards and porting NMControl to work with BitShares.
If DNSChain’s author wants to collaborate, he could lend a hand with NMControl or help build the trusted server solution I’m working on with Ryan. Greg is obviously great at marketing and has a lot of energy. Even if he doesn’t like programming in Python, there are plenty of other areas he could work with us on. At the very least, they should switch from trusting routers to the zone exports we will be publishing.
Bonus: REST API
DNSChain makes a lot of hay about having a REST API. This is pretty silly: REST is a great RPC for the web because of how it scales, but local clients are better off using a more powerful RPC library, like the one packaged with NMControl. If you must have a REST API for local software, NMControl is adding one4. We are working on with TLS encryption too, if you really want to run your own client/server setup, consider hacking on NMControl.
My point is this: choose the right tool for the job. DNSChain is poorly architected because it’s trying to do everything at once. Our middleware, NMControl has the backing of the Namecoin team and we are working on making it compatible with BitShares and CouchDB has a large team of paid developers behind it. Why build a server and the middleware from scratch?
I agree that there should be a trusted server solution and I’m emulating a solution that has been deployed on a large scale and it offers backwards compatibility with the existing domain name system. The core architecture uses a distributed trust model and is forward compatible with security improvements to internet infrastructure.
The problem with DNSChain is that they persist in making false, grandiose claims about a solution that involves everyone buying a plug-computer or a new router. With DNSChain, we will get a large number of people locked into trusting their home router manufacturer, forever.
DNSChain will say that their model is (now) more secure since a user can change which servers they trust.
This is similar (but not as absurd) to their claim that users will run their own servers. How many people change the default directory authority servers on their Tor client? I’ve talked to Tor developers, they are shooting from the hip when it comes to choosing routers. Unlike Tor, DNSSEC signers aren’t making qualitative decisions on which routers to trust, it’s trivial for anyone to validate the resulting DNSSEC zone file.
DPoS blockchains (like BitShares) control who produces the DNSSEC zone records and (unlike DNSChain) has a mechanism to pay them to perform this public service. While only ~7 servers would be signing off on the DNSSEC records, the rest of the BitShares network can verify evidence of fraud and remove untrustworthy servers.
DNSChain supports a version of public key pinning for all domains. However, security conscious websites should presumably be performing public key pinning on the server side. But, again, if you are willing to install software to improve your security, setting up DNSChain requires at least as much work as installing a lightweight resolver and is also less secure. ↩
Including DNS service providers, ISPs, and router manufacturers. Of course, if you are going to install something locally, you should just use a lightweight resolver. ↩
Again, politics is locking up the details for now. ↩
We actually already have one but the current implementation is insecure. That being said, we’ve peaked at DNSChain’s code and …. ↩