7 ms·

tptacek: > Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger? Ple

by danyork 12y ago

tptacek: > Why on earth would anyone store SSH keys in a PKI controlled by NSA and GCHQ? How does that not make the argument against DNSSEC even stronger? Please remind me again how the NSA/GCHQ can subvert my domain at example.com without anyone else in the chain noticing that?

tptacek 12y ago
What makes you think anyone is going to notice? DNS is a distributed system. The NSA is a byzantine attacker. There is no instantaneous convergence on a single answer; CAP applies; a byzantine DNS attacker can deliberately introduce inconsistent answers. Virtually none of the DNS resolvers in the world also function as inconsistent-answer detectors. There's this weird presumption among DNSSEC advocates that DNS is somehow resilient against targeted attacks (you see it every time an argument lands on "but people will notice that"). No. Not only is that not true, but it's even less true than other protocols where we know that to be true; for instance, BGP4 is also not resilient against byzantine failures, but at least BGP4 updates propagate (BGP4 is like a "PUSH" system in that regard, where DNS is "PULL"). What's even funnier about this "people will notice" objection is that people routinely notice corruption at certificate authorities... and nothing happens to those CAs. Compared to the DNS roots, CAs are trivial to blacklist. Nobody is going to notice targeted attacks on DNS, but even if they did, nothing will happen; there is no disincentive to those attacks for the attackers.
- danyork 12y ago
  Thomas, I perform DNSSEC validation on the edge of my home office network. All my devices use my DNSSEC-validating DNS resolver on my network server-gateway. That resolver is going to check the DNSSEC chain of trust using DS records all the way up to the root of DNS. If I get back a signed record for www.example.com (meaning an RRSIG), my DNS resolver is going to validate the signatures back up to the root of DNS. If the signatures don't validate, it's going to give me a SERVFAIL and prevent me from going to whatever site I'm trying to get to. If the NSA/GCHQ/whomever wanted to redirect me to another site under their control, they could try to send me the record with a valid RRSIG from their own DNSKEY. My resolver is now going to go to .COM (for example.com) and pull the DS record for "example.com". If the DNSKEY and DS don't match, I'm going to get a SERVFAIL and won't get to the site. Now, the attacker could try to send me their own DS record for the .COM domain... but that's going to be signed by the .COM's DNSKEY ... which again I suppose the attacker could try to send me a substitute. But now my resolver is going to pull a DS record from the root of DNS for the .COM TLD. That DS record will be signed with the DNSKEY of the root. My resolver is going to validate that signed DS record and compare it with the DNSKEY for .COM. If they don't match, I'm going to get a SERVFAIL. Now I guess in theory the attacker could try to send me a DS record for the .COM TLD that is signed by their own key... but here's the thing - my local resolver is already pre-loaded with the public key of the root zone as the trust anchor. So it's not going to trust anyone else's records that purport to be the root zone if the signatures don't match the local trust anchor. So how does the NSA/GCHQ/etc. carry out this attack to redirect me to another site?
  - tptacek 12y ago
    I don't understand the point you're trying to make. In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.
  - fragmede 12y ago
    The NSA attack assumes an NSA level attacker has access to the root zone's (or someone else in the chain's) private key. The NSA can then send a key for the .COM TLD that's valid, according to your pre-loaded local resolver, and they can also send a seemingly valid record for example.com. The CA mechanism used for TLS has the same issue. It's not just theoretical either, Gmail and other Google domains had fake certificates that passed validation issued by CNNIC, China's Internet authority, which was discovered earlier this year.
    - danyork 12y ago
      But here's the thing - the root zone's private key for DNSSEC is not in one place. It is spread across a number of smart cards carried by a variety of individuals spread around the world - specifically so that it could not be compromised by governments or others. You can see for yourself exactly what kind of process takes place to use the root key to generate new Zone Signing Keys (ZSKs) every 3 months at the IANA key ceremonies: https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies It would be an extremely difficult process for an intelligence agency to subvert, even one with essentially limitless resources.
      - tptacek 12y ago
        But domains under .COM are exactly as trustworthy as Verisign, right? The root key signing ceremonies are just theater, right?
    - danyork 12y ago
      > The CA mechanism used for TLS has the same issue. It's not just theoretical either... Exactly. Which is why so many of us are looking for ways to add an additional layer of trust to the CA system used for TLS. One such mechanism is to use DANE and DNSSEC as an additional mechanism for trust.
- danyork 12y ago
  tptacek: > I don't understand the point you're trying to make. I am trying to understand how the attack you say is possible truly is possible. > In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself. Verisign operates the .COM TLD registry and has documented in excruciating detail how they handle the security of DNSSEC key material: https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf Is your assertion that the NSA would order Verisign to bypass those controls and make a change to a DS record (and associated NS records) to redirect people to another site? If so, how would they do that for just me? It would have to be a much larger redirection of people.
  - tptacek 12y ago
    First, Verisign operates the .COM TLD at the pleasure of the US government. Second, if "just trust Verisign" is enough, we're done: just have the browsers only allow Verisign as the TLS CA for .COM names.
    - jamiesonbecker 12y ago
      to tptacek's point - an attacker doesn't need to change the root zone. All they need is the root key. (This argument could be equally made of the CA system.) Then they can sign anything they like, anytime they like, and only for some small targeted set of the population - and for DNSSEC, that's ONLY if you're checking it anyway. (and if you don't control your recursive resolver or patch your browser, tough cookies). @danyork your edge checking is great.. so I presume you never bring your laptop to a coffee shop. ;) Let's not be naive.. as far as root keys go, Verisign is a big company and will promptly hand over any and all keys upon receipt of an NSL or court order and probably just an administrative subpoena. That's how you win and keep massive, government-mandated monopolies to run the world. (To be fair, it's not Verisign's fault that the entire CA system is broken. Oh, wait, actually.. it's exactly Verisign's fault. https://en.wikipedia.org/wiki/Verisign#History https://en.wikipedia.org/wiki/Verisign#History )
      - 12y ago
pingwin 12y ago
I think what tptacek is hinting at is that a nation state could forge roots with their own certificates, creating a separate chain of trust. Given that your internet enabled device does not likely have an DNSSEC validating resolver (with uncompromising trust anchors for the roots) operating on it it's still possible for your device to receive forged responses.
- tptacek 12y ago
  He knows that; he's saying, if GCHQ did that to tamper with a key stored for a .IO name, the world would notice, because they'd all get that poisoned key. But that's not actually how DNS works.
- danyork 12y ago
  If your Internet-enabled device doesn't have a DNSSEC-validating resolver (with solid trust anchors for the root zone), then this entire conversation is irrelevant. If your Internet-enable device does have a DNSSEC-validating resolver either on the device or within an acceptable zone or risk[1] then the chain of trust back up to the root zone of DNS will mean that I will notice a substitution and get a SERVFAIL. It may mean that the attacker could DoS me and prevent me from going to a site, but I don't see where I would wind up on the bogus site. [1] For example, I have a DNSSEC-validating resolver on the edge of my home network. Yes, an attacker could still compromise my home network and send me forged responses. I consider that less likely and am willing to take that risk.

by danyork 12y ago

tptacek 12y ago

What makes you think anyone is going to notice? DNS is a distributed system. The NSA is a byzantine attacker. There is no instantaneous convergence on a single answer; CAP applies; a byzantine DNS attacker can deliberately introduce inconsistent answers. Virtually none of the DNS resolvers in the world also function as inconsistent-answer detectors. There's this weird presumption among DNSSEC advocates that DNS is somehow resilient against targeted attacks (you see it every time an argument lands on "but people will notice that"). No. Not only is that not true, but it's even less true than other protocols where we know that to be true; for instance, BGP4 is also not resilient against byzantine failures, but at least BGP4 updates propagate (BGP4 is like a "PUSH" system in that regard, where DNS is "PULL"). What's even funnier about this "people will notice" objection is that people routinely notice corruption at certificate authorities... and nothing happens to those CAs. Compared to the DNS roots, CAs are trivial to blacklist. Nobody is going to notice targeted attacks on DNS, but even if they did, nothing will happen; there is no disincentive to those attacks for the attackers.

danyork 12y ago
Thomas, I perform DNSSEC validation on the edge of my home office network. All my devices use my DNSSEC-validating DNS resolver on my network server-gateway. That resolver is going to check the DNSSEC chain of trust using DS records all the way up to the root of DNS. If I get back a signed record for www.example.com (meaning an RRSIG), my DNS resolver is going to validate the signatures back up to the root of DNS. If the signatures don't validate, it's going to give me a SERVFAIL and prevent me from going to whatever site I'm trying to get to. If the NSA/GCHQ/whomever wanted to redirect me to another site under their control, they could try to send me the record with a valid RRSIG from their own DNSKEY. My resolver is now going to go to .COM (for example.com) and pull the DS record for "example.com". If the DNSKEY and DS don't match, I'm going to get a SERVFAIL and won't get to the site. Now, the attacker could try to send me their own DS record for the .COM domain... but that's going to be signed by the .COM's DNSKEY ... which again I suppose the attacker could try to send me a substitute. But now my resolver is going to pull a DS record from the root of DNS for the .COM TLD. That DS record will be signed with the DNSKEY of the root. My resolver is going to validate that signed DS record and compare it with the DNSKEY for .COM. If they don't match, I'm going to get a SERVFAIL. Now I guess in theory the attacker could try to send me a DS record for the .COM TLD that is signed by their own key... but here's the thing - my local resolver is already pre-loaded with the public key of the root zone as the trust anchor. So it's not going to trust anyone else's records that purport to be the root zone if the signatures don't match the local trust anchor. So how does the NSA/GCHQ/etc. carry out this attack to redirect me to another site?
- tptacek 12y ago
  I don't understand the point you're trying to make. In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself.
- fragmede 12y ago
  The NSA attack assumes an NSA level attacker has access to the root zone's (or someone else in the chain's) private key. The NSA can then send a key for the .COM TLD that's valid, according to your pre-loaded local resolver, and they can also send a seemingly valid record for example.com. The CA mechanism used for TLS has the same issue. It's not just theoretical either, Gmail and other Google domains had fake certificates that passed validation issued by CNNIC, China's Internet authority, which was discovered earlier this year.
  - danyork 12y ago
    But here's the thing - the root zone's private key for DNSSEC is not in one place. It is spread across a number of smart cards carried by a variety of individuals spread around the world - specifically so that it could not be compromised by governments or others. You can see for yourself exactly what kind of process takes place to use the root key to generate new Zone Signing Keys (ZSKs) every 3 months at the IANA key ceremonies: https://www.iana.org/dnssec/ceremonies https://www.iana.org/dnssec/ceremonies It would be an extremely difficult process for an intelligence agency to subvert, even one with essentially limitless resources.
    - tptacek 12y ago
      But domains under .COM are exactly as trustworthy as Verisign, right? The root key signing ceremonies are just theater, right?
  - danyork 12y ago
    > The CA mechanism used for TLS has the same issue. It's not just theoretical either... Exactly. Which is why so many of us are looking for ways to add an additional layer of trust to the CA system used for TLS. One such mechanism is to use DANE and DNSSEC as an additional mechanism for trust.
danyork 12y ago
tptacek: > I don't understand the point you're trying to make. I am trying to understand how the attack you say is possible truly is possible. > In this case, you're talking about a zone (COM) the USG explicitly controls. They don't need to spoof the delegation from the root to COM, or the anchor key for the root itself. Verisign operates the .COM TLD registry and has documented in excruciating detail how they handle the security of DNSSEC key material: https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf https://www.verisigninc.com/assets/tld-gtld-zone-v1.2.pdf Is your assertion that the NSA would order Verisign to bypass those controls and make a change to a DS record (and associated NS records) to redirect people to another site? If so, how would they do that for just me? It would have to be a much larger redirection of people.
- tptacek 12y ago
  First, Verisign operates the .COM TLD at the pleasure of the US government. Second, if "just trust Verisign" is enough, we're done: just have the browsers only allow Verisign as the TLS CA for .COM names.
  - jamiesonbecker 12y ago
    to tptacek's point - an attacker doesn't need to change the root zone. All they need is the root key. (This argument could be equally made of the CA system.) Then they can sign anything they like, anytime they like, and only for some small targeted set of the population - and for DNSSEC, that's ONLY if you're checking it anyway. (and if you don't control your recursive resolver or patch your browser, tough cookies). @danyork your edge checking is great.. so I presume you never bring your laptop to a coffee shop. ;) Let's not be naive.. as far as root keys go, Verisign is a big company and will promptly hand over any and all keys upon receipt of an NSL or court order and probably just an administrative subpoena. That's how you win and keep massive, government-mandated monopolies to run the world. (To be fair, it's not Verisign's fault that the entire CA system is broken. Oh, wait, actually.. it's exactly Verisign's fault. https://en.wikipedia.org/wiki/Verisign#History https://en.wikipedia.org/wiki/Verisign#History )
    - 12y ago

pingwin 12y ago

I think what tptacek is hinting at is that a nation state could forge roots with their own certificates, creating a separate chain of trust. Given that your internet enabled device does not likely have an DNSSEC validating resolver (with uncompromising trust anchors for the roots) operating on it it's still possible for your device to receive forged responses.

tptacek 12y ago
He knows that; he's saying, if GCHQ did that to tamper with a key stored for a .IO name, the world would notice, because they'd all get that poisoned key. But that's not actually how DNS works.
danyork 12y ago
If your Internet-enabled device doesn't have a DNSSEC-validating resolver (with solid trust anchors for the root zone), then this entire conversation is irrelevant. If your Internet-enable device does have a DNSSEC-validating resolver either on the device or within an acceptable zone or risk[1] then the chain of trust back up to the root zone of DNS will mean that I will notice a substitution and get a SERVFAIL. It may mean that the attacker could DoS me and prevent me from going to a site, but I don't see where I would wind up on the bogus site. [1] For example, I have a DNSSEC-validating resolver on the edge of my home network. Yes, an attacker could still compromise my home network and send me forged responses. I consider that less likely and am willing to take that risk.