Then, when you have only two or three big SSL providers, it's way easier to shut someone off by denying them a certificate, and see their site vanish in mere weeks.
(2) It's much slower than the TLS WebPKI.
(3) There's no transparency log and never will be, both because it hasn't been designed and because Google and Mozilla basically had to mug the WebPKI CA's in a dark alley to make CT happen.
(4) It requires you to set up DNSSEC, which is so error prone that some of the largest engineering teams in the world have managed to take their sites (and also countries) offline.
The thing about DNSSEC is that once you turn it on, it's a king-hell pain in the ass to turn it off without incurring an outage. DNS providers know this, and they know ops teams are terrified of DNSSEC, so they push it as a kind of account lock-in tool. There's a reason that the overwhelming majority of large site don't use it.
> (1) It doesn't work reliably, because middleboxes don't pass DNSSEC/TLSA records reliably, so there has to be a downgrade path, so it's strippable.
They need to be fixed but yes it is a real problem from what i've heard. > (2) It's much slower than the TLS WebPKI.
Caching should make it fast enough. Do you have real-world numbers? > (3) There's no transparency log and never will be, both because it hasn't been designed and because Google and Mozilla basically had to mug the WebPKI CA's in a dark alley to make CT happen.
That is an excellent point. Do you have a solution? > (4) It requires you to set up DNSSEC, which is so error prone that some of the largest engineering teams in the world have managed to take their sites (and also countries) offline.
I really don't like DNSSEC myself – i'd rather have seen DNSCurve https://dnscurve.org/ succeed – but at a certain point, i think we just have to go with it.