6 ms·

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

> 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.
  - ryan-c 12y ago
    > 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.
    - itistoday2 12y ago
      > 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.
      - e12e 12y ago
        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).
        itistoday2 12y ago
        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.
  - e12e 12y ago
    >> 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.
- ryan-c 12y ago
  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.
  - cstrahan 12y ago
    > and we do endorse DNSChain in any way. Is that a typo (i.e. you do not endorse DNSChain in any way)?
    - ryan-c 12y ago
      Whoops. Fixed.
ryan-c 12y ago
> .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.
- itistoday2 12y ago
  > This would require miners to somehow validate ownership at time of registration and on every update. 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 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.
  - ryan-c 12y ago
    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.
    - itistoday2 12y ago
      > 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.

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.
- ryan-c 12y ago
  > 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.
  - itistoday2 12y ago
    > 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.
    - e12e 12y ago
      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).
      - itistoday2 12y ago
        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.
- e12e 12y ago
  >> 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.
ryan-c 12y ago
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.
- cstrahan 12y ago
  > and we do endorse DNSChain in any way. Is that a typo (i.e. you do not endorse DNSChain in any way)?
  - ryan-c 12y ago
    Whoops. Fixed.

ryan-c 12y ago

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

itistoday2 12y ago
> This would require miners to somehow validate ownership at time of registration and on every update. 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 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.
- ryan-c 12y ago
  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.
  - itistoday2 12y ago
    > 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.