3 ms·
No. What is needed is less centralization, not more. I'll take the US society as an example: having congress, senate, president, courts, military, police, stat
by pierrebai 4y ago
No.
What is needed is less centralization, not more. I'll take the US society as an example: having congress, senate, president, courts, military, police, states, free press (with multiple participants), university etc means that to compromise democracy, you need to subvert many elements simultaneously.
Likewise, having DNS and PKI separate is a plus, as the cert is linked to DNS and finding a web server is done through DNS. To completely fool an attentive user, you would need to both fool their DNS and their pool of trusted certificate (or a single CA).
To increase security, we need more cross-linked layers that each require the other. We need to have more steps and more elements that a crooked player needs to control simultaneously in order to achieve an exploit.
For example, we could require multiple certs, so that you'd need to compromise multiple CA. Although, if you can add one CA to the trusted pool, then you can add 3, so this does not protect against actors that have access to the user's OS. But, on that front, if you got root access to a user's OS, you can do anything. Once you MITM them, you can make a user divulge their credentials. Only a physical fob with its own certs, DNS resolver and hardware-level private key can protect against that.
- deleted 4y ago[deleted]
- jesprenj 4y ago> What is needed is less centralization, not more. I don't think depending on more CAs counts as constructive decentralization. Since every CA is ultimately trusted, the security of our PKI depends on the weakest link in the chain. A single exploited CA is enough to completely invalidate PKI security, whereas separating CAs based on DNS hierarchy means that a compromised CA for .SI would only affect domains under .SI. > To completely fool an attentive user, you would need to both fool their DNS and their pool of trusted certificate (or a single CA). Currently, due to the way domain ownership is verified, a compromised TLD registry leads not only to DNS compromise, but to TLS compromise as well, since domain ownership is verified via DNS by currently trusted CAs (most notably letsencrypt). > We need to have more steps Less steps that form a reliable security chain that can be easily monitored is IMO better for securing infrastructure than having to trust each and every obscure CA. > we could require multiple certs But this would significantly increase deployment complexity. And the domain registry can still lie about domain ownership so it still must be ultimately trusted.
- tptacek 4y agoEvery CA isn't equivalently trusted. One thing that tends to happen in these discussions is that people start with a set of axioms based on the circa-2002 era WebPKI, and just build an argument from first principles. That doesn't work. There has been a sea change since then in how browser root programs are managed.