> The only (current) real remedy is the nuclear option
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).
> Derivatives of Moxie Marlinspike's Convergence cert plugin that allows you to assign your own trust authorities for verifying signatures. [0]
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.
> 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).
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.
> 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.
>DNSChain/Blockchains already provide certificate transparency (publicly auditable log of certs issued), and they do a far better job of it than Certificate Transparency.
>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.
> 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"
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? :-\