> 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.
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.
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.
