5 ms·

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 (rammi

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 dnssec and recommended tls as a better alternative). Dnssec also does not solve bgp hijacking, which combined with ip based tls signing servers moots any value dnssec has - sure you could registrar lock your domain via dns (preventing letsencrypt signing things), but if a threat actor has the capability to bgp hijack to perform such an attack and is targeting you, you probably have bigger issues elsewhere.

teddyh 3y ago
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 record in the DNS using DNSSEC. No need to trust CAs. BGP could possibly use the same solution, using the reverse lookup .arpa DNS space. DNSSEC is the building block from which secure certificates and BGP routes can be built, without the ad-hoc CA system we have today.
- tptacek 3y ago
  People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and will never consent to transparency logging. This very much includes the US, which actively manipulates the DNS for policy ends. If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit, as it has done in the past with other major CAs. Google can't do anything about .COM mis-signatures. Thankfully, practically none of .COM is signed.
  - belorn 3y ago
    If the issue is the lack of certificate transparency, then add that as a new standard to dnssec. Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.
    - tptacek 3y ago
      I've explained several times on this thread already why DNSSEC won't ever get transparency logging.
      - belorn 3y ago
        You said that registrars won't implement transparency logging, but certificate transparency was not created by certificate authoritative. Google added it to chrome, and they could just as easy add it to their own public resolver.
        tptacek 3y ago
        And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.
        belorn 3y ago
        "If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit" - tptacek If Verisign knowingly missuses .com root certificate, Google could nuke them from orbit by making it public. That is the whole purpose of certificate logs. Verisign operate on trust and they are also certificate authority. The damage to Verisign if they lost their status as certificate authority and as a trusted company would create so much fallout I am doubtful that ICANN and DNS would be left without major scars. I don't think you've thought this through all the way.
        3y ago
- theamk 3y ago
  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 is going to happen? Moving to a new TLD is a huge deal, and affects everyone, including your customer. And browsers can't really ban an entire TLD like they ban CAs. So yes, both CAs and DNSSEC have some problems. But one of them is pretty good and getting better the time (deprecation of old crypto, short-expiration certificates) while the other is stuck with ancient crypto, constant technical outages, and no chance of improvement.
  - tialaramex 3y ago
    The TLD registrar has enormous impact on you regardless of DNSSEC, and people just seem to put up with it, much as they put up with having an awful US state government, or a terrible HOA, or dozens of other problems. 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.
- tialaramex 3y ago
  BGP has its own PKI, the RPKI, so it doesn't need to lean on DNS whereas much of the other Internet systems already leans on DNS so might as well choose DNSSEC. 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 ?
bawolff 3y ago
> Dnssec also does not solve bgp hijacking This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.
- technion 3y ago
  Where it's a complaint worth making is that every time there's a BGP Hijack there are a series of articles written incorrectly claiming DNSSEC would have prevented it.
- hsbauauvhabzb 3y ago
  What does dnssec solve then?
  - bawolff 3y ago
    Authenticity of dns records. Making sure that the dns record points to the correct ip address. Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure. The relavant security thing for bgp is called rpki.
belorn 3y ago
DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.
- tptacek 3y ago
  Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.
  - hsbauauvhabzb 3y ago
    You’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.
    - wlonkly 3y ago
      A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.
  - belorn 3y ago
    If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack). If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server. If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.
    - tptacek 3y ago
      None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.

teddyh 3y ago

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 record in the DNS using DNSSEC. No need to trust CAs. BGP could possibly use the same solution, using the reverse lookup .arpa DNS space. DNSSEC is the building block from which secure certificates and BGP routes can be built, without the ad-hoc CA system we have today.

tptacek 3y ago
People say this all the time, but of course the WebPKI has Certificate Transparency, requiring every issuer to register every certificate issued in a globally monitored tamper-proof log, and DNSSEC doesn't. Moreover, the WebPKI got CT because the browser root programs were able to force the CAs to join it. They have no such influence over DNS registrars, many of which are de jure controlled by world governments and will never consent to transparency logging. This very much includes the US, which actively manipulates the DNS for policy ends. If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit, as it has done in the past with other major CAs. Google can't do anything about .COM mis-signatures. Thankfully, practically none of .COM is signed.
- belorn 3y ago
  If the issue is the lack of certificate transparency, then add that as a new standard to dnssec. Certificate Transparency came into the picture around 2013, by which time https was fairly old. Public resolvers like google, quad 9, and cloudflare could create Certificate Transparency for dnssec today if there was a demand for it.
  - tptacek 3y ago
    I've explained several times on this thread already why DNSSEC won't ever get transparency logging.
    - belorn 3y ago
      You said that registrars won't implement transparency logging, but certificate transparency was not created by certificate authoritative. Google added it to chrome, and they could just as easy add it to their own public resolver.
      - tptacek 3y ago
        And then what happens? Google stops resolving .COM names? I don't think you've thought this through all the way.
        belorn 3y ago
        "If Comodo knowingly misissues a Google Mail certificate, Google will nuke them from orbit" - tptacek If Verisign knowingly missuses .com root certificate, Google could nuke them from orbit by making it public. That is the whole purpose of certificate logs. Verisign operate on trust and they are also certificate authority. The damage to Verisign if they lost their status as certificate authority and as a trusted company would create so much fallout I am doubtful that ICANN and DNS would be left without major scars. I don't think you've thought this through all the way.
        3y ago
theamk 3y ago
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 is going to happen? Moving to a new TLD is a huge deal, and affects everyone, including your customer. And browsers can't really ban an entire TLD like they ban CAs. So yes, both CAs and DNSSEC have some problems. But one of them is pretty good and getting better the time (deprecation of old crypto, short-expiration certificates) while the other is stuck with ancient crypto, constant technical outages, and no chance of improvement.
- tialaramex 3y ago
  The TLD registrar has enormous impact on you regardless of DNSSEC, and people just seem to put up with it, much as they put up with having an awful US state government, or a terrible HOA, or dozens of other problems. 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.
tialaramex 3y ago
BGP has its own PKI, the RPKI, so it doesn't need to lean on DNS whereas much of the other Internet systems already leans on DNS so might as well choose DNSSEC. 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 ?

bawolff 3y ago

> Dnssec also does not solve bgp hijacking This seems like a pretty unreasonable complaint. Dnssec also doesn't stop phishing. Or nukes.

technion 3y ago
Where it's a complaint worth making is that every time there's a BGP Hijack there are a series of articles written incorrectly claiming DNSSEC would have prevented it.
hsbauauvhabzb 3y ago
What does dnssec solve then?
- bawolff 3y ago
  Authenticity of dns records. Making sure that the dns record points to the correct ip address. Whether or not an ip address goes to the correct computer is totally unrelated to DNS, so i'm not sure why anyone would think that has anything to do with a dns security measure. The relavant security thing for bgp is called rpki.

belorn 3y ago

DNSSEC does actually have protection against bgp hijacking. The dnssec root key are (generally?) hardcoded into the resolvers, so even if someone would do a bgp hijacking of the root servers they would still not resolve.

tptacek 3y ago
Who cares? If you control BGP, you control the meaning of the IP addresses DNS resolves to.
- hsbauauvhabzb 3y ago
  You’re also relying on the client validating DNSSec. I have no idea if/how/when this occurs, or if you can choose to ignore it.
  - wlonkly 3y ago
    A nit, but the resolver, not the client, validates DNSSEC. The client/stub resolver trusts its local resolver. That always struck me as weird.
- belorn 3y ago
  If the attacker bgp hijacks the record target they need to also bgp hijack the authoritative server that holds the TLSA record (which the client could verify during an attack). If the attacker want to bgp hijack the authoritative server they will need to bgp hijack the TLD name servers that holds the DS posts for the authoritative server. If the attacker want to bgp hijack the TLD name servers they will need to bgp hijack the root server that holds the DS posts for the TLD name servers. This they can't do because the root servers keys are hard coded into revolvers.
  - tptacek 3y ago
    None of this matters. An attacker who controls BGP controls IP routing. They can defeat ACME.