5 ms·

obligatory https://xkcd.com/927/ https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols th

obligatory https://xkcd.com/927/ https://xkcd.com/927/ Honestly: we're in this situation because we keep trying to band-aid solutions onto ancient protocols that were never designed to be secure. (I'm talking about you DNS.) Given xkcd's wisdom though, I'm not sure if this is easily solvable.

sulandor 2y ago
dns should not have to be secure, it should be regulated as a public utility with 3rd-party quality control and all the whistles. only then can it be trustworthy, fast and free/accessible
- iscoelho 2y ago
  If my DNS can be MITM'd, and is thus insecure, it is not trustworthy.
  - 8organicbits 2y ago
    This sort of all-or-nothing thinking isn't helpful. DNS points you to a server, TLS certificates help you trust that you've arrived at the right place. It's not perfect, but we build very trustworthy systems on this foundation.
    - quesera 2y ago
      But DNS is all-or-nothing. If you can't trust DNS, you can't trust TLS or anything downstream of it. Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS. Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".
      - 8organicbits 2y ago
        Bank websites like chase.com and hsbc.com and web services like google.com, amazon.com, and amazonaws.com intentionally avoid DNSSEC. I wouldn't consider those sites less than "very trustworthy" but my point is that "adequately trustworthy" is the goal. All-or-nothing thinking isn't how we build and secure systems.
        quesera 2y ago
        I am definitely not arguing in favor of DNSSEC. However, I don't think it's reasonable to call DNS, as a system, "very trustworthy". "Well-secured" by active effort, and consequently "adequately trustworthy" for consumer ecommerce, sure. But DNS is a systemic weak link in the chain of trust, and must be treated with extra caution for "actually secure" systems. (E.g., for TLS and where possible, the standard way to remove the trust dependency on DNS is certificate pinning. This is common practice, because DNS is systemically not trustworthy!)
        8organicbits 2y ago
        Is certificate pinning common? On the web we used to have HPKP, but that's obsolete and I didn't think it was replaced. I know pinning is common in mobile apps, but I've generally heard that's more to prevent end-user tampering than any actual distrust of the CAs/DNS. I think you're "well-secured" comment is saying the same thing I am, with some disagreement about "adequate" vs "very". I don't spend any time worrying that my API calls to AWS or online banking transactions are insecure due to lack of DNSSEC, so the DNS+CA system feels "very" trustworthy to me, even outside ecommerce. The difference between "very" and "adequate" is sort of a moot point anyway: you're not getting extra points for superfluous security controls. There's lots of other things I worry about, though, because attackers are actually focusing their efforts there.
        quesera 2y ago
        I agree that the semantics of "adequate" and "very" are moot. As always, it ultimately depends on your threat profile, real or imagined. Re: certificate pinning, it's common practice in the financial industry at least. It mitigates a few risks, of which I'd rate DNS compromise as more likely than a rogue CA or a persistent BGP hijack.
- IgorPartola 2y ago
  There is nothing fundamentally preventing us from securing DNS. It is not the most complicated protocol believe it or not and is extensible enough for us to secure it. Moreover a different name lookup protocol would look very similar to DNS. If you don’t quite understand what DNS does and how it works the idea of making it a government protected public service may appeal to you but that isn’t actually how it works. It’s only slightly hyperbolic to say that you want XML to be a public utility. On the other hand things like SMTP truly are ancient. They were designed to do things that just aren’t a thing today.
goodpoint 2y ago
Standards evolve for good reasons. That's just a comic.
- iscoelho 2y ago
  The comic is about re-inventing the wheel. What you propose "standards evolving" would be the opposite in spirit (and is what has happened with DNSSEC, RPKI, etc)
Dylan16807 2y ago
Can we all agree to not link that comic when nobody is suggesting a new standard, or when the list of existing standards is zero to two long? It's not obligatory to link it just because the word "standard" showed up. I think that covers everything in that list. For example, trying to go from IPv4 to IPv6 is a totally different kind of problem from the one in the comic.
- iscoelho 2y ago
  The point is that, ironically, new standards may have been a better option. Bolting on extensions to existing protocols not designed to be secure, while improving the situation, has been so far unable to address all of the security concerns leaving major gaps. It's just a fact.

sulandor 2y ago

dns should not have to be secure, it should be regulated as a public utility with 3rd-party quality control and all the whistles. only then can it be trustworthy, fast and free/accessible

iscoelho 2y ago
If my DNS can be MITM'd, and is thus insecure, it is not trustworthy.
- 8organicbits 2y ago
  This sort of all-or-nothing thinking isn't helpful. DNS points you to a server, TLS certificates help you trust that you've arrived at the right place. It's not perfect, but we build very trustworthy systems on this foundation.
  - quesera 2y ago
    But DNS is all-or-nothing. If you can't trust DNS, you can't trust TLS or anything downstream of it. Even banks are not bothering with EV certificates any more, since browsers removed the indicator (for probably-good reasons). DV certificate issuance depends on trustworthy DNS. Internet security is "good enough" for consumers, most of the time. That's "adequately trustworthy", but it's not "very trustworthy".
    - 8organicbits 2y ago
      Bank websites like chase.com and hsbc.com and web services like google.com, amazon.com, and amazonaws.com intentionally avoid DNSSEC. I wouldn't consider those sites less than "very trustworthy" but my point is that "adequately trustworthy" is the goal. All-or-nothing thinking isn't how we build and secure systems.
      - quesera 2y ago
        I am definitely not arguing in favor of DNSSEC. However, I don't think it's reasonable to call DNS, as a system, "very trustworthy". "Well-secured" by active effort, and consequently "adequately trustworthy" for consumer ecommerce, sure. But DNS is a systemic weak link in the chain of trust, and must be treated with extra caution for "actually secure" systems. (E.g., for TLS and where possible, the standard way to remove the trust dependency on DNS is certificate pinning. This is common practice, because DNS is systemically not trustworthy!)
        8organicbits 2y ago
        Is certificate pinning common? On the web we used to have HPKP, but that's obsolete and I didn't think it was replaced. I know pinning is common in mobile apps, but I've generally heard that's more to prevent end-user tampering than any actual distrust of the CAs/DNS. I think you're "well-secured" comment is saying the same thing I am, with some disagreement about "adequate" vs "very". I don't spend any time worrying that my API calls to AWS or online banking transactions are insecure due to lack of DNSSEC, so the DNS+CA system feels "very" trustworthy to me, even outside ecommerce. The difference between "very" and "adequate" is sort of a moot point anyway: you're not getting extra points for superfluous security controls. There's lots of other things I worry about, though, because attackers are actually focusing their efforts there.
        quesera 2y ago
        I agree that the semantics of "adequate" and "very" are moot. As always, it ultimately depends on your threat profile, real or imagined. Re: certificate pinning, it's common practice in the financial industry at least. It mitigates a few risks, of which I'd rate DNS compromise as more likely than a rogue CA or a persistent BGP hijack.
IgorPartola 2y ago
There is nothing fundamentally preventing us from securing DNS. It is not the most complicated protocol believe it or not and is extensible enough for us to secure it. Moreover a different name lookup protocol would look very similar to DNS. If you don’t quite understand what DNS does and how it works the idea of making it a government protected public service may appeal to you but that isn’t actually how it works. It’s only slightly hyperbolic to say that you want XML to be a public utility. On the other hand things like SMTP truly are ancient. They were designed to do things that just aren’t a thing today.

goodpoint 2y ago

Standards evolve for good reasons. That's just a comic.

iscoelho 2y ago
The comic is about re-inventing the wheel. What you propose "standards evolving" would be the opposite in spirit (and is what has happened with DNSSEC, RPKI, etc)

Dylan16807 2y ago

Can we all agree to not link that comic when nobody is suggesting a new standard, or when the list of existing standards is zero to two long? It's not obligatory to link it just because the word "standard" showed up. I think that covers everything in that list. For example, trying to go from IPv4 to IPv6 is a totally different kind of problem from the one in the comic.

iscoelho 2y ago
The point is that, ironically, new standards may have been a better option. Bolting on extensions to existing protocols not designed to be secure, while improving the situation, has been so far unable to address all of the security concerns leaving major gaps. It's just a fact.