4 ms·

> 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,

> 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 ago
You'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.
- wizeman 4y ago
  If you wanted something like certificate transparency for a DNS PKI, you wouldn't want an exact copy of WebPKI's CT system as it exists right now. That wouldn't work, obviously! That's not the point at all. In fact, a certificate transparency-like system for DNS PKI would probably be a lot easier and more scalable to implement, as you'd need to store a log of at most 1 DNSKEY and/or DS records per TLD per day (as per their usual TTL), or much less actually, because those DNSKEYs don't actually change often, I believe. You don't even need the TLDs' cooperation to do it, as those public keys are publicly available, unlike certificates issued by certificate authorities! You'd then need a way to check that the keys match what you've got from the upstream DNS server. You could probably implement this at the DNS server and DNSSEC resolver level. You'd return an error if the keys that you've got aren't available in the log. You could discard old keys, so a locally-stored copy of the log would be really small and wouldn't keep growing indefinitely. The point is, something like this would be doable and has nothing to do with all the other points I've been making which are a lot more important.
  - tptacek 4y ago
    You're trying, and failing (you don't have all the available keys, because servers can selectively change their responses) to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency, now that you've learned that Certificate Transparency won't work for DNSSEC. You've vindicated my argument.
    - wizeman 4y ago
      > you don't have all the available keys, because servers can selectively change their responses Well, that's the entire point of the log, isn't it? To make sure that everybody is seeing the same keys. If the keys you got from the upstream link in the DNS chain doesn't match the one in the log, you reject them, because you are being spoofed. > to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency > now that you've learned that Certificate Transparency won't work for DNSSEC It wouldn't work exactly like it is, obviously, which is why I've been saying "CT-like" system, not the exact same CT incantation that exists right now which was explicitly designed for WebPKI, not a DNS PKI. Your argument is like saying in the year 2002: "electric vehicles can't possibly work because gas stations are not designed for electric vehicles". Well, not exactly a sound argument you have there, now is it? :) > You've vindicated my argument. I highly doubt that :)

tptacek 4y ago

You'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.

wizeman 4y ago
If you wanted something like certificate transparency for a DNS PKI, you wouldn't want an exact copy of WebPKI's CT system as it exists right now. That wouldn't work, obviously! That's not the point at all. In fact, a certificate transparency-like system for DNS PKI would probably be a lot easier and more scalable to implement, as you'd need to store a log of at most 1 DNSKEY and/or DS records per TLD per day (as per their usual TTL), or much less actually, because those DNSKEYs don't actually change often, I believe. You don't even need the TLDs' cooperation to do it, as those public keys are publicly available, unlike certificates issued by certificate authorities! You'd then need a way to check that the keys match what you've got from the upstream DNS server. You could probably implement this at the DNS server and DNSSEC resolver level. You'd return an error if the keys that you've got aren't available in the log. You could discard old keys, so a locally-stored copy of the log would be really small and wouldn't keep growing indefinitely. The point is, something like this would be doable and has nothing to do with all the other points I've been making which are a lot more important.
- tptacek 4y ago
  You're trying, and failing (you don't have all the available keys, because servers can selectively change their responses) to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency, now that you've learned that Certificate Transparency won't work for DNSSEC. You've vindicated my argument.
  - wizeman 4y ago
    > you don't have all the available keys, because servers can selectively change their responses Well, that's the entire point of the log, isn't it? To make sure that everybody is seeing the same keys. If the keys you got from the upstream link in the DNS chain doesn't match the one in the log, you reject them, because you are being spoofed. > to design a transparency scheme for the DNS PKI, one that does not currently exist, which is deliberately different than Certificate Transparency > now that you've learned that Certificate Transparency won't work for DNSSEC It wouldn't work exactly like it is, obviously, which is why I've been saying "CT-like" system, not the exact same CT incantation that exists right now which was explicitly designed for WebPKI, not a DNS PKI. Your argument is like saying in the year 2002: "electric vehicles can't possibly work because gas stations are not designed for electric vehicles". Well, not exactly a sound argument you have there, now is it? :) > You've vindicated my argument. I highly doubt that :)