> As a domain admin, you simply get DNSSEC for free if your registrar supports it.
How is a registrar holding your keys in any aspect better than WebPKI right now?
> If you are instead running your own DNS server, you're probably big enough that you can afford spending some time on configuring DNSSEC.
And as the parent comment said, it's complicated and brittle, while offering little benefit. Plus you are still forced to trust your registrar, because it's doubtful you will go into the effort of interfacing with the TLD registry directly.
> How is a registrar holding your keys in any aspect better than WebPKI right now?
In this context, the question is more "how is a registrar holding your keys in any aspect worse?" There are a couple of mostly availability-related risk models where having DNSSEC at all is probably nets negative but your registrar generally has de facto control over your domain under the no-DNSSEC PKI anyway. There is a wide range of viable use-cases where telling your registrar that yeah turn on DNSSEC is nearly free and gets you ... well, the extremely minor benefit of being able to use DNS as a verifiable public kvmap.
> In this context, the question is more "how is a registrar holding your keys in any aspect worse?"
I find it fairly obvious that such an extra operator in the middle of the trust chain between your webserver and your end-user is worse.
> but your registrar generally has de facto control over your domain under the no-DNSSEC PKI anyway.
Yes-ish. The issue is that DANE+DNSSEC would give the registrars control over the keys, which door they belong to and nobody could determine otherwise. A registrar trying to do the same right now with WebPKI would most likely be pathetically caught in the act, either by trying to redirect traffic without a valid certificate or trying to issue a certificate and it getting logged.
The pattern has recurred for over a decade: someone says DNSSEC is, at last, easy to deploy, and then some huge company tries to turn it on and falls off the entire Internet for a day. Last time, I think, it was Slack. I wonder who it'll be this time.
Almost not a week goes by on HN where there's a headline about some well-known company or government organization that did something (or didn't do something) to either get themselves knocked off the internet or were compromised.
While companies screwing up DNSSEC has gotten some companies knocked of the net, it pales in comparison to other reasons for companies getting knocked off the net.
But whatever.
A more nuanced take on the ease of deploying DNSSEC: it's easy to do for the weekend hobbyist working on a side project or a homelab. Or a small organization whose registrar and internet host both support DNSSEC.
Deploying DNSSEC is definitely not easy if you're running at Facebook, Twitter, Apple, etc. scale. There are other reasons too, but there's no need to rehash once again.
> How is a registrar holding your keys in any aspect better than WebPKI right now?
You can use both DNSSEC and HTTPS. And actually, if your registrar and hosting provider are the same (e.g. Cloudflare, AWS), they might hold your keys anyway.
> And actually, if your registrar and hosting provider are the same (e.g. Cloudflare, AWS), they might hold your keys anyway.
Sure, but you have the ability to choose if they're the same or not. Although an untrustworthy registrar right now would be quite bad, it wouldn't trivially compromise the security of your WebPKI TLS connections. One would not be able to say the same if we would have had deployed and built everything on top of DNSSEC+DANE.
How is a registrar holding your keys in any aspect better than WebPKI right now?
> If you are instead running your own DNS server, you're probably big enough that you can afford spending some time on configuring DNSSEC.
And as the parent comment said, it's complicated and brittle, while offering little benefit. Plus you are still forced to trust your registrar, because it's doubtful you will go into the effort of interfacing with the TLD registry directly.