6 ms·

DNSSec has caused so many outages at this point it's a joke. You have to be so insanely careful and plan everything to the nth degree otherwise you break every

DNSSec has caused so many outages at this point it's a joke. You have to be so insanely careful and plan everything to the nth degree otherwise you break everything: https://internetnz.nz/news-and-articles/dnssec-chain-validation-issue-technical-incident-report/ https://internetnz.nz/news-and-articles/dnssec-chain-validat... The idea is important. What it aims to protect is important. The current implementation is horrible, far too complex and fraught with so many landminds that no one wants to touch it. If Geoff Huston is suggesting it might be time to stick a fork in DNSSec because it's done, then IMHO it's well cooked. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/ https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/

iscoelho 1y ago
Yeah I'm by no means saying the implementation is good. RPKI is a joke as well in my opinion. But it's all we have right now. I am saying it is dishonest to discount the real security threat of not having DNSSEC.
- muppetman 1y ago
  Right OK, I fully agree with you then.
  - tptacek 1y ago
    What parts do you agree about? Someone making an argument that we should return to the drawing board and come up with a new protocol, one that doesn't make the "offline signers and authenticated denial" tradeoffs DNSSEC makes, would probably be saying something everybody here agrees with --- though I still don't think it would be one of the 5 most important security things to work on. But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.
    - iscoelho 1y ago
      I would love to go to back to the drawing board and solve the security pitfalls in BGP & DNS. I wish the organizations and committees involved did a better job back then. Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.
      - tptacek 1y ago
        You understand that it is a little difficult for people to take seriously a claim that you're interested in going back to the drawing board while at the same time very stridently arguing that hundreds of millions of dollars of work should go in to getting a 1994 protocol design from 4% deployment to 40% deployment. The time to return to the drawing board is now.
    - muppetman 1y ago
      I don't read that reply as them saying we should hasten deployment of DNSSEC. If that was the intention of the comment then no, I don't agree with that aspect of it. I saying say I agree with the statement "I am saying it is dishonest to discount the real security threat of not having DNSSEC." I believe we do need some way to secure/harden DNS against attacks, we can't pretend that DNS as it stands is OK. DNSSEC is trying to solve a real problem - I do think we need to go back to the drawing board on how we solve it though.
      - tptacek 1y ago
        They definitely believe we should hasten deployment of DNSSEC --- read across the thread. For instance: Slack was taken down for a half a day owing to a deployment of DNSSEC that a government contract obligated them to undertake, and that commenter celebrated the contract. It's fine that we all agree on some things and disagree on others! I don't think DNS security is a priority issue, but I'm fine with it conceptually. My opposition is to the DNSSEC protocol itself, which is a dangerous relic of premodern cryptography designed at a government-funded lab in the 1990s. The other commenter on this thread disagrees with that assessment. slightly later (My point here is just clarity about what we do and don't agree about. "Resolving" this conflict is pointless --- we're not making the calls, the market is. But from an intellectual perspective, understanding our distinctive positions on Internet security, even if that means recognizing intractable disputes, is more useful than just pretending we agree.)
belorn 1y ago
A common reason, if not the vast majority of cases, is that people mix up which key they publish and which key they are actually using. I don't doubt there are a lot of things they could do to improve the protocol, but this very common problem is fairly difficult to solve on a protocol level. I remember back in the days when people discouraged people from using encrypted disks because of the situation that could happen if the user lost their passwords. No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. Nowadays people usually have TPMs or key management software to manage keys, so people can forget the password and still access their encrypted disks. DNSSEC software is still not really that developed that they automatically include basic tests and verification tools to make sure people don't simply mix up keys. They assume that people write those themselves. Too many times this happens after incidents rather than before (heard this in so many war stories). It also doesn't help that dns is full of caching and caching invalidation. A lot of the insane step-by-step plans comes from working around TTL's, lack of verification, basic tooling, and that much of the work is done manually.
- dwattttt 1y ago
  > No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. This problem is accurate, but it's the framing that makes it wrong. No disk encryption algorithm can simultaneously protect and not protect something encrypted, what you're missing is the protocol/practices around that, and those are far less limited. There is heaps of encryption around these days, there are people losing access to their regular keys, and yet procedures that recover access to their data while not entirely removing the utility of having encrypted data/disks.
- josephcsible 1y ago
  A TPM is absolutely not a reliable way to store your key. Think about how often you get asked for a BitLocker recovery code, and imagine if every time that happened, you lost all your data.
daneel_w 1y ago
> You have to be so insanely careful and plan everything to the nth degree If you're on the root/TLD end of things I agree. Certainly not if you're a domain owner or name server administrator on the customer end of things.
1over137 1y ago
>DNSSec has caused so many outages at this point it's a joke. So has failing to renew TLS certificates. So what?
- pvg 1y ago
  Unrenewed certs have not caused the kind of extended mass outages DNSSec has, it's not close.
  - cyberax 1y ago
    If Let's Encrypt goes down, half of the Internet will stop working. Doubly so when we switch to certs that are valid for just a couple of days.
    - tptacek 1y ago
      That is... not how certificates work. The part of LetsEncrypt that has to work continuously ships as part of your browser root store.
      - bombcar 1y ago
        The proposal is to make LE certs 9 days long or something. Which means if LE is down for even a short time thousands and millions of certs will expire.
        viraptor 1y ago
        You don't wait till the last second to renew. 9 day certificates would mean 7 day renewals for example. And at that point you could have 2 or 3 ACME-compatible services configured as a backup.
        bombcar 1y ago
        I doubt 20% of the LE users even know other ACME services exist let alone what they may be.

iscoelho 1y ago

Yeah I'm by no means saying the implementation is good. RPKI is a joke as well in my opinion. But it's all we have right now. I am saying it is dishonest to discount the real security threat of not having DNSSEC.

muppetman 1y ago
Right OK, I fully agree with you then.
- tptacek 1y ago
  What parts do you agree about? Someone making an argument that we should return to the drawing board and come up with a new protocol, one that doesn't make the "offline signers and authenticated denial" tradeoffs DNSSEC makes, would probably be saying something everybody here agrees with --- though I still don't think it would be one of the 5 most important security things to work on. But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.
  - iscoelho 1y ago
    I would love to go to back to the drawing board and solve the security pitfalls in BGP & DNS. I wish the organizations and committees involved did a better job back then. Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.
    - tptacek 1y ago
      You understand that it is a little difficult for people to take seriously a claim that you're interested in going back to the drawing board while at the same time very stridently arguing that hundreds of millions of dollars of work should go in to getting a 1994 protocol design from 4% deployment to 40% deployment. The time to return to the drawing board is now.
  - muppetman 1y ago
    I don't read that reply as them saying we should hasten deployment of DNSSEC. If that was the intention of the comment then no, I don't agree with that aspect of it. I saying say I agree with the statement "I am saying it is dishonest to discount the real security threat of not having DNSSEC." I believe we do need some way to secure/harden DNS against attacks, we can't pretend that DNS as it stands is OK. DNSSEC is trying to solve a real problem - I do think we need to go back to the drawing board on how we solve it though.
    - tptacek 1y ago
      They definitely believe we should hasten deployment of DNSSEC --- read across the thread. For instance: Slack was taken down for a half a day owing to a deployment of DNSSEC that a government contract obligated them to undertake, and that commenter celebrated the contract. It's fine that we all agree on some things and disagree on others! I don't think DNS security is a priority issue, but I'm fine with it conceptually. My opposition is to the DNSSEC protocol itself, which is a dangerous relic of premodern cryptography designed at a government-funded lab in the 1990s. The other commenter on this thread disagrees with that assessment. slightly later (My point here is just clarity about what we do and don't agree about. "Resolving" this conflict is pointless --- we're not making the calls, the market is. But from an intellectual perspective, understanding our distinctive positions on Internet security, even if that means recognizing intractable disputes, is more useful than just pretending we agree.)

belorn 1y ago

A common reason, if not the vast majority of cases, is that people mix up which key they publish and which key they are actually using. I don't doubt there are a lot of things they could do to improve the protocol, but this very common problem is fairly difficult to solve on a protocol level. I remember back in the days when people discouraged people from using encrypted disks because of the situation that could happen if the user lost their passwords. No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. Nowadays people usually have TPMs or key management software to manage keys, so people can forget the password and still access their encrypted disks. DNSSEC software is still not really that developed that they automatically include basic tests and verification tools to make sure people don't simply mix up keys. They assume that people write those themselves. Too many times this happens after incidents rather than before (heard this in so many war stories). It also doesn't help that dns is full of caching and caching invalidation. A lot of the insane step-by-step plans comes from working around TTL's, lack of verification, basic tooling, and that much of the work is done manually.

dwattttt 1y ago
> No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. This problem is accurate, but it's the framing that makes it wrong. No disk encryption algorithm can simultaneously protect and not protect something encrypted, what you're missing is the protocol/practices around that, and those are far less limited. There is heaps of encryption around these days, there are people losing access to their regular keys, and yet procedures that recover access to their data while not entirely removing the utility of having encrypted data/disks.
josephcsible 1y ago
A TPM is absolutely not a reliable way to store your key. Think about how often you get asked for a BitLocker recovery code, and imagine if every time that happened, you lost all your data.

daneel_w 1y ago

> You have to be so insanely careful and plan everything to the nth degree If you're on the root/TLD end of things I agree. Certainly not if you're a domain owner or name server administrator on the customer end of things.

1over137 1y ago

>DNSSec has caused so many outages at this point it's a joke. So has failing to renew TLS certificates. So what?

pvg 1y ago
Unrenewed certs have not caused the kind of extended mass outages DNSSec has, it's not close.
- cyberax 1y ago
  If Let's Encrypt goes down, half of the Internet will stop working. Doubly so when we switch to certs that are valid for just a couple of days.
  - tptacek 1y ago
    That is... not how certificates work. The part of LetsEncrypt that has to work continuously ships as part of your browser root store.
    - bombcar 1y ago
      The proposal is to make LE certs 9 days long or something. Which means if LE is down for even a short time thousands and millions of certs will expire.
      - viraptor 1y ago
        You don't wait till the last second to renew. 9 day certificates would mean 7 day renewals for example. And at that point you could have 2 or 3 ACME-compatible services configured as a backup.
        bombcar 1y ago
        I doubt 20% of the LE users even know other ACME services exist let alone what they may be.