5 ms·

I think the central thing here is you need to trust the DNS anyway. If you control a domains DNS records you can get a Cert issued for that name under the exis

I think the central thing here is you need to trust the DNS anyway. If you control a domains DNS records you can get a Cert issued for that name under the existing WebPKI. Given that scenario the current CA setup just adds many more entities that need to be trusted on top of that. > (you can't generally get signed name directly off the root) Yea you can (unfortunately IMO.) Just stump up the money. Most people have no need for that though. > browsers have no real influence with DNS registries. I’m not sure why the browser vendors being in control of this is so much better than ICANN. Google has undue influence here IMO. > They can kill misbehaving CAs, and have done so, to some of the largest CAs. But they can't kill a DNS registry; I think the difference is that the DNS hierarchy means only one set of published records exist for a domain. It’s not like the Web PKI where other certs can be issued I parallel by other CAs. > they can't even move their own names off a registry they don't trust (customers are going to keep hitting Google.com no matter what Google says). I’m not that familiar with all the processes here, but this seems like an abuse of a registrars power. Surely the gtld servers can stop delegating zones to bad actors? Have there been historical examples of something like google getting hijacked by their DNS registrar? > append-only cryptographic ledger (CT) that tracks every certificate issuance. That system doesn't exist for DANE As conflicting records can’t exist it’s trivial for an entity to monitor the published records for their domain, and alert on changes. > it doesn't work (for instance: large numbers of middleboxes won't pass DANE queries). That is true for many things. I don’t find it a good argument against protocols themselves.

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 ago
    Every 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.

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 ago
  Every 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.