4 ms·

> 9. I'm not smart enough to understand what this argument means. Thomas, I _think_ you are replying to this: > 9. Wrong. SSH public keys, Email public keys,

by danyork 12y ago

> 9. I'm not smart enough to understand what this argument means. Thomas, I _think_ you are replying to this: > 9. Wrong. SSH public keys, Email public keys, DKIM public keys... check your email headers from Google... they all have "unprotected key" because Google doesn't use DNSSEC -- the large provider host hiding problem is most likely why. With which I'll agree with jocluteseh that the value DNSSEC can bring is far larger than only TLS certificates - although I agree with you that protection of TLS certs is one value it brings. There are people using DNS/DNSSEC to secure the storage of SSH public keys, of PGP public keys and other similar public keys. People are putting those keys in DNS and then using DNSSEC to ensure that someone retrieving those keys and performing DNSSEC validation can be sure they are getting the correct keys associated with that domain.

tptacek 12y ago
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?
- pyre 12y ago
  To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either: 1. Pull the public key from DNS to add to ~/.ssh/authorized_keys 2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea. Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
  - danyork 12y ago
    The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case: http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255 When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.) The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key. Do note this is not a new idea. This RFC was published back in 2006.
- xorcist 12y ago
  The NSA can take any one of their trusted root keys, which I don't think it would be healthy to doubt they are in possession of, and sign a certificate today. With DNSSEC, they'd have to subvert the entire DNS infrastructure, signed from the top all the way down to the particular domain they want to falsify. But it is somehow this infrastructure you wish to label "NSA controlled"?
  - tptacek 12y ago
    What difference does it make whether the program they run to carry out this attack is 100 lines long or 400 lines long? DNSSEC gives NSA and GCHQ this level of control by design. It is a PKI, based on delegations from a root, where the top of the tree is literally controlled by the US and UK governments.
    - xorcist 12y ago
      The difference is not in the complexity of the code, but the magnitude of the attack. You would need to subvert every DNS request from a certain client, for the duration of the TTL of all signature points. (Exactly how much harder it is depends on the circumstances, but a travelling target would be even harder than a well known stationary one, even if you control large parts of Internet infrastructure and is willing to use it.) But that's not the point. The only point is that between it and the SSL CA infrastructure, the latter is the one NSA has more control over and a much easier time generating certificates for, so the labelling the former "NSA controlled" is slightly disingenious.
      - tptacek 12y ago
        You don't like the CA system. I don't either. I go farther, and say "it's a very bad idea to replace the CA system with another hierarchical PKI the top of which is controlled be NSA and GCHQ". I'm not sure I understand your rebuttal to that point.
        xorcist 12y ago
        Because it is not "controlled" by the NSA in any meaningful way (with emphasis on meaningful). Any such argument would be valid for pretty any global PKI system, if the argument is that they control important parts of the Internet infrastructure. The SSL CA system is even more controlled by the NSA as DNSSEC is. DNSSEC is much harder to circumvent than the SSL CA system, no matter how you look at it. So I do not mean to refute that the NSA controls the Internet, the CA system, and DNSSEC (even if I don't believe that's an accurate description). It is simply not a meaningful discussion to have. Even if the NSA can break the Internet, there are other use cases and it still carries great value for everyone.
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?

by danyork 12y ago

tptacek 12y ago

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?

pyre 12y ago
To expand on this. If you store your public SSH key in DNSSEC, I'm assuming that the use-case is either: 1. Pull the public key from DNS to add to ~/.ssh/authorized_keys 2. Implement an sshd runtime that checks the DNS record rather then (or in addition to) ~/.ssh/authorized_keys Sure, it's "just" the public key so you're not providing the private key to the world-at-large, but if the NSA controls DNSSEC, then they can change the public key to one that is paired with a private key that they control. Now they have access to all systems that the public key could access. This is basically adding DNSSEC as an attack vector to your ~/.ssh/authorized_keys file, which seems like a bad idea. Please correct me if I'm missing something about how DNSSEC and SSH keys would be used together.
- danyork 12y ago
  The idea would be to enable you to verify the public key of a server to which you are connecting for the first time. RFC 4255 outlines this use case: http://tools.ietf.org/html/rfc4255 http://tools.ietf.org/html/rfc4255 When you first connect and get the SSH fingerprint, how many people truly validate through some other mechanism that this is the correct public key to use for some system? (I have on some systems but I know I have just accepted the public key on other systems.) The idea is to use DNSSEC and the SSHFP record to provide a mechanism to validate the SSH public key. Do note this is not a new idea. This RFC was published back in 2006.
xorcist 12y ago
The NSA can take any one of their trusted root keys, which I don't think it would be healthy to doubt they are in possession of, and sign a certificate today. With DNSSEC, they'd have to subvert the entire DNS infrastructure, signed from the top all the way down to the particular domain they want to falsify. But it is somehow this infrastructure you wish to label "NSA controlled"?
- tptacek 12y ago
  What difference does it make whether the program they run to carry out this attack is 100 lines long or 400 lines long? DNSSEC gives NSA and GCHQ this level of control by design. It is a PKI, based on delegations from a root, where the top of the tree is literally controlled by the US and UK governments.
  - xorcist 12y ago
    The difference is not in the complexity of the code, but the magnitude of the attack. You would need to subvert every DNS request from a certain client, for the duration of the TTL of all signature points. (Exactly how much harder it is depends on the circumstances, but a travelling target would be even harder than a well known stationary one, even if you control large parts of Internet infrastructure and is willing to use it.) But that's not the point. The only point is that between it and the SSL CA infrastructure, the latter is the one NSA has more control over and a much easier time generating certificates for, so the labelling the former "NSA controlled" is slightly disingenious.
    - tptacek 12y ago
      You don't like the CA system. I don't either. I go farther, and say "it's a very bad idea to replace the CA system with another hierarchical PKI the top of which is controlled be NSA and GCHQ". I'm not sure I understand your rebuttal to that point.
      - xorcist 12y ago
        Because it is not "controlled" by the NSA in any meaningful way (with emphasis on meaningful). Any such argument would be valid for pretty any global PKI system, if the argument is that they control important parts of the Internet infrastructure. The SSL CA system is even more controlled by the NSA as DNSSEC is. DNSSEC is much harder to circumvent than the SSL CA system, no matter how you look at it. So I do not mean to refute that the NSA controls the Internet, the CA system, and DNSSEC (even if I don't believe that's an accurate description). It is simply not a meaningful discussion to have. Even if the NSA can break the Internet, there are other use cases and it still carries great value for everyone.

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?