DNSChain 0.5 released, brings full HTTPS support, Openname Resolver API and more
blog.okturtles.com
blog.okturtles.com
> 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).
What are you referring to?
> 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.
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:
https://github.com/okTurtles/dnschain/blob/master/docs/What-...
> 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?
That sounds like it would have similar/identical properties to HPKP, which we cover here:
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
> 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:
https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i...
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?
Note: I am involved in the Namecoin project, and we do not endorse DNSChain in any way.
Is that a typo (i.e. you do not endorse DNSChain in any way)?
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.
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.
Maybe take a look at Ethereum or Blockstore if you want to do that.
>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.
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:
https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i...
> Many thanks for all the various answers, I now have a much clearer picture of what dnschain is, and isn't.
No prob. Thanks for saying thanks. :)
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).
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.
They'd need to validate on initial registration, yes, but after that there's no reason (that I see) for them to validate again against DNS.
Relevant proposal: https://forum.namecoin.info/viewtopic.php?f=5&t=1439
> I've seen no plausible proposal on how to do that without introducing significant risks of forking the blockchain.
I haven't heard a compelling argument as to why it would introduce "significant risk" of a fork. Define significant.
* 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.
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.
> 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.