5 ms·

As much as I want DNSSEC to be a thing, it just doesn’t seem like it ever will. Checkout this name-and-shame site and you’ll see how hopeless it looks https://d

As much as I want DNSSEC to be a thing, it just doesn’t seem like it ever will. Checkout this name-and-shame site and you’ll see how hopeless it looks https://dnssec-name-and-shame.com https://dnssec-name-and-shame.com

jaas 8y ago
Why do you want it to be a thing? Have you ever been exposed to an attack that would have been prevented by DNSSEC? I feel like most people who want DNSSEC just have very theoretical warm feelings about the idea of it. When they actually implement it it does nothing but consume time and energy while adding liability.
- amluto 8y ago
  A BGP attack against a CA to get a fraudulent cert issues. (As far as I know, no one has done this to me, but they could.)
  - tptacek 8y ago
    How does DNSSEC help you here? BGP attackers control IP addresses. They don't even need to touch the DNS to misissue a DV certificate.
    - amluto 8y ago
      With CAA records and a draft extension to CAA [0]. Letsencrypt already supports enough of it in staging. If you enable DNSSEC and set a CAA record like issue "letsencrypt.org; validationmethods=dns-01" Then, unless I’m missing something, you’re protected from BGP and other MITM attacks. (Well, you will be once this hits production.) And it’ll be considerably less annoying to work with once the “accounturi” constraint works. I would go so far as to say that not doing this for a high value site will be irresponsible once this CAA feature becomes stable. [0] https://tools.ietf.org/html/draft-ietf-acme-caa-06 https://tools.ietf.org/html/draft-ietf-acme-caa-06
      - agwa 8y ago
        I'm afraid that's unlikely to protect you from BGP attacks. In theory, the Baseline Requirements require CAs to honor DNSSEC when checking CAA records. However, in practice, there are too many terrible DNS servers, and looking up a CAA record can often fail, for example because the authoritative server just drops any packet containing a CAA query. So CAs are allowed to treat a CAA lookup failure as permission to issue if the domain is not DNSSEC-signed. However, since no off-the-shelf resolver provides an API to check if a domain is DNSSEC-signed, CAs had to roll their own solutions, most of which were wrong and insecure (probably in no small part due to DNSSEC's monstrous complexity). An attacker who can BGP hijack your authoritative DNS servers would be able to get a certificate from one of these CAs. I created https://caatestsuite.com/ https://caatestsuite.com/ and smoked out many of these bugs in 2017. Maybe the situation has improved since then, but given the difficulty in implementing this check correctly, I'm sure there's at least one CA out there that is doing it wrong, and it only takes one CA to misissue.
        amluto 8y ago
        It will make BGP attacks considerably harder. It will also make them more like one-off attacks: if you know a vulnerable CA, you can only reliably attack it once like this. In the long run, I’d love to see something a little more like TLSA so that browsers can at least reject certificates from the wrong CA.
        tptacek 8y ago
        This is the problem: DNSSEC purports to make a difficult attack somewhat more difficult (you say a lot more difficult, I say marginally more difficult) at absolutely staggering enormous global expense. We can solve the DV misissuance problem directly without forklifting in a new DNS, and the forklift upgrade doesn't even decisively solve the primary problem it's meant to solve. Why are we still considering DNSSEC?
        amluto 8y ago
        Do you have a concrete proposal that is both credibly deployable and better than DNSSEC? DNSSEC is awful in many ways, but it can be deployed incrementally, it's already standardized, and a good chunk of the benefit can be had without changing normal clients at all. I think that "absolutely staggering enormous global expense" is an overstatement. edit: A major benefit of DNSSEC is that the CA/B forum already requires that CAs use it to check CAA records.
- move-on-by 8y ago
  I don’t think I’ve ever been exposed to an attack that the HSTS preload list has protected me from, but that does not negate its value. Assurance is an important aspect of InfoSec. Without a doubt DNSSEC has some major shortcomings and the lack of implementation makes it useless, but that does not mean it would not provide value if it were more widespread
  - Quekid5 8y ago
    You're ignoring the possibility of negative value. People ITT have been saying repeatedly that DNSSEC provides negative value, i.e. that the effort is vastly out of proportion with any benefit that could be derived from it. They aren't necessarily saying that there is (absolutely) no benefit.
throwawaymath 8y ago
First of all, shame on that website for breaking my back button. Second, that website has to be a parody of DNSSEC. It's showing that none of the major tech companies use it, meanwhile the "good examples" of DNSSEC compliance are all vendors substantially involved in standardizing or selling DNS services.
- tptacek 8y ago
  Here's that point, in infographic form: https://twitter.com/tqbf/status/1086061495811743747 https://twitter.com/tqbf/status/1086061495811743747

jaas 8y ago

Why do you want it to be a thing? Have you ever been exposed to an attack that would have been prevented by DNSSEC? I feel like most people who want DNSSEC just have very theoretical warm feelings about the idea of it. When they actually implement it it does nothing but consume time and energy while adding liability.

amluto 8y ago
A BGP attack against a CA to get a fraudulent cert issues. (As far as I know, no one has done this to me, but they could.)
- tptacek 8y ago
  How does DNSSEC help you here? BGP attackers control IP addresses. They don't even need to touch the DNS to misissue a DV certificate.
  - amluto 8y ago
    With CAA records and a draft extension to CAA [0]. Letsencrypt already supports enough of it in staging. If you enable DNSSEC and set a CAA record like issue "letsencrypt.org; validationmethods=dns-01" Then, unless I’m missing something, you’re protected from BGP and other MITM attacks. (Well, you will be once this hits production.) And it’ll be considerably less annoying to work with once the “accounturi” constraint works. I would go so far as to say that not doing this for a high value site will be irresponsible once this CAA feature becomes stable. [0] https://tools.ietf.org/html/draft-ietf-acme-caa-06 https://tools.ietf.org/html/draft-ietf-acme-caa-06
    - agwa 8y ago
      I'm afraid that's unlikely to protect you from BGP attacks. In theory, the Baseline Requirements require CAs to honor DNSSEC when checking CAA records. However, in practice, there are too many terrible DNS servers, and looking up a CAA record can often fail, for example because the authoritative server just drops any packet containing a CAA query. So CAs are allowed to treat a CAA lookup failure as permission to issue if the domain is not DNSSEC-signed. However, since no off-the-shelf resolver provides an API to check if a domain is DNSSEC-signed, CAs had to roll their own solutions, most of which were wrong and insecure (probably in no small part due to DNSSEC's monstrous complexity). An attacker who can BGP hijack your authoritative DNS servers would be able to get a certificate from one of these CAs. I created https://caatestsuite.com/ https://caatestsuite.com/ and smoked out many of these bugs in 2017. Maybe the situation has improved since then, but given the difficulty in implementing this check correctly, I'm sure there's at least one CA out there that is doing it wrong, and it only takes one CA to misissue.
      - amluto 8y ago
        It will make BGP attacks considerably harder. It will also make them more like one-off attacks: if you know a vulnerable CA, you can only reliably attack it once like this. In the long run, I’d love to see something a little more like TLSA so that browsers can at least reject certificates from the wrong CA.
        tptacek 8y ago
        This is the problem: DNSSEC purports to make a difficult attack somewhat more difficult (you say a lot more difficult, I say marginally more difficult) at absolutely staggering enormous global expense. We can solve the DV misissuance problem directly without forklifting in a new DNS, and the forklift upgrade doesn't even decisively solve the primary problem it's meant to solve. Why are we still considering DNSSEC?
        amluto 8y ago
        Do you have a concrete proposal that is both credibly deployable and better than DNSSEC? DNSSEC is awful in many ways, but it can be deployed incrementally, it's already standardized, and a good chunk of the benefit can be had without changing normal clients at all. I think that "absolutely staggering enormous global expense" is an overstatement. edit: A major benefit of DNSSEC is that the CA/B forum already requires that CAs use it to check CAA records.
move-on-by 8y ago
I don’t think I’ve ever been exposed to an attack that the HSTS preload list has protected me from, but that does not negate its value. Assurance is an important aspect of InfoSec. Without a doubt DNSSEC has some major shortcomings and the lack of implementation makes it useless, but that does not mean it would not provide value if it were more widespread
- Quekid5 8y ago
  You're ignoring the possibility of negative value. People ITT have been saying repeatedly that DNSSEC provides negative value, i.e. that the effort is vastly out of proportion with any benefit that could be derived from it. They aren't necessarily saying that there is (absolutely) no benefit.

throwawaymath 8y ago

First of all, shame on that website for breaking my back button. Second, that website has to be a parody of DNSSEC. It's showing that none of the major tech companies use it, meanwhile the "good examples" of DNSSEC compliance are all vendors substantially involved in standardizing or selling DNS services.

tptacek 8y ago
Here's that point, in infographic form: https://twitter.com/tqbf/status/1086061495811743747 https://twitter.com/tqbf/status/1086061495811743747