4 ms·

If Google stored their domain info in a blockchain how would anyone know what identifier actually belonged to Google? The last time I brought this up you admit

by ryan-c 12y ago

If Google stored their domain info in a blockchain how would anyone know what identifier actually belonged to Google? The last time I brought this up you admitted there was no good solution yet, has that changed?

nickodell 12y ago
I don't think DNSChain is a feasible project. However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1] If we went a bit further, and required that the certs be in the public log for some minimum amount of time (say 6 hours), that would have made it possible to shut down MCS before they got started. [1] http://www.certificate-transparency.org/ http://www.certificate-transparency.org/
- itistoday2 12y ago
  > I don't think DNSChain is a feasible project. If you want to prevent MITM attacks, it's one of the only options available to you (probably the only realistic option): https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... > However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1] DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
  - nickodell 12y ago
    >DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency. Better in what way?
    - itistoday2 12y ago
      We wrote a blog post to answer this question: https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/ https://blog.okturtles.com/2015/03/certificate-transparency-...
      - nickodell 12y ago
        >The CT spec allows only one SCT to accompany a certificate, making this attack feasible No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32.
        itistoday2 12y ago
        > No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32. I see the wording wasn't very clear, so I removed the word "only" to make the meaning clearer. It now reads: "The CT spec allows one SCT to accompany a certificate, making this attack feasible" Good catch. :)
      - deleted 12y ago
        [deleted]
itistoday2 12y ago
> If Google stored their domain info in a blockchain how would anyone know what identifier actually belonged to Google? The same way they know that Google chose google.com and Twitter chose twitter.com instead of twitter.io or something else. > The last time I brought this up you admitted there was no good solution yet, has that changed? This is referring to something else I think, how to transfer .com's into a blockchain while preserving ownership, is that right? That could be done (if needed) with a centralized registrar whose job it was to vet the ownership of the names upon first registration in some namespace. After the initial registration, control would be transferred to the owner of the domain. This is again, however, specific to the case of migrating ICANN domains (if someone wants to do that).

by ryan-c 12y ago

nickodell 12y ago

I don't think DNSChain is a feasible project. However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1] If we went a bit further, and required that the certs be in the public log for some minimum amount of time (say 6 hours), that would have made it possible to shut down MCS before they got started. [1] http://www.certificate-transparency.org/ http://www.certificate-transparency.org/

itistoday2 12y ago
> I don't think DNSChain is a feasible project. If you want to prevent MITM attacks, it's one of the only options available to you (probably the only realistic option): https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md https://github.com/okTurtles/dnschain/blob/master/docs/Compa... > However, we can reduce the scope of the problem, and just focus on forcing certificates to be public. [1] DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
- nickodell 12y ago
  >DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency. Better in what way?
  - itistoday2 12y ago
    We wrote a blog post to answer this question: https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/ https://blog.okturtles.com/2015/03/certificate-transparency-...
    - nickodell 12y ago
      >The CT spec allows only one SCT to accompany a certificate, making this attack feasible No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32.
      - itistoday2 12y ago
        > No, it doesn't. It describes the format of multi-SCT on page 16, and it explains the rationale for this (basically all of the points you brought up) on page 32. I see the wording wasn't very clear, so I removed the word "only" to make the meaning clearer. It now reads: "The CT spec allows one SCT to accompany a certificate, making this attack feasible" Good catch. :)
    - deleted 12y ago
      [deleted]

itistoday2 12y ago

> If Google stored their domain info in a blockchain how would anyone know what identifier actually belonged to Google? The same way they know that Google chose google.com and Twitter chose twitter.com instead of twitter.io or something else. > The last time I brought this up you admitted there was no good solution yet, has that changed? This is referring to something else I think, how to transfer .com's into a blockchain while preserving ownership, is that right? That could be done (if needed) with a centralized registrar whose job it was to vet the ownership of the names upon first registration in some namespace. After the initial registration, control would be transferred to the owner of the domain. This is again, however, specific to the case of migrating ICANN domains (if someone wants to do that).