5 ms·

> jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure. Please explain how. The whole point of DNSSEC is to provide a cryptographic validation

by danyork 12y ago

> jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure. Please explain how. The whole point of DNSSEC is to provide a cryptographic validation that the material put into DNS by the operator of a zone is the same information you get out of DNS when you perform DNSSEC validation. I'm quite tired of seeing the assertion that "DNSSEC can be re-directed" without people actually walking through HOW that redirection can occur. (Thank you in advance for doing so.)

jocluteseh 12y ago
I'll try to post a comment, but my IP address may be rate limited -- I keep getting "You are posting too fast" errors. In any case, you've made my case for me much better than I could have made it myself. The problem with the 'redirect DNS' argument is that -- it seems -- most people misunderstand that in order to redirect a DNSSEC signed domain, you need to control the 'root' key AND re-sign every domain under that key. So, can it be done? Yes. Is it likely to happen? No. I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.
- jamiesonbecker 12y ago
  > I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero. Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?
  - fragmede 12y ago
    If the MITM is unable to forge a signature that passes validation, and the browser/whatever complains that the signature is invalid, then the game is not over.
    - jamiesonbecker 12y ago
      No signature needed. Just hand out whatever you like for the entire zone. There are several exceptions to the above example. First, if "example.com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example.com" in the "com" zone. If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error. http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Trust_anchors_and_authentication_chains http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...
      - fragmede 12y ago
        If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. That's the second sentence in your quote which seems to say you can't hand out whatever you like for the entire zone, given that .com and .net and .edu have all been signed since 2011.
        jamiesonbecker 12y ago
        Right.. check the rest of the thread above (what good is a signature that no one checks ;) )
        danyork 12y ago
        I agree that signatures are of no value unless validation is done... but please do note that current measurements are showing about 13% of all DNS queries globally are in fact being validated: http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g... If you scroll down that page you'll see higher statistics, such as 70% of all queries being DNSSEC-validated in Sweden, because almost all the ISPs there are now validating. In the USA, about 23% of all DNS queries are being DNSSEC-validated: http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1 http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1 So the argument that "no one is checking" is no longer true.
- jocluteseh 12y ago
  > Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over? Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance. You are much more likely to die by getting run over by an airplane while walking down the road while also holding a Dalmatian over your head, than to have your DNSSEC signed domain redirected. The edge case that's being argued about NSA taking over DNSSEC is rather over done. However, if the argument is denial of requests, so as to block traffic, DNSSEC or not matters not - so the argument again -- is not about DNSSEC as a specific service or architecture.
  - jamiesonbecker 12y ago
    You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption. :) Without those, everything collapses, and even if they're there, you still might be in very real trouble and not even know it. Scenario 1: best of all worlds: you're running an awesome mythical OS (edit: or browser plugin as jocluteseh mentioned below) with up to date root keys and you're trying to get to a single zone and you know the root zone key... but the DNSSEC root key was compromised. No one knew this, because there's no way to detect. Your MITM attacker just forges everything. But you feel secure, since you have DNSSEC. ;) Scenario 2: you're running some really new fancy OS with a pre-shared DNSSEC root key and you make a query for DNSSEC for a zone that you don't have a key for. The recursor simply tells you that that zone doesn't have DNSSEC records. oops. Scenario 3: you're running a current OS without any root zone anchors at all. You make a query to your preferred recursive DNS server (probably whatever you were handed via DHCP) and it just lies to you, about everything. I don't understand your point about probabilities. In each of these scenarios, they're not a 1 in anything chance of getting owned in those circumstances.. that's a 1 in 1 chance. All it took was a MITM. To say nothing of the traffic analysis and complete lack of any sort of encryption for passive MITM's.
  - jocluteseh 12y ago
    > You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption. First: There are two arguments to be had. One is the server side, and one is the browser side. The server is going to know about the key problem if it happens. The client side browser can know, if the client is using plugins like this one: https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ Second: Here is the root key: https://www.iana.org/dnssec/files https://www.iana.org/dnssec/files
jamiesonbecker 12y ago
'quite tired' eh :) jocluteseh is the OP arguing for DNSSEC. That's his quote. tptacek already explained this in some detail in the original article that this article is a rebuttal to. DNSSEC doesn't secure browser lookups: http://marc.info/?l=namedroppers&m=99635022704707&w=2 http://marc.info/?l=namedroppers&m=99635022704707&w=2 DNSSEC only guards against the relatively small problem of cache poisoning for individual records, but it can't even do that properly. It all falls apart w/ MITM and the browser wouldn't even be able to detect MITM since it's relying on a flawed source of truth. http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Section3.4 http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Sect... See tptacek's original post for more info. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/

by danyork 12y ago

jocluteseh 12y ago

I'll try to post a comment, but my IP address may be rate limited -- I keep getting "You are posting too fast" errors. In any case, you've made my case for me much better than I could have made it myself. The problem with the 'redirect DNS' argument is that -- it seems -- most people misunderstand that in order to redirect a DNSSEC signed domain, you need to control the 'root' key AND re-sign every domain under that key. So, can it be done? Yes. Is it likely to happen? No. I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero.

jamiesonbecker 12y ago
> I would argue that the re-direct DNSSEC argument is nearly vanishingly small. But it can't be claimed to be zero. Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over?
- fragmede 12y ago
  If the MITM is unable to forge a signature that passes validation, and the browser/whatever complains that the signature is invalid, then the game is not over.
  - jamiesonbecker 12y ago
    No signature needed. Just hand out whatever you like for the entire zone. There are several exceptions to the above example. First, if "example.com" does not support DNSSEC, there will be no RRSIG record in the answer and there will not be a DS record for "example.com" in the "com" zone. If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error. http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Trust_anchors_and_authentication_chains http://en.wikipedia.org/wiki/Domain_Name_System_Security_Ext...
    - fragmede 12y ago
      If there is a DS record for "example.com", but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. That's the second sentence in your quote which seems to say you can't hand out whatever you like for the entire zone, given that .com and .net and .edu have all been signed since 2011.
      - jamiesonbecker 12y ago
        Right.. check the rest of the thread above (what good is a signature that no one checks ;) )
        danyork 12y ago
        I agree that signatures are of no value unless validation is done... but please do note that current measurements are showing about 13% of all DNS queries globally are in fact being validated: http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g... If you scroll down that page you'll see higher statistics, such as 70% of all queries being DNSSEC-validated in Sweden, because almost all the ISPs there are now validating. In the USA, about 23% of all DNS queries are being DNSSEC-validated: http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1 http://stats.labs.apnic.net/dnssec/US?o=cXAw7x1g0r1 So the argument that "no one is checking" is no longer true.
jocluteseh 12y ago
> Fair enough.. but if you're talking to a MITM anyway, would you agree that it's game over? Don't think: 1/10,000 chance. Think: 1/1,000,000,000,000,000,000,000 chance. You are much more likely to die by getting run over by an airplane while walking down the road while also holding a Dalmatian over your head, than to have your DNSSEC signed domain redirected. The edge case that's being argued about NSA taking over DNSSEC is rather over done. However, if the argument is denial of requests, so as to block traffic, DNSSEC or not matters not - so the argument again -- is not about DNSSEC as a specific service or architecture.
- jamiesonbecker 12y ago
  You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption. :) Without those, everything collapses, and even if they're there, you still might be in very real trouble and not even know it. Scenario 1: best of all worlds: you're running an awesome mythical OS (edit: or browser plugin as jocluteseh mentioned below) with up to date root keys and you're trying to get to a single zone and you know the root zone key... but the DNSSEC root key was compromised. No one knew this, because there's no way to detect. Your MITM attacker just forges everything. But you feel secure, since you have DNSSEC. ;) Scenario 2: you're running some really new fancy OS with a pre-shared DNSSEC root key and you make a query for DNSSEC for a zone that you don't have a key for. The recursor simply tells you that that zone doesn't have DNSSEC records. oops. Scenario 3: you're running a current OS without any root zone anchors at all. You make a query to your preferred recursive DNS server (probably whatever you were handed via DHCP) and it just lies to you, about everything. I don't understand your point about probabilities. In each of these scenarios, they're not a 1 in anything chance of getting owned in those circumstances.. that's a 1 in 1 chance. All it took was a MITM. To say nothing of the traffic analysis and complete lack of any sort of encryption for passive MITM's.
- jocluteseh 12y ago
  > You are assuming that your client OS/browser DNS resolvers have the pre-shared trust anchors for whichever root zone. That's kind of a big assumption. First: There are two arguments to be had. One is the server side, and one is the browser side. The server is going to know about the key problem if it happens. The client side browser can know, if the client is using plugins like this one: https://www.dnssec-validator.cz/ https://www.dnssec-validator.cz/ Second: Here is the root key: https://www.iana.org/dnssec/files https://www.iana.org/dnssec/files

jamiesonbecker 12y ago

'quite tired' eh :) jocluteseh is the OP arguing for DNSSEC. That's his quote. tptacek already explained this in some detail in the original article that this article is a rebuttal to. DNSSEC doesn't secure browser lookups: http://marc.info/?l=namedroppers&m=99635022704707&w=2 http://marc.info/?l=namedroppers&m=99635022704707&w=2 DNSSEC only guards against the relatively small problem of cache poisoning for individual records, but it can't even do that properly. It all falls apart w/ MITM and the browser wouldn't even be able to detect MITM since it's relying on a flawed source of truth. http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Section3.4 http://www.cse.wustl.edu/~jain/cse571-07/ftp/cafecrack/#Sect... See tptacek's original post for more info. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ http://sockpuppet.org/blog/2015/01/15/against-dnssec/