It certainly feels like the wrong way of solving problems (ramming more into the domain registry always seems like a bad option). Is the technology dead or destined to fail?
Edit: rationale: dnssec solves domain validity, but https tls solves almost the same problem but has better backing (azure said they don’t support dnssec and recommended tls as a better alternative). Dnssec also does not solve bgp hijacking, which combined with ip based tls signing servers moots any value dnssec has - sure you could registrar lock your domain via dns (preventing letsencrypt signing things), but if a threat actor has the capability to bgp hijack to perform such an attack and is targeting you, you probably have bigger issues elsewhere.
Both BGP and certificate issuance have bootstrapping problems, which are handled today by imperfect TOFU-like solutions. DNSSEC is, IMHO, perfectly positioned to solve both of those problems. I.e. use certificates all you like, but verify them by looking up the TLSA record in the DNS using DNSSEC. No need to trust CAs. BGP could possibly use the same solution, using the reverse lookup .arpa DNS space.
DNSSEC is the building block from which secure certificates and BGP routes can be built, without the ad-hoc CA system we have today.
If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit, as it has done in the past with other major CAs. Google can't do anything about .COM mis-signatures.
Thankfully, practically none of .COM is signed.
Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.
Compare to DNSSEC which are designed to have single supplier. If a TLD registrar goes bad, what is going to happen? Moving to a new TLD is a huge deal, and affects everyone, including your customer. And browsers can't really ban an entire TLD like they ban CAs.
So yes, both CAs and DNSSEC have some problems. But one of them is pretty good and getting better the time (deprecation of old crypto, short-expiration certificates) while the other is stuck with ancient crypto, constant technical outages, and no chance of improvement.
For ccTLDs you could hope, especially if you are a citizen of the country encoded and it's a democracy, that you can vote for governments who require the TLD registrar to meet your needs. Will that work? Well, no worse than them ensuring adequate drinking water and that sort of thing.
TLDs seem primarily to be chosen for existing popularity, so no matter how badly COM is run, people will insist they want a .com domain, and then complain about how badly the TLD is run. I don't see DNSSEC ever making that substantially worse.
Suppose you paid $50 last year for theamk.example - what sort of abuses could the example TLD already do - ignoring DNSSEC entirely ?
Somebody has decided to register the\u{0251}mk.example, the\u{0431}mk.example and now the\u{ff41}mk.example - your TLD's policies say that they take this sort of thing "very seriously" and they try to ensure that after they've been paid in full for the domains they get around to removing these bogus sites used to attack your customers just as soon as you file the necessary paperwork, plus 90 days admin.
They might tell you that somebody else offered them $5000 for theamk.example and so too bad now it's not yours any more. Can you fight them? Yeah, and eventually you might even win, but meanwhile your domain isn't working. I hope you didn't need that.
Oops due to an "error" theamk.example just doesn't resolve any more. Don't worry though, they aim to fix such errors within 45 days. Or you can pay for $25 Expedited Support ?
Oh no, apparently "Theamk Inc." in Beijing says you are squatting on their rightful trademark which they registered last week in Bulgaria apparently. The TLD registrar has decided to immediately transfer your domain to them.
As with any PKI, the RPKI isn't effective if you don't use it, or if you use it in a merely advisory capacity and then routinely ignore its advice. And as with DNSSEC of course if you actually use this technology and people screw up (which will happen) there are outages, which would not have happened if you used no security technology.
In addition though, RPKI signifies business arrangements and so you can imagine real world policies may vary slightly from what RPKI says. For example, suppose you're a Canadian ISP and Big US ISP A says they're not going to use Long Haul provider X any more from Thursday. Sure enough the RPKI entries for ISP A via provider X expire after Wednesday. As of 00:05 on Thursday, 40% of routes for ISP A on your systems transit provider X. Should you kill those? Your customers would perhaps be pretty angry if the ISP A CEO later clarifies that "obviously" they meant from start of Business Hours. How about at 12:00 midday? How about the Monday after ? What if two months after this announcement, having left these routes in place you discover provider X were hijacking ISP A traffic and this was never merely a mistake, it was leverage ?
If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server.
If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.
This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.
Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure.
The relavant security thing for bgp is called rpki.
So you either accept that TLS is the global maxima for security and world governments can basically permanently compromise the internet, or you build private PKI systems, or you want something like DNSSec. And DNSSec is something like DNSSec.
With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it.
While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.
Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.
The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
Users who are concerned about a government like the United States can use DNSSec to prevent a threat like this by using a non-US based TLD that employs DNSSec, and by running their client in a mode that requires valid DNSSec records for their domains. Of course, such services would practically need to be located outside of the country of concern as well.
If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
I don't check or audit my CA's and don't think most people do either. Wouldn't be surprised if more than one of these has been compromised in some fashion already. It only takes one and there's plenty to target.
The next thing you'd need is a mitm attack and again that's entirely possible for a nation state to pull off at scale.
Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially additive that is in widespread use today (DNSCrypt). ¯\_(ツ)_/¯
I'm only half joking.
Google is very enthusiastic it seems about things which force users to use Google Chrome, and very unenthusiastic about users doing anything easily from the command line because it has the notable quality of removing a place you can show ads.
And what I note about the whole OAuth ecosystem is that you wind up having to puppet a web browser in order to get through sign-ins and the like. "Oh but you do it infrequently" says every single company implementing their own bespoke way of entering a username, password and TOTP while salivating at all that unused <div> space for ads.
What else would we expect from an advertising company.
The story of Ethernet is kinda interesting. Invented in 1974 at Xerox PARC, the inventors started a new company called 3COM in 1979, and worked with IEEE, as well as DEC, Intel, and Xerox (called the DIX - I'm not kidding) for all of them to join forces and support one new standard. IEEE project to standardize it started in 1980, and formal standard publication happened in 1983. International (ISO) publication was in 1989.
Business decides what becomes the new standard, because the biggest businesses are whom everyone is dependent upon. So the biggest companies do set the new standards. Google has been doing that for years, using its search market dominance and custom browser as carte blanche to shape the web as it sees fit. CloudFlare has come in the back door, and doesn't have anywhere near the same influence, but does control a powerful market segment that is growing. Add in the cloud providers, and that's most of whom actually matter in terms of where the web goes.
Where the "internet" (sans web) goes is, I think, more up to the operating systems and ISPs. But since everything has been pushed into the web to avoid the manipulation of the "middle boxes" (ISPs and corporate networks), the end result is the people who control 'the web' (Google and CloudFlare) can now dictate terms.
Same cars has issues with drivers being locked inside if the car goes into the water. That is a bug.
Is the solution to abandon locks on cars, or is the solution to fix the problem of the car doors staying locked when submerged into water? The security system by now is fairly advanced and addressing issues with accidents is a real problem. No one however would sell cars without locks.
The natural progression is for hijackers to then carry buckets of water or spray cans and target the sensors that detect a water scenario.
The difference is that DoH protects transactions and DNSSEC protects the authenticity of records. It's perfectly possible for a DoH server to feed you bogus cached records; you have to trust the DoH server you're talking to, where you wouldn't have to do that if all the records on the chain of lookups you're doing are signed with DNSSEC, and you're running DNSSEC on your local system rather than a stub resolver than talks to full resolver server you have to trust (this is an uncommon set of circumstances and in practice you have exactly the same server trust problem with DNSSEC that you do with DoH).
Muddying the waters further, the attacks DNSSEC protects against overlap with the ones DoH protects again, so that if the whole Internet managed to switch to DoH, you'd have bottom-up built 95% of the security feature DNSSEC is attempting to provide (DoH has massively better deployment stats than DNSSEC, so this is plausible).
It's better to think of DoH as one of a catalog of different arguments that together make a clear case for sticking a fork in DNSSEC and calling it done.
With DNSSEC, I know that anyone asking for IP addresses of my web server will get the correct address, and in the future it may be possible to use TLSA records (and/or HTTPS records) so that the user’s web browser can be certain that it is connecting to the correct site, with the correct key. The only weak point is that the user might be using a DNS resolver which may be correctly checking the DNSSEC signatures, but the DNS replies, sent from the resolver to the user, are not signed, only “authenticated” by the AD bit. (This is where DoT – or even, blech, DoH – might actually help.) Or the user could run their own local resolver with no untrusted path between their device and their resolver, closing the gap completely.
Contrast that with using no DNSSEC, only DoH (or DoT). The user asks the resolver for the IP address (and possibly HTTPS/TLSA records), and the resolver asks the authoriative DNS server for the information. But the whole conversation between the resolver and the authoritative DNS server is completely unsigned, and can be manipulated at will by any middlemen. Also, it is not even TCP (which is hard, but not impossible) to manipulate as a man-in-the-middle, but DNS is most often UDP. But let’s say there is no manipulation here. How do you trust the identity of the resolver? Because they have a nice certificate from “Honest Achmed's Used Cars and Certificates”¹, which says they they are indeed the DoH resolver the user has configured? The same problem also applies to the web site certificate; how can you trust it, when any CA in the world can issue any certificate at will?
For more fun diving into this topic, I can recommend a famous old presentation called the "Everything you Never Wanted to Know about PKI but were Forced to find out", and godzilla crypto tutorial written by the same author (Peter gutmann). The certificates in browsers has had a long history of problems and ill designs. People did not like them, and they definitively did not like them when they caused major issues.
Supplementary question: Why do so many sites these days opt for tiny font-sizes in some shade of pale-grey on white?
