9 ms·

In Defense of DNSSEC

15 points by jocluteseh 12y ago

tptacek 12y ago
I read this thing so you don't have to. Here's a summary of what I believe this person's arguments to be. If I've failed to be charitable enough, please do call me out for that. 1. With DNSSEC, SPF, DKIM, and DMARC enabled, email is secure enough to authenticate requests for TLS certificates. Without DNSSEC, it isn't. 2. DNSSEC zone owners control their keys, so DNSSEC doesn't imply that the DNS roots control keys. 3. There is nothing wrong with older cryptosystems and anyways, DNSSEC supports elliptic curve now. 4. The code to make DNSSEC deployable is underway and so it's not valid to suggest that it's too expensive to support. 5. All that's required of DNSSEC deployers is to generate a couple of DNS records, and so it can't be expensive to to deploy. 6. It's specious to criticize DNSSEC for only securing server-server transactions and not browser-server DNS lookups. 7. Nobody ever said DNSSEC would provide end-to-end encryption. DNSSEC reveals hostnames now, but there's something called NSEC5 that's going to make that better. 8. Nobody ever said DNSSEC was going to provide end-to-end security so it's not valid to criticize DNSSEC for not doing that. 9. DNSSEC isn't a replacement for the CA system, but rather a security improvement for DNS, so comparisons to TLS and CA aren't valid.
- tptacek 12y ago
  Well, allow me to retort: 1. SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. Making it secure is the biggest problem in Internet cryptography and we aren't anywhere near solving it. If domain-validated certificates scare you, the solution is to eliminate DV certs. 2. The roots control delegations. The keys you store in your zone don't matter if surveillance targets never see them, because the government-controlled roots switch delegations to zones they control. DNSSEC is a PKI controlled by NSA and GCHQ. That is literally what it is is. 3. DNSSEC is 90s cryptography. 90s cryptography has been discredited. The DNSSEC roots use an archaic flavor of RSA. ECC DNSSEC records break zillions of deployed implementations. The flavor of ECC that DNSSEC supports is also archaic. This stuff is in the FAQ for the post they're rebutting. 4. The phrase "good money after bad" comes to mind. 5. Here is a list of major DNSSEC outages. DNSSEC reliability is komedy gold: http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html 6. No it's not. 7. 7 years ago, this argument would have been written "DNSSEC reveals hostnames now, but there's something called NSEC3 that's going to make that better". 8. There is a finite amount of money and energy to be spent on cryptographically improving core Internet infrastructure, and the many deficiencies of DNSSEC are why virtually nobody credible in the cryptographic engineering community thinks DNSSEC is a good use of that money. We can't spend tens of millions of dollars forklifting in a baroque new cryptosystem that doesn't actually encrypt anything. 9. The sole important application for DNSSEC is storage of TLS certificates.
  - jocluteseh 12y ago
    1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree? 2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control. 3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense. 4. Only if you don't value the hard work by many smart people over a long time. 5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4. 6. Yes it is. 7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self? 8. Again with the 'old' is bad 'new' is better? Got anything else? 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. However, for a small domain, DNSSEC is terrific.
    - tptacek 12y ago
      1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys. 2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC. 3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on. 4. That's not an argument. 5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated. 6. That's not an argument either. 7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant. 8. Non sequitur. 9. I'm not smart enough to understand what this argument means.
- marcosdumay 12y ago
  Well, about #2, people are defending the status quo (where any governemnt anywhere on the world can compromisse a site's key) by arguing that with DNSSEC there'll always be one government able to compromisse any site's key. Calling that a falacious argument is too charitable, it's an outright lie (and I wonder why that piece of propaganda is so pervasive). About #3 the article simply points that there's nothing wrong with DNSSEC, unless you choose to use bad crypto algorithms. Guess what, any cryptosystem works the same way, TLS included. About #6, yes, it's specious to criticize DNSSEC because browsers choosed to not support it (unless you are talking from the point of view of a site master wondering how you'll configure your host today - but even then, that's not a valid criticism of the algorithm, it's just reason to not deploy it now). About #8, yes, that's not valid. DANE is the main end-to-end encryption algorithm that used DNSSEC, so one must either criticize DANE (if able) or shut-up. Anyway, what a badly formated page. Points #1, 4, 5 and 7 are flaws. Point #7 is a big flaw, and don't hold your breath waiting for it to be solved. I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I can't see where the author is going...
  - jocluteseh 12y ago
    Fixed formatting a little here: http://shortText.com/6308c7af http://shortText.com/6308c7af
  - rakoo 12y ago
    > I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I'd say DNSSEC is more broken than the current CA system. At least with the current system you can more or less choose a CA to trust (or, more interestingly, a bunch of CAs), that you can change anytime you want. The only thing preventing you to do it is the lack of tools to actually do it, which is why tools such as TACK/HPKP, or Convergence/Perspectives, are needed. With DNSSEC, there is only one realistic root ever possible (call it ICANN or NSA as you want, that's yet another problem)
    - marcosdumay 12y ago
      > At least with the current system you can more or less choose a CA to trust Blind illusion. You must trust all of them. Any of them can attest somebody is you any time they want. The good thing about DNSSEC is exactly that it only has one root. And people can pin second and third level domains, completely escaping it - for some other org, controlled by some other agency, but one can choose what agency to submit their identity.
joshuafalken 12y ago
Page seems down; cached version: http://webcache.googleusercontent.com/search?q=cache:_q7stvYH64MJ:shorttext.com/63084847+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:_q7stvY...
deleted 12y ago
[deleted]
gwu78 12y ago
Ask HN: I am asked would I prefer 1. to have a pre-generated cryptographic "signature" of every www page that can be checked against some centralized repository for "authenticity" or 2. to encrypt every www page before transmission or at least have it encrypted in transit? "Both" is not an valid choice. I have no idea why not; as far as I can tell, they are not mutually exclusive. Because I mindlessly support SSL (let's encrypt!) I choose option 2 over option 1. Now I am asked the same question regarding DNS packets. 1. Sign the packets or 2. encrypt them? Do I still choose option 2 over option 1? If I choose 1, those DNS requests will be unencrypted plain text like unencrypted HTTP. Maybe DNSSEC has nothing to do with privacy regarding DNS requests?
- danyork 12y ago
  > Maybe DNSSEC has nothing to do with privacy regarding DNS requests? DNSSEC has nothing to do with privacy. DNSSEC is entirely about the integrity of DNS requests. DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about. That's it. DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.
  - colmmacc 12y ago
    DNSSEC is probably better described as a mechanism to prevent cache poisoning; which is different from the "modified in transit" case. DNSSEC isn't very useful for defending against a MITM: 1. If the MITM goal is to block your domain, they still can by dropping the queries or replies. 2. If the MITM goal is to intercept your content, they don't need to rewrite DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here. Additionally, if the MITM is between you and your resolver: for example in the Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do not validate.
    - danyork 12y ago
      colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query. Yes, "cache poisoning". Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there. If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there. If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater. This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.
danyork 12y ago
jocluteseh - your site seems to be down now (perhaps buried under HN traffic). Perhaps post it as a gist on Github or something like that? https://gist.github.com/ https://gist.github.com/
- jocluteseh 12y ago
  Done... enjoy... or not, but just make sure the beer is cold. https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-poorly_formatted_dnssec_rubuttal https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-...
jamiesonbecker 12y ago
jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure. jocluteseh: DKIM signs the message and provides a body hash which is validated against the public key in DNS. tptacek: SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. in short: DNSSEC and SMTP hang together by threads. cut one thread and the whole thing collapses. "It's better than what we have right now" isn't an argument because we actually don't have it anyway. tptacek is 100% correct.
- 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?
peterwwillis 12y ago
Before I pick apart the obvious points, keep this in mind: do you __need__ DNSSEC right now? Not would it be helpful or nice or make things a bit more secure, but do you need it? -- > 1. DNSSEC is better than no DNSSEC. You can't use your argument to defend your argument; this is circular reasoning and therefore illogical. Also, the commenter has no idea what protocols use crypto in what way as many of them are proprietary. > 4. [...]There may need to be some software adjustments to fully accommodate DNSSEC. However, there currently exist several DNSSEC plugins, extensions, or modules for several end user browsers. Thus, the code base has already been started, making improvements and merging code bases is the next step. This is like saying "Replacing cars with driverless cars just requires a software update". Yeah. On every car and road. No biggie. I'll put it all on my Visa. > In short, if a devops can type a few characters in a DNS record, a devops can deploy DNSSEC within a few hours depending on the domain complexity. You don't need to be "a devops" to make a DNS record change, but ideally you would call this person the domain name record owner or DNS administrator. This shows little understanding of how DNS is deployed in the real world. > Generally #6 is specious. If you consider "we have to upgrade our OS on all our systems - which may range from 1 to 100,000 depending on the organization - to gain a marginal amount of security we didn't need before" to be specious [assuming Windows comes with a validating stub resolver now]. > There is a vulnerability in DNSSEC, that is openly listed in the RFCs, that indicates subdomains are enumerated. [..] However, for simple domains with a few hosts, enumerated architectures should be a minor problem if a problem at all. "Please ignore this information leak." > This sockpuppet Anti-DNSSEC rant is inaccurate, incomplete, and presents a picture of DNSSEC that is unsupported factually, mathematically, and architecturally. "I can't argue the point that we don't need DNSSEC, so let's just throw some hyperbole around and hope nobody notices I don't even try to prove my claims."
xorcist 12y ago
It's a bit pointless to argue for or against DNSSEC. It exists, and if you are fishing for larger customers in the hosting business, you already have had to relate to that. It is, for better or for worse, infrastructure. You can have informed opinions on how to change it, just like you can argue for changes in the TLS protocol to extend it or modernize the crypographic primitives. But a fundamentally different protocol would need a clean start, and would need to offer enough advantages to get people to switch. These global systems takes a decade to change, at best, and it can be done. While I would love for both TLS, IPsec and DNSSEC to have been designed differently from the start (i.e. without X509), that's not where we are today. As for the basic idea, it is wise to ask yourself: Would it be useful for registrars to prove domain ownership cryptographically? If you think that could be put to good use, you will understand the basic premise and what the protocol was designed for.

15 points by jocluteseh 12y ago

I read this thing so you don't have to. Here's a summary of what I believe this person's arguments to be. If I've failed to be charitable enough, please do call me out for that. 1. With DNSSEC, SPF, DKIM, and DMARC enabled, email is secure enough to authenticate requests for TLS certificates. Without DNSSEC, it isn't. 2. DNSSEC zone owners control their keys, so DNSSEC doesn't imply that the DNS roots control keys. 3. There is nothing wrong with older cryptosystems and anyways, DNSSEC supports elliptic curve now. 4. The code to make DNSSEC deployable is underway and so it's not valid to suggest that it's too expensive to support. 5. All that's required of DNSSEC deployers is to generate a couple of DNS records, and so it can't be expensive to to deploy. 6. It's specious to criticize DNSSEC for only securing server-server transactions and not browser-server DNS lookups. 7. Nobody ever said DNSSEC would provide end-to-end encryption. DNSSEC reveals hostnames now, but there's something called NSEC5 that's going to make that better. 8. Nobody ever said DNSSEC was going to provide end-to-end security so it's not valid to criticize DNSSEC for not doing that. 9. DNSSEC isn't a replacement for the CA system, but rather a security improvement for DNS, so comparisons to TLS and CA aren't valid.

tptacek 12y ago
Well, allow me to retort: 1. SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. Making it secure is the biggest problem in Internet cryptography and we aren't anywhere near solving it. If domain-validated certificates scare you, the solution is to eliminate DV certs. 2. The roots control delegations. The keys you store in your zone don't matter if surveillance targets never see them, because the government-controlled roots switch delegations to zones they control. DNSSEC is a PKI controlled by NSA and GCHQ. That is literally what it is is. 3. DNSSEC is 90s cryptography. 90s cryptography has been discredited. The DNSSEC roots use an archaic flavor of RSA. ECC DNSSEC records break zillions of deployed implementations. The flavor of ECC that DNSSEC supports is also archaic. This stuff is in the FAQ for the post they're rebutting. 4. The phrase "good money after bad" comes to mind. 5. Here is a list of major DNSSEC outages. DNSSEC reliability is komedy gold: http://ianix.com/pub/dnssec-outages.html http://ianix.com/pub/dnssec-outages.html 6. No it's not. 7. 7 years ago, this argument would have been written "DNSSEC reveals hostnames now, but there's something called NSEC3 that's going to make that better". 8. There is a finite amount of money and energy to be spent on cryptographically improving core Internet infrastructure, and the many deficiencies of DNSSEC are why virtually nobody credible in the cryptographic engineering community thinks DNSSEC is a good use of that money. We can't spend tens of millions of dollars forklifting in a baroque new cryptosystem that doesn't actually encrypt anything. 9. The sole important application for DNSSEC is storage of TLS certificates.
- jocluteseh 12y ago
  1. Why? An unqualified blanket statement does not prove anything. SPF, DKIM, DMARC provide strong cryptographical ties to a specific, real, and verified account holder. DNSSEC provides domain level certification. So, with all four items, there is a very strong assurance level of the validity of the email account holder. Do you honestly disagree? 2. Can DNSSEC be re-directed to incorrect public keys? Sure. But DNS can be pointed anywhere anyway. DNSSEC does no extra damage. And exploitation of DNSSEC enabled domain records is very easily discoverable by the domain holder, since the public key will no longer match the domain's private key... which is still very much in the domain owner's control. 3. Much of cryptography dates to the 1950s. This '90s cryptography stuff is pure nonsense. 4. Only if you don't value the hard work by many smart people over a long time. 5. OK. Denial of service is a bad thing. If you have a worldwide network, you are going to have denial of service. Mitigation is possible... maybe instead of throwing out other people's work, some resources could be used to improve what's already out there... ah... but then back #4. 6. Yes it is. 7. Revealing hostnames is only a problem if a domain is seeking to hide hosts. So, this particular issue is domain level dependent -- why not let a domain owner speak for him/her self? 8. Again with the 'old' is bad 'new' is better? Got anything else? 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. However, for a small domain, DNSSEC is terrific.
  - tptacek 12y ago
    1. Because SMTP email transmits unencrypted messages through a series of insecure relay servers. SMTP is insecure. The protocols you mentioned are band-aids that do not result in SMTP being end-to-end secure. But that's what SMTP needs to be if all of Internet security is going to rely on it to authenticate keys. 2. The point of argument #2 is that the government's ability to poison the DNS makes it unsuitable for storing end-user keys, which, no matter what the DNSSEC deployment goal you have in mind is, is the core function of DNSSEC. 3. Elliptic curve cryptography is from the 1980s. Secure elliptic curve functions take you to the early 2000s. Authenticated encryption functions are late 90s early 2000s. The first error oracle attack was published in the early 2000s; practically all cryptography designed prior to that was designed ignorant to the concept of an error oracle. I could go on. 4. That's not an argument. 5. The problem with DNSSEC isn't that it makes DDoS attackers easier, although it does. The problem is DNSSEC spontaneously kills sites because it is calamitously easy to screw up, because it is very complicated. 6. That's not an argument either. 7. Virtually every Fortune 500 company on the Internet currently depends on some way on hidden hostnames. You more or less admit that this is a real problem when you cite NSEC5 as a step forward; it would be unnecessary if you were right that hidden hostnames were unimportant. 8. Non sequitur. 9. I'm not smart enough to understand what this argument means.
marcosdumay 12y ago
Well, about #2, people are defending the status quo (where any governemnt anywhere on the world can compromisse a site's key) by arguing that with DNSSEC there'll always be one government able to compromisse any site's key. Calling that a falacious argument is too charitable, it's an outright lie (and I wonder why that piece of propaganda is so pervasive). About #3 the article simply points that there's nothing wrong with DNSSEC, unless you choose to use bad crypto algorithms. Guess what, any cryptosystem works the same way, TLS included. About #6, yes, it's specious to criticize DNSSEC because browsers choosed to not support it (unless you are talking from the point of view of a site master wondering how you'll configure your host today - but even then, that's not a valid criticism of the algorithm, it's just reason to not deploy it now). About #8, yes, that's not valid. DANE is the main end-to-end encryption algorithm that used DNSSEC, so one must either criticize DANE (if able) or shut-up. Anyway, what a badly formated page. Points #1, 4, 5 and 7 are flaws. Point #7 is a big flaw, and don't hold your breath waiting for it to be solved. I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I can't see where the author is going...
- jocluteseh 12y ago
  Fixed formatting a little here: http://shortText.com/6308c7af http://shortText.com/6308c7af
- rakoo 12y ago
  > I'd say about point #9 is that DNSSEC is exactly a less broken CA system. I'd say DNSSEC is more broken than the current CA system. At least with the current system you can more or less choose a CA to trust (or, more interestingly, a bunch of CAs), that you can change anytime you want. The only thing preventing you to do it is the lack of tools to actually do it, which is why tools such as TACK/HPKP, or Convergence/Perspectives, are needed. With DNSSEC, there is only one realistic root ever possible (call it ICANN or NSA as you want, that's yet another problem)
  - marcosdumay 12y ago
    > At least with the current system you can more or less choose a CA to trust Blind illusion. You must trust all of them. Any of them can attest somebody is you any time they want. The good thing about DNSSEC is exactly that it only has one root. And people can pin second and third level domains, completely escaping it - for some other org, controlled by some other agency, but one can choose what agency to submit their identity.

joshuafalken 12y ago

Page seems down; cached version: http://webcache.googleusercontent.com/search?q=cache:_q7stvYH64MJ:shorttext.com/63084847+&cd=1&hl=en&ct=clnk&gl=us http://webcache.googleusercontent.com/search?q=cache:_q7stvY...

deleted 12y ago

[deleted]

gwu78 12y ago

Ask HN: I am asked would I prefer 1. to have a pre-generated cryptographic "signature" of every www page that can be checked against some centralized repository for "authenticity" or 2. to encrypt every www page before transmission or at least have it encrypted in transit? "Both" is not an valid choice. I have no idea why not; as far as I can tell, they are not mutually exclusive. Because I mindlessly support SSL (let's encrypt!) I choose option 2 over option 1. Now I am asked the same question regarding DNS packets. 1. Sign the packets or 2. encrypt them? Do I still choose option 2 over option 1? If I choose 1, those DNS requests will be unencrypted plain text like unencrypted HTTP. Maybe DNSSEC has nothing to do with privacy regarding DNS requests?

danyork 12y ago
> Maybe DNSSEC has nothing to do with privacy regarding DNS requests? DNSSEC has nothing to do with privacy. DNSSEC is entirely about the integrity of DNS requests. DNSSEC is focused on ensuring that the information you get OUT of DNS in response to a query is identify to the information that was put IN to DNS by the operator of the domain you are querying DNS about. That's it. DNSSEC is a focused mechanism to ensure the DNS records have not been modified in transit between the authoritative DNS server for a domain and whatever DNS client is performing the DNSSEC validation.
- colmmacc 12y ago
  DNSSEC is probably better described as a mechanism to prevent cache poisoning; which is different from the "modified in transit" case. DNSSEC isn't very useful for defending against a MITM: 1. If the MITM goal is to block your domain, they still can by dropping the queries or replies. 2. If the MITM goal is to intercept your content, they don't need to rewrite DNS; they can do it at TCP level. TLS/SSL is the effective mitigation here. Additionally, if the MITM is between you and your resolver: for example in the Café wifi case - DNSSEC is no help at all. Since stub resolvers and clients do not validate.
  - danyork 12y ago
    colmmacc - I was thinking more of a case where the attacker is doing a MITM on your DNS info, i.e. getting between you and the DNS server authoritative for the domain you want to connect to in order to redirect you to another site. My use of "modified in transit" was to the DNS query. Yes, "cache poisoning". Agree with your last point. DNSSEC only helps provide integrity validation down to the point of wherever the actual DNSSEC validation occurs. In the most secure form, that validation would occur on your actual device (i.e. the stub resolver) or in your application (some now are building DNSSEC validation in, ex. the Jitsi softphone). I know some folks who run Unbound (or DNSSEC-Trigger) on their laptops to have the validation occurring there. If you rely on the DNSSEC validation to occur at your ISP (ex. Comcast in the US) your zone of attack exposure is then your local network and the connection to your ISP... so yes, and attacker could potentially inject bogus responses there. If you rely on DNSSEC validation out at a public server such as Google's Public DNS... well... then your zone of exposure is much greater. This is where the work going on within the DPRIVE working group within the IETF is so important. They are developing mechanisms to secure the confidentiality and integrity of the connection between your stub resolver / client and the recursive resolver you use. With DPRIVE covering your connection, you could use a DNSSEC-validating resolver that was farther away from you.

danyork 12y ago

jocluteseh - your site seems to be down now (perhaps buried under HN traffic). Perhaps post it as a gist on Github or something like that? https://gist.github.com/ https://gist.github.com/

jocluteseh 12y ago
Done... enjoy... or not, but just make sure the beer is cold. https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-poorly_formatted_dnssec_rubuttal https://gist.github.com/anonymous/3f36dfeb3297e184417b#file-...

jamiesonbecker 12y ago

jocluteseh: Can DNSSEC be re-directed to incorrect public keys? Sure. jocluteseh: DKIM signs the message and provides a body hash which is validated against the public key in DNS. tptacek: SMTP email isn't end-to-end secure with DNSSEC, SPF, DKIM, and DMARC. It isn't even close. It is unsafe to authenticate CA certificate requests via email before DNSSEC and remains so after DNSSEC. SMTP is insecure. in short: DNSSEC and SMTP hang together by threads. cut one thread and the whole thing collapses. "It's better than what we have right now" isn't an argument because we actually don't have it anyway. tptacek is 100% correct.

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?

peterwwillis 12y ago

Before I pick apart the obvious points, keep this in mind: do you __need__ DNSSEC right now? Not would it be helpful or nice or make things a bit more secure, but do you need it? -- > 1. DNSSEC is better than no DNSSEC. You can't use your argument to defend your argument; this is circular reasoning and therefore illogical. Also, the commenter has no idea what protocols use crypto in what way as many of them are proprietary. > 4. [...]There may need to be some software adjustments to fully accommodate DNSSEC. However, there currently exist several DNSSEC plugins, extensions, or modules for several end user browsers. Thus, the code base has already been started, making improvements and merging code bases is the next step. This is like saying "Replacing cars with driverless cars just requires a software update". Yeah. On every car and road. No biggie. I'll put it all on my Visa. > In short, if a devops can type a few characters in a DNS record, a devops can deploy DNSSEC within a few hours depending on the domain complexity. You don't need to be "a devops" to make a DNS record change, but ideally you would call this person the domain name record owner or DNS administrator. This shows little understanding of how DNS is deployed in the real world. > Generally #6 is specious. If you consider "we have to upgrade our OS on all our systems - which may range from 1 to 100,000 depending on the organization - to gain a marginal amount of security we didn't need before" to be specious [assuming Windows comes with a validating stub resolver now]. > There is a vulnerability in DNSSEC, that is openly listed in the RFCs, that indicates subdomains are enumerated. [..] However, for simple domains with a few hosts, enumerated architectures should be a minor problem if a problem at all. "Please ignore this information leak." > This sockpuppet Anti-DNSSEC rant is inaccurate, incomplete, and presents a picture of DNSSEC that is unsupported factually, mathematically, and architecturally. "I can't argue the point that we don't need DNSSEC, so let's just throw some hyperbole around and hope nobody notices I don't even try to prove my claims."

xorcist 12y ago

It's a bit pointless to argue for or against DNSSEC. It exists, and if you are fishing for larger customers in the hosting business, you already have had to relate to that. It is, for better or for worse, infrastructure. You can have informed opinions on how to change it, just like you can argue for changes in the TLS protocol to extend it or modernize the crypographic primitives. But a fundamentally different protocol would need a clean start, and would need to offer enough advantages to get people to switch. These global systems takes a decade to change, at best, and it can be done. While I would love for both TLS, IPsec and DNSSEC to have been designed differently from the start (i.e. without X509), that's not where we are today. As for the basic idea, it is wise to ask yourself: Would it be useful for registrars to prove domain ownership cryptographically? If you think that could be put to good use, you will understand the basic premise and what the protocol was designed for.