5 ms·

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

> 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: https://github.com/okTurtles/dnschain/blob/master/docs/What-is-it.md 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.

e12e 12y ago
Thank you for a concise and clear response! > 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?
- itistoday2 12y ago
  > 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: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#tack--hpkp 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_idea_for_fixing_https_with_a/cp211ng https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i...
  - e12e 12y ago
    > 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?
    - itistoday2 12y ago
      > 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.

e12e 12y ago

Thank you for a concise and clear response! > 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?

itistoday2 12y ago
> 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: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md#tack--hpkp 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_idea_for_fixing_https_with_a/cp211ng https://www.reddit.com/r/privacy/comments/2xjy13/love_this_i...
- e12e 12y ago
  > 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?
  - itistoday2 12y ago
    > 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.