51–60 of 181 posts
Earlier quoted context omitted.
Fortunately, New Zealanders benefit from all of the problems solved by DNSSEC.
Isn't DNSSEC basically obsoleted by DoH?
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). ¯\_(ツ)_/¯
DNSSEC is easily the worst upgrade, multiplying complexity and brittleness, with the least amount of net benefit (without even adding encryption), that could have been solved in much simpler ways, that the Internet has ever attempted -- and that's including IPv6 (which is now quite workable). Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially add…
I'm only half joking.
Earlier quoted context omitted.
Where what matters? On-path DNS attacks occur everywhere across the Internet, and are probably more common on the lookup side and at the edges. Certainly, the use of DoH to protect authority transactions isn't common, yet!
The most devastating and primary attack I am worried about is someone obtaining a TLS certificate for my domain via services like Let's Encrypt. Thus, I really care about LE getting the right IP, I don't care about random users' DNS getting hijacked because their browser will reject the missing/invalid certificate.
Meanwhile if DNSSEC's vision is ever fully realized, you will lose that control entirely. There is no CT there, and even if it was build somehow it will be useless as it has no "teeth".
In 2020 I scraped fortune top 500 companies for dnssec and found iirc one domain using dnssec. 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 dnss…
When criticizing DNSSEC, you can’t assume that the system for TLS certificates – i.e. CAs – is perfect. They both have their weak points and drawbacks. 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 r…
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 ?
DNSSEC is easily the worst upgrade, multiplying complexity and brittleness, with the least amount of net benefit (without even adding encryption), that could have been solved in much simpler ways, that the Internet has ever attempted -- and that's including IPv6 (which is now quite workable). Speaking as someone who most people consider a DNS expert and actually did help develop and deploy something substantially add…
At this point it feels like DNS should be given to Cloudflare or Google and let them design it from scratch. 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 space for ads.
Earlier quoted context omitted.
If we follow this analogy further, why should we keep the concept of car doors if particular car locks can be made with bugs in them? Doesn't the possibility of bugs in locks means that there will always be a risk, even if we abandon specific locks that has demonstrated to have a bug in them?
We should keep the locks that work and don't cause other problems, and ditch the other ones. Again, seems simple.
Solutions exist within problem spaces, or "paradigms", a car lock is only useful for a specific set of things i.e. deterring thieves or unwanted entry e.g. at stop lights.
What I really want is a force-field to keep people and highway debris out while driving around, and a secure storage solution while not in operation.
If you could sell me a force-field car with a retracting tent, and it were safer/had less issues, I might not care to have locks on my car.
See also - door-less/open air vehicles. Car door locks have some pretty serious issues. There are some problems they just can't solve.
Earlier quoted context omitted.
Isn't DNSSEC basically obsoleted by DoH?
Let’s say I operate my own authoritative DNS servers and my own web server. Which I do. 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 m…
Which is where you get to the crunch point though: this is not a digital problem, it's a social problem. The way you establish trust is by generating a suitable preponderance of evidence that someone is who they say they are.
On the internet we outsourced this to a couple of big players who broadly benefit from decent standards, but the ultimately it is just "might makes right" - Google says they don't like you, your business ceases to exist.
The trouble is some of our standards in this area are complete junk and so widely implemented they're near impossible to change - i.e. why CA certificates don't have a limited domain scope (technically yes, they can, but it's an extension and a lot of implementations don't check it to the point you can't rely on it at all).
IMO this is where open-source and it's anti-government bent has to some extent done a huge disservice to the internet. The vast majority of internet traffic people need to be "no questions secure" is traffic that interacts with government or government-recognized entities and their associated legal systems. The identity people are trying to establish is most frequently "Are you under a legal jurisdiction providing me recourse if dealt with unfairly, and honestly representing yourself?"
Which incidentally is why I wish like hell the Signal project would create a paid enterprise offering to fund itself. I want my bank to use Signal to send me things, and I want some assurances around proving that's who it is.
Earlier quoted context omitted.
When criticizing DNSSEC, you can’t assume that the system for TLS certificates – i.e. CAs – is perfect. They both have their weak points and drawbacks. 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 r…
DNSSEC scares me. CAs are not perferct but they at least have some measure of accountability. Therr are many stories of CAs being removed from browsers, and many of them ended up ceasing operations whatsoever. The reason for that is CAs are interchangeable, if one goes back I can switch to other with almost no distruption. Compare to DNSSEC which are designed to have single supplier. If a TLD registrar goes bad, what…
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.
Earlier quoted context omitted.
Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. "Who cares about what people post to a forum?" was something I personally heard when I added https to one site. It was only really b…
> Browsers did ignore most certificate errors back in the early 2000s. HTTPS sites were fairly rare and most people did not care about it or even considered https to be a negative. Many administrators considered it as bad technology that only increased instability with no obvious benefit. I’m not sure what you’re basing that on but every claim is the opposite of my experience back then. Even in the 90s it was expecte…
