Blockchain-based solutions like Namecoin & DNSChain would have prevented this attack without forcing people to rely on untrusted third-parties (if Google stored their domain info in a blockchain).
We compare various mechanisms here:
https://github.com/okTurtles/dnschain/blob/master/docs/Compa...
EDIT: Not sure why this comment is getting downvoted. Maybe some folks don't want this problem to be fixed? :-\
The only derivative of Convergence that actually addresses the problems with Convergence (ironically), is FreeSpeechMe, which btw, relies on Namecoin's blockchain.
But downvote me again for pointing out facts. lol.
The last time I brought this up you admitted there was no good solution yet, has that changed?
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).
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.
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/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.
Better in what way?
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. :)