4 ms·

Making DNSSEC more attractive will help all the people that the workarounds won't. Two reasons for a better DNSSEC: 1) People will continue to [erroneously] a

Making DNSSEC more attractive will help all the people that the workarounds won't. Two reasons for a better DNSSEC: 1) People will continue to [erroneously] assume their DNS transactions are secure. They won't be, and then they'll get screwed. For users, this means being smart enough to know if their application is resistant to DNS attack, and if not, smart enough to implement a workaround. For organizations, this means waiting until they are attacked, then adding the workarounds. Organizations and users who make this assumption - which will be most of them - will continue to be more vulnerable than is necessary. 2) There are many applications and protocols on the internet other than HTTP[S], and assuming the above point, these apps/protocols would eventually need to implement the workarounds that web clients/servers have. Many of these are legacy, and many of them are also critical, including uses by the financial industry, medical industry, public utilities, government/military, web businesses, etc. The public sector is already implementing DNSSEC because they see that not doing so is unnecessarily risky (and they don't have to pay for it). But for all the private orgs that either don't see the need or don't want to bear the cost, a less odorous solution that doesn't require "workarounds" would net them significant benefits, even if it's at the fringes of today's real world security problems. Basically, we will all at some point be involved (at the least, indirectly) in something that isn't an HTTPS transaction, and so we will all at some point have a need to trust DNS to some extent. The workarounds aren't going to work by default for everyone everywhere, and so there will be people left in the lurch.

tptacek 8y ago
There are fewer and fewer non-HTTPS protocols every year, a fact underscored by the fact that DNS itself is moving towards a preferred realization in HTTPS. Not only that, but simply adding DNSSEC to an insecure legacy protocol obviously doesn't make it secure; all it does is give you a better chance of looking up its genuine IP address. These do not seem like compelling reasons to push a forklift upgrade of DNS infrastructure. And the market agrees: DNSSEC has more or less failed, even though you can now enable it pretty straightforwardly at a number of cloud providers. Nobody cares. And they're right: DNSSEC was a terrible solution to something that has always been kind of a non-problem. Even in the eras where DNS spoofing was straightforward (2007, the late 1990s), it never really mattered much operationally.
- peterwwillis 8y ago
  The market is perfectly content to sit back and add workarounds on top of workarounds until everything starts to collapse. It's culminated in DNS Flag Day: https://dnsflagday.net/ https://dnsflagday.net/. I suppose it's fine to forklift upgrade if it's to resolve the tech debt the market tacitly accepted, but not so if it means securing a small but meaningful part of internet infrastructure. I don't want or need DNSSEC as currently designed to be accepted everywhere, but saying that a workaround is preferable because the real fix is costly ignores the long-term ramifications.
  - tptacek 8y ago
    I understand your argument, but try for a second to see it from my perspective: the end-to-end argument pretty strongly implies, to me at least, that to get meaningful security, you want to provide it in higher-layer protocols, closer to the endpoints. What's wrong with taking a layered design like TCP/IP and simply drawing a line, below which we don't try to provide cryptographic security? We've been doing that for ~30 years now; it is the only means of providing cryptographic security on the Internet that has ever actually worked. You're calling this approach "workarounds", which, sure, they're workarounds, in the same sense as TCP is a workaround for IP's native lack of congestion avoidance.
    - wahern 8y ago
      Because making a TLS stack mandatory for doing DNS is both ridiculous and also a non-starter. Ridiculous because if you think adding DNSSEC verification to a DNS library is hard, try adding a TLS stack. The hard part isn't recursive queries. All DNS libraries, even stub resolves, already need to handle recursive resolution to follow CNAME chains as caching servers don't normally return resolved chains unless they're (a) in-bailiwick or (b) the chain can be resolved from cache. The ugly part is attaching such a complex dependency to all the various third-party resolvers out there. A non-starter because I've written DNS servers and clients that saw widespread deployment and by far the biggest headache was networks that blocked TCP on port 53. DNS over TLS uses port 853. LOL Like that's gonna work better. Same analysis applies to DNS over HTTP, except now you're adding a whole HTTP stack to your DNS library. For heaven's sake.... Why not just get the slow, painful death of the open internet over with and move everything to AWS. We can have AWS terminals using opaque, bespoke protocols for everything. We can merge the AWS and Blink/Chrome teams and we can delegate the development of all new novel network services to them.

tptacek 8y ago

There are fewer and fewer non-HTTPS protocols every year, a fact underscored by the fact that DNS itself is moving towards a preferred realization in HTTPS. Not only that, but simply adding DNSSEC to an insecure legacy protocol obviously doesn't make it secure; all it does is give you a better chance of looking up its genuine IP address. These do not seem like compelling reasons to push a forklift upgrade of DNS infrastructure. And the market agrees: DNSSEC has more or less failed, even though you can now enable it pretty straightforwardly at a number of cloud providers. Nobody cares. And they're right: DNSSEC was a terrible solution to something that has always been kind of a non-problem. Even in the eras where DNS spoofing was straightforward (2007, the late 1990s), it never really mattered much operationally.

peterwwillis 8y ago
The market is perfectly content to sit back and add workarounds on top of workarounds until everything starts to collapse. It's culminated in DNS Flag Day: https://dnsflagday.net/ https://dnsflagday.net/. I suppose it's fine to forklift upgrade if it's to resolve the tech debt the market tacitly accepted, but not so if it means securing a small but meaningful part of internet infrastructure. I don't want or need DNSSEC as currently designed to be accepted everywhere, but saying that a workaround is preferable because the real fix is costly ignores the long-term ramifications.
- tptacek 8y ago
  I understand your argument, but try for a second to see it from my perspective: the end-to-end argument pretty strongly implies, to me at least, that to get meaningful security, you want to provide it in higher-layer protocols, closer to the endpoints. What's wrong with taking a layered design like TCP/IP and simply drawing a line, below which we don't try to provide cryptographic security? We've been doing that for ~30 years now; it is the only means of providing cryptographic security on the Internet that has ever actually worked. You're calling this approach "workarounds", which, sure, they're workarounds, in the same sense as TCP is a workaround for IP's native lack of congestion avoidance.
  - wahern 8y ago
    Because making a TLS stack mandatory for doing DNS is both ridiculous and also a non-starter. Ridiculous because if you think adding DNSSEC verification to a DNS library is hard, try adding a TLS stack. The hard part isn't recursive queries. All DNS libraries, even stub resolves, already need to handle recursive resolution to follow CNAME chains as caching servers don't normally return resolved chains unless they're (a) in-bailiwick or (b) the chain can be resolved from cache. The ugly part is attaching such a complex dependency to all the various third-party resolvers out there. A non-starter because I've written DNS servers and clients that saw widespread deployment and by far the biggest headache was networks that blocked TCP on port 53. DNS over TLS uses port 853. LOL Like that's gonna work better. Same analysis applies to DNS over HTTP, except now you're adding a whole HTTP stack to your DNS library. For heaven's sake.... Why not just get the slow, painful death of the open internet over with and move everything to AWS. We can have AWS terminals using opaque, bespoke protocols for everything. We can merge the AWS and Blink/Chrome teams and we can delegate the development of all new novel network services to them.