4 ms·
> Currently Verisign can't sell certs directly, and would be caught by a CT log/report if they hijacked DNS to do this. And then what? Like you said, browsers
by wizeman 4y ago
> Currently Verisign can't sell certs directly, and would be caught by a CT log/report if they hijacked DNS to do this.
And then what? Like you said, browsers can't remove Verisign for abuse of trust, because Verisign isn't part of their roots of trust.
And they can't remove the certificate authority who issued the certificate because 1) the certificate authority is not at fault in that scenario, and 2) Verisign could just use another one to issue a new certificate.
Whatever answer you give here would apply to DANE as well.
> If DANE was used, they could do whatever they want
See above: they can already do whatever they want, so you wouldn't be leaning on them more than you are right now.
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
We already have a centralized system of trust, called the DNS system. It's just that currently it is still relatively insecure (DNSSEC is not widely deployed yet), so we have another fake security layer on top of it (the CA PKI system) which, because it's backed by Google and other organizations that people like so much, for some reason people trust that layer even though its security depends on the security of DNS and is actually even more flawed (since it has even more points of attack).
> DANE is setting up a centralized system ripe for monopolistic abuse, where there are no checks and no consequences for fucking up.
You can implement a CT-like system on top of it which would give you more transparency regarding what certificates are being used (where clients, rather than certificate authorities, would publish new certificate fingerprints to CT logs or even directly to some server managed by the domain owner).
But of course, the real issue is how to deal with Verisign if it starts hijacking domains, but this is already exactly the same problem we have today with the CA PKI system.
- tptacek 4y agoYou cannot implement a CT-like system on top of DNS. You've said that a couple times in the thread, but ignored the reasons why it won't work for DNS. It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates. You have to understand how CT works before you (a) dismiss it, like someone else did upthread when they claimed CAs can just ignore CT, or (b) assume it trivially ports over to DNS.
- wizeman 4y ago> You cannot implement a CT-like system on top of DNS. [citation needed] > It only works in the WebPKI because browsers are able to force CAs to participate, by distrusting CAs that don't include SCTs in their signed certificates. So? In a DNS PKI system, browsers would already distrust ALL CAs. So by that argument, it's in a much better footing to begin with. What's happening is that you're thinking that in a DNS PKI system, TLD operators like Verisign would be equivalent to certificate authorities. Except that they wouldn't, because Verisign couldn't create rogue certificates for other TLDs like certificate authorities can. And even if Verisign could create rogue certificates for .COM domains, this is already something that they can do today with the WebPKI system in place, since they can hijack any .COM domain at any time. And even if Verisign is caught hijacking a domain to create rogue certificates with the WebPKI system, the browsers can't do anything about it, because Verisign is not part of their roots of trust. So basically, you wouldn't be any worse than today (because Verisign can still attack your domain, regardless) but you'd certainly be much better, because you wouldn't have to keep a database of certificate authorities from all over the world who can create certificates for any domain in the entire world. Oh, by the way, we're talking about a database of fully-trusted authorities that even if they are caught in any wrongdoing, can never actually be distrusted (like you mention) in hundreds of millions of deployed systems out there who might take months or even years to update, or worse, who never update (Android devices, IoT devices, etc).
- tptacek 4y agoYou're not saying anything here. What I think has happened in this thread is that at least a couple of people have determined for themselves that CT is something CA's opt into, and that they can just randomly decide to issue certificates that aren't logged. But that's not how CT works: it's a continuous log of everything issued, and you can't skip entries. If you spot a certificate without an SCT tied to the log, you have dispositive evidence of misissuance, and you kill the CA. You need all the pieces of this system for it to work: not just the log, but the SCTs (which don't exist in the DNSSEC protocol, and which browsers can't compel). All you're saying at this point is that CT doesn't, in your opinion, matter. But now you're contradicting your own argument, which was, previously, that DNSSEC can easily copy CT to do DNS PKI transparency.