Is there a clear readme on dnschain somewhere? I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server? Using the public server obviously still leaks metadata (who looks up what when) - not that such metadata isn't rather obvious anyway by observing traffic between ips. How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?).
DNSChain queries blockchains instead of querying DNS servers. The blockchain would have entries inserted by domain owners detailing their information -- functionally, A, AAAA and TLSA records. All the trust is put inside the blockchain. DSNChain allows you to query the blockchain with "traditional" tools, ie using DNS or HTTP queries.
> How is it any better than cacert? Because you pin the trust to your own ca?
There is no third-party to trust between you and the domain you want to visit (again, assuming the blockchain doesn't lie), so you really have the information the domain owner wants you to have.
Well, the blockchian lying is one thing -- another thing is if it tells the truth about lies ("it" has been lied to).
I suppose my confusion stemmed from the fact that dnschain is two things: a way to secure data, and an infrastructure for registering data. Apparently there's no trust at the point of registration, which means the whole thing is entirely untrustworthy from a certain point of view (I don't necessarily thing this is a bad thing/feature -- it's just that without any form of vetting, there can be only a certain "kind" of trust), on the other hand if you trust the registration, you can trust your queries to return data that has been registered.
With the/a CA system, you can trace trust trough keys back to organizations/individuals (that either act in bad faith, or has been compromised) -- but detecting such bad behaviour is out of scope of the CA system.
Currently DNSChain supports reading from blockchains. Writing is planned for a future release.
> Apparently there's no trust at the point of registration, which means the whole thing is entirely untrustworthy from a certain point of view
Trust is not involved "at the point of registration", unless you are referring to trusting a central authority for registering .gov's or something like that (which can be done on a blockchain as well).
Why are you reimplementing so many layers? Is it not possible to just provide dns resolution and cert pinning via the blockchain, and avoid having to deal with anything HTTP related? Seems overly specific to HTTP for no good reason.
> Is it not possible to just provide dns resolution and cert pinning via the blockchain, and avoid having to deal with anything HTTP related? Seems overly specific to HTTP for no good reason.
Might be misunderstanding you, but DNSChain is providing DNS resolution and "cert pinning" via the blockchain (the certs in the blockchain can be trusted pretty much as though they were pinned).
The HTTP aspect of it is so that arbitrary applications can provide user-friendly MITM-proofed communication.
In terms of securing communications, DNS is irrelevant. You can spoof DNS IPs all you want, but what ultimately secures the connection is the certificate that you receive, and that's queried over TLS/HTTPS.
Ah, ok, the HTTP proxy thing is just there for ease of use. That seems reasonable then. Pity it has to use a blockchain approach, but scalable cert pinning might just be worth it.
> I looked at the github repo, but still don't quite get what actual benefits it brings over running one's own dns server?
A traditional DNS server does not give you access to blockchain-based domains. Blockchain TLDs (like .bit) can be MITM-proofed. DNSChain also lets you communicate with blockchains over a MITM-proof HTTPS connection:
> not that such metadata isn't rather obvious anyway by observing traffic between ips.
Tor is your best option if you want complete anonymity. DNSChain does have a planned feature called Unblock, which is effectively a DNS-based proxy that hides metadata as it travels between client and DNSChain, but if you want the best anonymity you should still use Tor.
DNSChain is a secure PKI solution (alternative to X.509), the primary purpose of which is to securely and simply distribute public keys, as that's what provides protection from MITM attacks.
> How is it any better than cacert? Because you pin the trust to your own ca? What stops you from doing that now (how is the trust different with dnschain?).
CACert is a CA. You can certainly design your software to only trust certificates from one CA, but that is only useful in special-purpose situations, it's not going to work for general purpose browsing.
In X.509, everyone on the Internet is forced to trust the weakest link, and security decreases for everyone with the more CAs there are. The opposite is true with DNSChain-based PKI, where the more independent servers that are queried, the more certain you can be of the authenticity of the response. If you completely trust a particular DNSChain server, then it's the only server you need to query.
> If you completely trust a particular DNSChain server, then it's the only server you need to query.
I guess this is the part that is still unclear to me: How is this different from a curated list of pinned certs coupled with a ca cert store that holds only my own ca cert? How can/why should I trust a dnschain server to validate google.com? Because there is ample evidence in the blockchain that others have been tricked by/trusted a particular key/cert for google.com?
> I guess this is the part that is still unclear to me: How is this different from a curated list of pinned certs coupled with a ca cert store that holds only my own ca cert?
That sounds like it would have similar/identical properties to HPKP, which we cover here:
> How can/why should I trust a dnschain server to validate google.com? Because there is ample evidence in the blockchain that others have been tricked by/trusted a particular key/cert for google.com?
As mentioned in the article (and in a footnote therein), .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain.
If you do not trust a DNSChain server, do not use it. Use only the server(s) you trust, and then you can trust the data in the blockchain. The data in the blockchain, meanwhile, is secure from MITM attacks as explained in more detail here:
> Use only the server(s) you trust, and then you can trust the data in the blockchain.
Ok. So essentially it trades trust-on-first-use with trust-on-first-registration? That is, you implicitly trust that whomever registers example.bit first, is the "correct" owner?
This is of course quite a lot better than TOFU, in that if you trust that you have access to the (correct) blockchain, the only room for injection is at registry time (modulus the 30 min window as discussed in the links), rather than simply mitm the connection at the time of first use?
And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation?
Namecoin's .bit registration process involves a blinded commitment step to prevent front running at time of registration. Also worth noting that the names expire after ~8 months if not renewed. Whomever has the private key for the most recent update to a .bit domain is the "owner" - not sure what you mean by "correct". On a technical level Namecoin names are essentially named colored coins with associated data that eventually expire if not updated.
Note: I am involved in the Namecoin project, and we do not endorse DNSChain in any way.
> Ok. So essentially it trades trust-on-first-use with trust-on-first-registration? That is, you implicitly trust that whomever registers example.bit first, is the "correct" owner?
Well, that is just how names work. Google was the first to register google.com, and now you "trust" that google.com belongs to them.
The blockchain is no different, except that it gives you even more reason to trust that the ownership hasn't changed.
> the only room for injection is at registry time (modulus the 30 min window as discussed in the links), rather than simply mitm the connection at the time of first use?
Right, and registry time isn't really an attack. It's a legitimate registry.
Someone could register google.ninja right now, but you wouldn't trust it because Google has established the .com (via word of mouth and links, essentially) as the de-facto website.
> And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation?
Sorry, not sure I understand what you're asking there.
> Well, that is just how names work. Google was the first to register google.com, and now you "trust" that google.com belongs to them.
You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers.
> You trust that google.com belongs to Google because you trust the DNS root zone to tell you who runs .com, and trust .com to tell you who runs google.com which tells you to talk to Google's servers.
Yes, that is how DNS works. I was referring to simply the notion that Google registered google.com.
Right. But eg: .no domains are linked to a tax/org [ed:code/registration number] (or used to be, anyway). And generally you can't just go and claim to be "The Norwegian Parliament".no (or whitehouse.gov). So a registry that's strictly first come, first serve, does not work like DNS (or the CA system for that matter, despite all it's flaws).
That's true. The point is to secure the connection. If you wanted it, you could create a blockchain that's secured in a decentralized fashion, but upon which registrations depend on a central authority. That way you could have .edu/.gov names that are both MITM-proof and are not first-come first-serve.
Maybe take a look at Ethereum or Blockstore if you want to do that.
>> And bootstrapping trust into the blockchain is basicially by trusting the ca-cert/github documentation?
>Sorry, not sure I understand what you're asking there.
How do I know what the "correct" blockchain is? That I'm not dealing with a fork?
Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't.
Some of my confusion was related to how/if dnschain is different from just running one's own dns infrastructure (and ca infrastructure, and ripe...). That data is anchored in the blockchain is all well and good, but that only gives some kind of consensus.
It's also interesting to know what that consensus actually tells you. Like does it imply any kind of vetting, or just first-come, first-serve.
> How do I know what the "correct" blockchain is? That I'm not dealing with a fork?
Ah, well, my friend, you should dive deep into the world of blockchain consensus, of which much has been written on.
Different blockchains use different consensus models. Namecoin and Bitcoin use the same one: proof of work via hashing. It's what prevents forks from happening (well, that and the block reward). Malicious forks can also happen via censorship, but as I explained in a previous link to a reddit comment, proof of work allows you to detect such attacks. Here it is again for your convenience:
But there's still a bootstrap issue? If mr. evil is mitm me, before I can start namecoind [ed: for the first time] -- I need to bootstrap into the block? (This isn't entirely hypothetical, think running dnscoin on a laptop for local resolving, and you don't trust your home ISP).
But I assume you can bootstrap with the usual methods (eg: your OS come with the cert of at least once CA you trust, so you can use tls/ssl, or you can connect to a known, trusted ssh host etc).
> .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain.
Trying to "import" domains from traditional TLDs into a blockchain really isn't a good idea. This would require miners to somehow validate ownership at time of registration and on every update. I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain.
I have seen that proposal, I do not consider it plausible, and the reasons it would cause fork issues are addressed in the thread there.
* Pool A mines block trying to import example.com, and validates ownership via TXT record.
* Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons.
Making blockchain validation depend on external data is trouble.
There was a web of trust/voting scheme proposed as well, but nothing fleshed out, and any votes based on coins held are unusable because a single party (my best guess is BTCe) holds at least a third of all NMC ever mined.
> Pool B must either trust Pool A is right (e.g. not evil and not fooled) or verify Pool A's block itself. Pool B tries to validate example.com, and is unable to because someone saw the import attempt and began a DDoS on example.com's name servers, or because example.com is trying to fork the chain on purpose, or because Pool B's ISP is censoring example.com or any number of other reasons.
Ah, good point, sorry I must have missed that in the thread. That's actually a significant roadblock to importing names, so I'll update the post accordingly, thanks.
>> .com's cannot be MITM-proofed in a practical manner, unless they imported into a blockchain.
> Trying to "import" domains from traditional TLDs into a blockchain really isn't a good idea. This would require miners to somehow validate ownership at time of registration and on every update. I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain.
You could import a domain into a blockchain using DPoS, with some number of delegates agreeing on a published DNS record over a given period of time. An attacker's ability to disrupt the process is limited by their ability to disrupt the publication of DNS information more generally.
> Making blockchain validation depend on external data is trouble.
This gets closer to the real problem. You are basically using the blockchain to perform triangulation of cryptographic information which is ultimately controlled by a third party. Throwing that information on the blockchain doesn't make it magically impervious to MITM attacks.
> Will this be a problem for low-end phones? Why not ECC certificates?
That's a great suggestion, thank you. I chose to use RSA because it has excellent browser support and I don't know how good the browser support for ECC is. If anyone has any useful links/info on this I'd appreciate it very much. Note that you can of course generate and use whatever sort of key/cert pair you'd like.
https://www.ssllabs.com/ssltest/clients.html is a good resource. For reference, the clients listed there that don't support ECDSA are: Android 2.3.7, IE 6 / XP, IE 8 / XP, Java 6u45, and OpenSSL 0.9.8y.
Clients supporting ECDSA certificates advertise it via a TLS extension - some server software can actually serve up a RSA or ECDSA certificate depending on what the client claims to support.
