3 ms·
> Some see the current DNSSEC costs simply as teething problems that will reduce as the software and tooling matures to provide more automation of the risky pro
by teddyh 3y ago
> Some see the current DNSSEC costs simply as teething problems that will reduce as the software and tooling matures to provide more automation of the risky processes and operational teams learn from their mistakes or opt to simply transfer the risk by outsourcing the management and complexity to larger providers to take care of.
> I don’t find these arguments compelling. We’ve already had 15+ years to develop improved software for DNSSEC without success. What’s changed that we should expect a better outcome this year or next? Nothing.
We’ve had the X.509 certificate infrastructure for 30+ years, and it’s only recently become mostly safe and automated enough for people to deploy without risk. (This includes new risks, like accidentally sending HSTS headers with too large timeouts to the world.) DNSSEC will get there, too.
- viraptor 3y agoI'm not sure what you mean about deploying without risk only recently. X509 without extra recent additions like hsts could never lock out your users for extended periods of time. If you really messed up in some way, they could still ignore errors and continue while you buy/deploy a new cert. With dnssec you can be down for days by messing up just the very basics.
- teddyh 3y agoYou frequently saw even large sites being down with an expired HTTPS certificate in the past, for days, or even longer. And if you mess up your HSTS headers, what recourse do you have? None, from what I recall.
- viraptor 3y agoIf you get an expired certificate, you can fix it close to immediately. It's all under your control. For dnssec you can't do anything until the cache expires. If the large sites were down for days because of expiry that's their own failures, not because of unexpected complexity.
- teddyh 3y ago> If you get an expired certificate, you can fix it close to immediately. Now you can. But getting a new certificate used to be a slow process. And you could still mess up irrevocably by mis-issuing HSTS headers, in which case you would just have to wait until those time out.
- ignoramous 3y ago> We've had the X.509 certificate infrastructure for 30+ years, a You could argue that because TLS is both free and ubiquitous, DNSSEC is just added burden given the outages. Personally, I don't see BigTech pouring resources, like they do at HTTP/TLS/WebPKI.
- tptacek 3y agoAdding to this: virtually none of the large tech firms have adopted DNSSEC. It's usually news when one of them does, and that news story usually takes the form of that firm dropping off the Internet for half a day because DNSSEC ate them.
- agwa 3y ago> We’ve had the X.509 certificate infrastructure for 30+ years, and it’s only recently become mostly safe and automated enough for people to deploy without risk. (This includes new risks, like accidentally sending HSTS headers with too large timeouts to the world.) DNSSEC will get there, too. The WebPKI didn't improve on its own; it got there largely because web browser makers have high-leverage points to exert influence, which they used to make sure improvements got done. How do you envision DNSSEC getting there?
- 411111111111111 3y ago> it got there largely because web browser makers have high-leverage points to exert influence That's not how I remember it. Unless you excluded google chrome, Microsoft's browsers, and Apples browsers. The change was brought upon by let's encrypt, and Mozilla is the only one of the founders that has a web browser.
- tialaramex 3y agoIt certainly helps that we're moving on from "It's irrelevant" to "Actually this is important and it's bad if it's broken". When would you say that happened for the Web PKI? Not last century when the Web PKI comes into existence for sure. Maybe if you squint you could argue for the Baseline Requirements in 2011 as a starting point ? Or maybe the Ten Blessed Methods which was only a few years ago? The browsers do have leverage over the TLDs, and over the DNS resolvers, in the form of how they choose to treat names and name services. For example check the "trusted resolver" policies at Mozilla and Chrome, which IIRC got big US ISPs to swear off nonsense like injecting bogus results into DNS in exchange for having the browser work with their DNS servers.
- agwa 3y agoBrowsers have leverage over CAs because CAs have to ask browsers to be included in the first place, and because distrusting a CA only temporarily breaks websites until they can switch to a new certificate. What kind of leverage do you think a browser could practically exert over a TLD?