9 ms·

It seems like some folks are missing the motivation for DNSSec and suggesting TLS instead. If your threat model includes global adversaries, you have can't rely

It seems like some folks are missing the motivation for DNSSec and suggesting TLS instead. If your threat model includes global adversaries, you have can't rely on TLS because governments can trivially compromise TLS providers and TLS exposes users to the lowest common denominator TLS. The lowest common denominator TLS (ACME DNS-1) and the mitigation to the TLS provider problem (CAA records) are both based on DNS. So you either accept that TLS is the global maxima for security and world governments can basically permanently compromise the internet, or you build private PKI systems, or you want something like DNSSec. And DNSSec is something like DNSSec.

insanitybit 3y ago
Let's say the US wanted to perform an attack that DNSSEC would have prevented, what does that attack look like?
- matthew9219 3y ago
  The US seizes the cryptographic material for a US based root, issues keys and certificates for the domains it wants to compromise and intercepts and modifies the traffic for targeted users. There's some additional asterisks around not getting caught and certificate transparency logs and browser reporting structure, but for many classes of devices, it will suffice to simply also hijack the domains used for requesting the transparency log or the domains used for reporting certificates that don't appear in the log. Users who are concerned about a government like the United States can use DNSSec to prevent a threat like this by using a non-US based TLD that employs DNSSec, and by running their client in a mode that requires valid DNSSec records for their domains. Of course, such services would practically need to be located outside of the country of concern as well.
  - CommanderData 3y ago
    For a state like the US, with it's laws and history on surveillance. I assume PKI has been compromised. I don't check or audit my CA's and don't think most people do either. Wouldn't be surprised if more than one of these has been compromised in some fashion already. It only takes one and there's plenty to target. The next thing you'd need is a mitm attack and again that's entirely possible for a nation state to pull off at scale.
    - tptacek 3y ago
      Every single certificate issued by a WebPKI CA (ie: a CA whose certificates are accepted by Google or Mozilla's root programs) is logged in a globally auditable tamper-proof log. You can stand up an instance of that log, or monitor any of the existing logs yourself. You're not relying on laws to surveil the WebPKI CAs, but rather mathematics.
      - matthew9219 3y ago
        A log to secure TLS which clients typically obtain over a TLS connection and whose violations they report over a TLS connection. It's a circular dependency. CT provides a guarantee like: "hopefully one of those devices will eventually connect to a non-compromised network and report the prior compromise". By observing the lack of such reports, we can be reasonably confident compromises of size N>millions are not happening, but it's difficult to reason about what compromises may be happening at small N.
        tptacek 3y ago
        This isn't how CT is used in the real world. It's not like OCSP.
    - ggm 3y ago
      https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies
    - jcranmer 3y ago
      > I don't check or audit my CA's and don't think most people do either. The people responsible for running the root stores do. And when CAs screw up, they are nuked from orbit--this has happened a few times. And they can be proactive: when Kazakhstan announced they would require all TLS connections to be MITM'd, the browsers promptly added the MITM certificate to the root store with the explicit distrust bit set, meaning that the resulting certificate error can't be clicked through, effectively breaking the internet if you tried to use that for MITM (which put the kibosh on that plan immediately). And for another thing, I wouldn't trust the people who run the nameservers any more intrinsically than CAs. After all, the TLD that runs most of the commercial internet (.com) is run by a company that had problems when it ran a CA. There's no way to route around an untrustworthy TLD operator, and it needs to be recalled that many TLDs are literally run by state governments. And several of those governments believe the privacy of their citizens to be a bug, not a feature; giving them a more prominent role in securing privacy is not a good thing.
  - toast0 3y ago
    If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel. If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
    - matthew9219 3y ago
      Admittedly, the US is a bit of a special case because of ICANN. Better examples are probably Saudi Arabia, Israel, Australia, Russia, etc.
    - AndyMcConachie 3y ago
      First off, ICANN doesn't run the root servers. ICANN operates 1 root server identity,l-root.root-servers.net. The others are run by different organizations. Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it. ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures. Finally, glue records aren't signed! https://www.internic.net/domain/root.zone https://www.internic.net/domain/root.zone
      - toast0 3y ago
        > ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures. Ok, well back to compelling Verisign. Certainly they are able to sign zones, although that authority flows from ICANN. > Finally, glue records aren't signed! If glue records aren't signed, then why wouldn't an adversary simply modify the glue records to omit the DNSSEC content? Maybe you're making a technical argument that the whole root zone is signed, not its individual components?
colmmacc 3y ago
That seems exactly backwards. With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it. While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.
- matthew9219 3y ago
  The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer. Most companies trust their home country as a matter of practicality. Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.
  - tptacek 3y ago
    All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
    - matthew9219 3y ago
      Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome. For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected? CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.
realusername 3y ago
The alternative is secure and decentralized DNS like 'unstoppable domains", DNSSec is too clunky and centralized to help here.
deleted 3y ago
[deleted]

insanitybit 3y ago

Let's say the US wanted to perform an attack that DNSSEC would have prevented, what does that attack look like?

matthew9219 3y ago
The US seizes the cryptographic material for a US based root, issues keys and certificates for the domains it wants to compromise and intercepts and modifies the traffic for targeted users. There's some additional asterisks around not getting caught and certificate transparency logs and browser reporting structure, but for many classes of devices, it will suffice to simply also hijack the domains used for requesting the transparency log or the domains used for reporting certificates that don't appear in the log. Users who are concerned about a government like the United States can use DNSSec to prevent a threat like this by using a non-US based TLD that employs DNSSec, and by running their client in a mode that requires valid DNSSec records for their domains. Of course, such services would practically need to be located outside of the country of concern as well.
- CommanderData 3y ago
  For a state like the US, with it's laws and history on surveillance. I assume PKI has been compromised. I don't check or audit my CA's and don't think most people do either. Wouldn't be surprised if more than one of these has been compromised in some fashion already. It only takes one and there's plenty to target. The next thing you'd need is a mitm attack and again that's entirely possible for a nation state to pull off at scale.
  - tptacek 3y ago
    Every single certificate issued by a WebPKI CA (ie: a CA whose certificates are accepted by Google or Mozilla's root programs) is logged in a globally auditable tamper-proof log. You can stand up an instance of that log, or monitor any of the existing logs yourself. You're not relying on laws to surveil the WebPKI CAs, but rather mathematics.
    - matthew9219 3y ago
      A log to secure TLS which clients typically obtain over a TLS connection and whose violations they report over a TLS connection. It's a circular dependency. CT provides a guarantee like: "hopefully one of those devices will eventually connect to a non-compromised network and report the prior compromise". By observing the lack of such reports, we can be reasonably confident compromises of size N>millions are not happening, but it's difficult to reason about what compromises may be happening at small N.
      - tptacek 3y ago
        This isn't how CT is used in the real world. It's not like OCSP.
  - ggm 3y ago
    https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies
  - jcranmer 3y ago
    > I don't check or audit my CA's and don't think most people do either. The people responsible for running the root stores do. And when CAs screw up, they are nuked from orbit--this has happened a few times. And they can be proactive: when Kazakhstan announced they would require all TLS connections to be MITM'd, the browsers promptly added the MITM certificate to the root store with the explicit distrust bit set, meaning that the resulting certificate error can't be clicked through, effectively breaking the internet if you tried to use that for MITM (which put the kibosh on that plan immediately). And for another thing, I wouldn't trust the people who run the nameservers any more intrinsically than CAs. After all, the TLD that runs most of the commercial internet (.com) is run by a company that had problems when it ran a CA. There's no way to route around an untrustworthy TLD operator, and it needs to be recalled that many TLDs are literally run by state governments. And several of those governments believe the privacy of their citizens to be a bug, not a feature; giving them a more prominent role in securing privacy is not a good thing.
- toast0 3y ago
  If the US is going to seize cryptographic material from CAs, they've probably got no problem ordering US based domain registries to do their bidding either. If it's Verisign registry, they can use the Verisign CA too, and it's only one company to compel. If all else fails, ICANN runs the root servers more or less, and is based in the US, and subject to being compelled to make bad signatues of tld glue records.
  - matthew9219 3y ago
    Admittedly, the US is a bit of a special case because of ICANN. Better examples are probably Saudi Arabia, Israel, Australia, Russia, etc.
  - AndyMcConachie 3y ago
    First off, ICANN doesn't run the root servers. ICANN operates 1 root server identity,l-root.root-servers.net. The others are run by different organizations. Secondly, the root server operators have no control over the cryptography. They get a zone file and they serve it. ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures. Finally, glue records aren't signed! https://www.internic.net/domain/root.zone https://www.internic.net/domain/root.zone
    - toast0 3y ago
      > ICANN only runs the key generation ceremony which is scripted to prevent any single entity from tampering with the keys. ZSKs are generated a few months in advance and used by Verisign (the root zone maintainer) to sign the root zone. No one gets to see the private part of the KSK. So there is no way to compel ICANN to produce bad signatures. Ok, well back to compelling Verisign. Certainly they are able to sign zones, although that authority flows from ICANN. > Finally, glue records aren't signed! If glue records aren't signed, then why wouldn't an adversary simply modify the glue records to omit the DNSSEC content? Maybe you're making a technical argument that the whole root zone is signed, not its individual components?

colmmacc 3y ago

That seems exactly backwards. With DNSSEC zones are controlled and signed by a single authority, and for CCTLDs that authority is controlled by ... the government. If they wanted to produce a malicious signature and serve it narrowly to a targeted victim ... that's quite doable with little in the DNSSEC system to prevent it. While it's true that there many TLS root cert operators and some probably could be compromised by a government (though I wouldn't say "trivially"), there is also a gigantic mutual destruction pact in the form of certificate transparency that means all certs issued are visible in transparency logs and there are quite sophisticated technical and social controls in place to detect malicious certs. The cert operator would be imperiling their business and future trust in a way that isn't as true for DNSSEC.

matthew9219 3y ago
The fundamental difference is that with TLS you have to trust ALL certificate issuers, but with DNSSec you only have to trust your TLD and your certificate issuer. Most companies trust their home country as a matter of practicality. Certificate transparency is cool, but it's not clear it really works for many classes of devices (particularly devices that only use one network like gaming systems or TVs). The global adversary just compromises the channels used to obtain the transparency logs and to report violations. It seems to work for mobile consumer devices like cel phones, because these devices naturally connect to many different networks, of which only some are compromised.
- tptacek 3y ago
  All the CAs are required to log. You don't have to trust any of them. The premise of CT isn't that every device is watching the logs in real time, such that your set-top box is somehow using it.
  - matthew9219 3y ago
    Somebody has got to check the logs and report violations. Chrome does, so CT works mostly for the world wide web, because all websites want to work in Chrome. For a device like a router, if the router doesn't check the logs itself, and a global adversary compromises the TLS update channel for the router, and starts distributing malicious firmware... If the router itself doesn't report the violation, for how long might such a compromise go undetected? Is there any reason to think it'd ever be detected? CT has a bit of an implicit dependency on heterogeneous configurations - that at least some clients report violations, and that attackers cannot easily distinguish reporting clients from non-reporting clients. For homogenous configurations (like the implementations of AWS, Azure, or GCM, or the deployment of routers, IOT devices, or gaming systems), it seems like a competent global adversary would simply figure out how to go unreported for that configuration, and nobody would particularly check.

realusername 3y ago

The alternative is secure and decentralized DNS like 'unstoppable domains", DNSSec is too clunky and centralized to help here.

deleted 3y ago

[deleted]