3 ms·

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

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

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