Universal DNSSEC: Secure DNS for Every Domain(blog.cloudflare.com)
blog.cloudflare.com
Universal DNSSEC: Secure DNS for Every Domain
https://blog.cloudflare.com/introducing-universal-dnssec/
8 comments
...its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
ISTM this could at least be a transparency win, for average users. If trust went by TLD, we'd know that e.g. using "bit.ly" required trusting the Libyan domain admins. With CAs now, we just get a pile of CAs pre-installed with our OS or browser, and a bit of knowledgeable clicking is required in order to determine which CAs are trusted for any particular transaction. [EDIT: and in a sense, we are still trusting the Libyan domain admins.]
Whether one views the combination of CAs and TLD registrars that we have now as "defense in depth" or "more links in a chain" sort of depends on your threat model. Personally I'm more worried about identity thieves than oppressive governments, but others might have different concerns.
This may not offset the other problems you've identified.
ISTM this could at least be a transparency win, for average users. If trust went by TLD, we'd know that e.g. using "bit.ly" required trusting the Libyan domain admins. With CAs now, we just get a pile of CAs pre-installed with our OS or browser, and a bit of knowledgeable clicking is required in order to determine which CAs are trusted for any particular transaction. [EDIT: and in a sense, we are still trusting the Libyan domain admins.]
Whether one views the combination of CAs and TLD registrars that we have now as "defense in depth" or "more links in a chain" sort of depends on your threat model. Personally I'm more worried about identity thieves than oppressive governments, but others might have different concerns.
This may not offset the other problems you've identified.
With key-pinning and standard TLS, we get transparency, a consequence for CAs who are subverted, and an Internet trust system that remains formally decoupled from government control. Even if 95% of users don't use browsers that reliably enforce pins, the 5% that do constitute a multi- million- node CA-forgery detection system. One, by the way, that is probably already working today (CT also has some wins here).
With DNSSEC, we get the knowledge that a .LY domain probably has TLS keys controlled by Libya, and, if we're very savvy, the knowledge that .IO keys are controlled by GCHQ. We don't get consequences (you can't take .IO away from its owners, and Google simply isn't going to move from .COM, which is controlled by NSA), and we only get pinning's security with many more years of effort that haven't yet been sunk into DANE.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
With DNSSEC, we get the knowledge that a .LY domain probably has TLS keys controlled by Libya, and, if we're very savvy, the knowledge that .IO keys are controlled by GCHQ. We don't get consequences (you can't take .IO away from its owners, and Google simply isn't going to move from .COM, which is controlled by NSA), and we only get pinning's security with many more years of effort that haven't yet been sunk into DANE.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
Not "controlled by Lybia" of course, but "controlled the domain owner, as specified by the TLD", but you knew that already.
And not all ccTLDs are controlled by that country's authorities, they are normally delegated to other organizations which in some cases may not even be under their jurisdiction.
There's also no movement of control to "governments". The entity that controls the TLD has authority over DNS, today, and the one with authority over DNS are in full control over DLV TLS certificates, today. Any pinning and transparency checks would work unimpeded in a DNSSEC world.
DNSSEC just makes it much harder to improperly get an TLS certificate. Today you just need to annouce their AS for a while, or cache spoof any of the hundreds of CAs. No CA has ever been dropped for signing a certificate by the rules. The only reason we don't see that more is because it's apparently even easier to bribe or force a CA to give them out. NSA certainly doesn't need to attack anything to get certificates issued, today.
And not all ccTLDs are controlled by that country's authorities, they are normally delegated to other organizations which in some cases may not even be under their jurisdiction.
There's also no movement of control to "governments". The entity that controls the TLD has authority over DNS, today, and the one with authority over DNS are in full control over DLV TLS certificates, today. Any pinning and transparency checks would work unimpeded in a DNSSEC world.
DNSSEC just makes it much harder to improperly get an TLS certificate. Today you just need to annouce their AS for a while, or cache spoof any of the hundreds of CAs. No CA has ever been dropped for signing a certificate by the rules. The only reason we don't see that more is because it's apparently even easier to bribe or force a CA to give them out. NSA certainly doesn't need to attack anything to get certificates issued, today.
Any CCTLD that isn't today controlled by a government is one government action away from being controlled by that government; in practice, they won't even have to do that: they'll just use their authority to subvert the ostensibly- but- not- really independent operators.
I agree that governments control the DNS today.
The problem is that DNS does not in turn control Internet cryptography, and DNSSEC's primary use case is to change that.
I agree that governments control the DNS today.
The problem is that DNS does not in turn control Internet cryptography, and DNSSEC's primary use case is to change that.
> The problem is that DNS does not in turn control Internet cryptography,
That's a strange thing to say. DNS is pretty much the only thing that controls Internet cryptography. The number of non-domain validated certificates is vanishingly small.
That's a strange thing to say. DNS is pretty much the only thing that controls Internet cryptography. The number of non-domain validated certificates is vanishingly small.
If someone hijacks DNS to send Google.com requests to their own server, the browser will throw a TLS cert error, no? But if DNS and authentication are the same thing, then hijacked DNS would not throw an error anymore.
Do I understand this correctly?
Do I understand this correctly?
[deleted]
thats not the point OP was trying to make, the cert is issued via control of the domain, get control of the domain somehow, most any CA will happily issue you a cert for it.
Not all certs, though, right? I believe extended validation certs require more documentation than just domain control.
Go try to get a domain-validated cert for Google. They are in no way relying on DNSSEC.
I suppose that's easy bordering on trivial for an attacker of sufficient skill. At least it used to be. Is that no longer the case?
If there is a blacklist in place, absolutely each and every one of the hundreds of CAs need to adhere to it. One mistake or one exception and I could still get a misissued certificate just as easily as ten years ago.
Google can probably get it revoked very quickly, but we all know how well that works in practice. The only saving grace for the CA system is key pinning, and that's the only reason all those corrupt and/or incompentent CAs were exposed lately. But key pinning is not enough in itself. It is complementary to your certificate validation path(s).
If there is a blacklist in place, absolutely each and every one of the hundreds of CAs need to adhere to it. One mistake or one exception and I could still get a misissued certificate just as easily as ten years ago.
Google can probably get it revoked very quickly, but we all know how well that works in practice. The only saving grace for the CA system is key pinning, and that's the only reason all those corrupt and/or incompentent CAs were exposed lately. But key pinning is not enough in itself. It is complementary to your certificate validation path(s).
That's great, if you are Google. I unfortunately, am not Google.
You are not Google. How many people are potentially affected if the security of your domain were to be compromised?
> I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
I remain impressed that people who were at best ambivalent about the NSA and Snowden revelations, and other US Gov misdeeds, would use the fear of government control as their primary argument against DNSSEC.
Those folks are right about DNSSEC, of course. Their hemming and hawing about the NSA, Snowden, and the US government, I think history will judge harshly.
I remain impressed that people who were at best ambivalent about the NSA and Snowden revelations, and other US Gov misdeeds, would use the fear of government control as their primary argument against DNSSEC.
Those folks are right about DNSSEC, of course. Their hemming and hawing about the NSA, Snowden, and the US government, I think history will judge harshly.
I remain impressed that people who were up in arms about the Snowden revelations, or, just yesterday, about NSA stockpiling zero-days, could casually rationalize the largest transfer of control over the Internet to governments in the whole history of the net.
Is this me? I was, and am still, quite concerned about many of Snowden's revelations. I'm not as concerned about "passive" NSA vuln research as e.g. EFF are, although active sabotage of standards and deployed infrastructure has got to stop. I don't intend in this thread to rationalize anything, only to find out more about DNSSEC. For instance, why couldn't DNSSEC be used in addition to other methods such as TLS and DNSCrypt? I appreciate your insight in this area, but it's not clear that DDOS amplification (which, if it could be avoided by anyone, could be avoided by CF with their long experience in packet dropping) is enough of an issue to prevent even trying something like this.
Is this me? I was, and am still, quite concerned about many of Snowden's revelations. I'm not as concerned about "passive" NSA vuln research as e.g. EFF are, although active sabotage of standards and deployed infrastructure has got to stop. I don't intend in this thread to rationalize anything, only to find out more about DNSSEC. For instance, why couldn't DNSSEC be used in addition to other methods such as TLS and DNSCrypt? I appreciate your insight in this area, but it's not clear that DDOS amplification (which, if it could be avoided by anyone, could be avoided by CF with their long experience in packet dropping) is enough of an issue to prevent even trying something like this.
Exactly. And not to mention that we used elliptic curves (so the keys are shorter) and neutered ANY queries (so you can't aggregate records to generate a large DNS response). The net effect it using the CloudFlare DNSSEC implementation for DDoS gets you little to no amplification factor. And that's before the clever things we do around forcing TCP when we expect abuse, etc. Critcize us for many things, but for not thinking through how to mitigate the DDoS risk shouldn't be one of them.
Nobody is criticizing Cloudflare's DDOS protection mechanisms.
[deleted]
There's one legitimate complaint here ("governments control TLDs"), and one observation masquerading as a complaint ("CloudFlare want more business"), against a background of really sloppy thinking. Let's pick it apart:
* DNS TLD operator trust is replacing CA trust. This is specious off the bat since so many CAs rely on the DNS for verifying the origin of a request. Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it. In other words certificate trust is already, implicitly, DNS trust. Even HPKP+HSTS won't save you when the adversary is a state actor and controls DNS, controls a CA, and controls the network.
If you think most targets will cry foul and invoke the Internet Death Penalty upon detecting a violated CA, you're dreaming. Most targets don't even know what a certficate is.
I would be looking for an entirely different trust framework rather than muttering about two that are nearly congruent.
* Server-based validation is a problem. Why? Whether it's a locally running validating recursive resolver, or a validating library you link to your own software, or 8.8.8.8, in every case you're choosing to trust someone else's code and the mechanism by which you invoke it. The only absolute way to resolve this issue is audit/write the validation code yourself.
I.e., this isn't an emergent property of DNSSEC, it's just browser authors being lazy. (See also: lack of SRV record support in HTTP/2).
* DNSSEC doesn't help _me_ with _my_ security issues. Well, for that kind of universal claim we only need one counterexample to make it false. I'm happy to provide one: distribution and validation of my SSH host keys.
* DNS TLD operator trust is replacing CA trust. This is specious off the bat since so many CAs rely on the DNS for verifying the origin of a request. Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it. In other words certificate trust is already, implicitly, DNS trust. Even HPKP+HSTS won't save you when the adversary is a state actor and controls DNS, controls a CA, and controls the network.
If you think most targets will cry foul and invoke the Internet Death Penalty upon detecting a violated CA, you're dreaming. Most targets don't even know what a certficate is.
I would be looking for an entirely different trust framework rather than muttering about two that are nearly congruent.
* Server-based validation is a problem. Why? Whether it's a locally running validating recursive resolver, or a validating library you link to your own software, or 8.8.8.8, in every case you're choosing to trust someone else's code and the mechanism by which you invoke it. The only absolute way to resolve this issue is audit/write the validation code yourself.
I.e., this isn't an emergent property of DNSSEC, it's just browser authors being lazy. (See also: lack of SRV record support in HTTP/2).
* DNSSEC doesn't help _me_ with _my_ security issues. Well, for that kind of universal claim we only need one counterexample to make it false. I'm happy to provide one: distribution and validation of my SSH host keys.
> Fundamentally, if you control a domain you can get a CA-signed certificate for any label under it.
It's worse than that. All an attacker needs to do is passively monitor the target domain's emails, and he can get a valid CA-signed certificate. If the attacker can only monitor some networks, not all globally: no problem, since the attacker gets to choose which CA the email gets sent from!
It's worse than that. All an attacker needs to do is passively monitor the target domain's emails, and he can get a valid CA-signed certificate. If the attacker can only monitor some networks, not all globally: no problem, since the attacker gets to choose which CA the email gets sent from!
Targets don't have to cry foul. Broken pins can be reported automatically. People on the Chrome and Mozilla security teams can monitor them. It's not like this is an abstract point: it's already happened!
I'm not sure what you're trying to say about "state actors" and HPKP. No matter what happens: the NSA will control the DNS. We all stipulate that they control CAs. DNSSEC does nothing to change this (it actually ratifies it), but HPKP does.
I'm not sure what you're trying to say about "state actors" and HPKP. No matter what happens: the NSA will control the DNS. We all stipulate that they control CAs. DNSSEC does nothing to change this (it actually ratifies it), but HPKP does.
> DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates.
That is just an implementation detail is it not? My understanding is that there is nothing stopping a user (or more likely, the suppler of the user's OS) from setting up a local DNS server which verifies DNSSEC records.
> its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
Those governments can already get fraudulent certs issued to them either by directly coercing a CA located within their jurisdiction, exploiting a vulnerability in one of the hundreds of CAs worldwide, or by temporarily falsifying the records of the target domain to trick an unsuspecting CA. The difference with DNSSEC+DANE is that governments can only impersonate domains under TLDs that they control. No longer can Iran impersonate google.com by hacking a Belgium CA.
I'm not going to defend all of the implementation details of DNSSEC. Suffice to say, mistakes were made, but the concept is sound.
That is just an implementation detail is it not? My understanding is that there is nothing stopping a user (or more likely, the suppler of the user's OS) from setting up a local DNS server which verifies DNSSEC records.
> its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
Those governments can already get fraudulent certs issued to them either by directly coercing a CA located within their jurisdiction, exploiting a vulnerability in one of the hundreds of CAs worldwide, or by temporarily falsifying the records of the target domain to trick an unsuspecting CA. The difference with DNSSEC+DANE is that governments can only impersonate domains under TLDs that they control. No longer can Iran impersonate google.com by hacking a Belgium CA.
I'm not going to defend all of the implementation details of DNSSEC. Suffice to say, mistakes were made, but the concept is sound.
(a) Users are actively discouraged against setting up full resolvers on their desktops, (b) browser vendors (at least at Apple, Mozilla, and Google) had experimental support for DNSSEC that has now been withdrawn, (c) if we get to stipulate that end-users will install additional security software of our choosing, we can do way better than DNSSEC!
So no, I don't concede that this is simply an "implementation detail".
Governments can't simply subvert CAs anymore, because of key pinning. If they do that, there's a very good chance they'll get caught, and when they get caught their CA gets restrictions imposed by the browser vendors, or removed altogether.
There are no meaningful consequences for the hard-to-detect forgeries DNSSEC enables NSA/GCHQ to make. Google can't simply restrict .COM, or switch to another domain. Google Mail just has to live with the security/privacy policies of all the TLDs it operates on, forever, with no recourse.
That's a terribly unsound concept.
So no, I don't concede that this is simply an "implementation detail".
Governments can't simply subvert CAs anymore, because of key pinning. If they do that, there's a very good chance they'll get caught, and when they get caught their CA gets restrictions imposed by the browser vendors, or removed altogether.
There are no meaningful consequences for the hard-to-detect forgeries DNSSEC enables NSA/GCHQ to make. Google can't simply restrict .COM, or switch to another domain. Google Mail just has to live with the security/privacy policies of all the TLDs it operates on, forever, with no recourse.
That's a terribly unsound concept.
Hypotheticly, lets say an intelligence agency/whoever keeps hijacking domains and then getting CAs to issue certs for them.
The CA cannot automatically detect when a domain has been hijacked, it will issue the certs.
In this situation (with either the present DNS world, or dnscrypt), agencies are frankly 100% as unaccountable as they would be under DNSSEC world, because they still control the TLDs.
DNSCrypt does as little as DNSSEC to fix this issue. Pinning and certificate transparency can help detect under either scenario however.
Another concern in DNSCrypt is how does it handle the MITM problem between DNS servers? Trust on first sight is a lousy unscalable model (what if keys change, what if the badguys are already there before first contact) that is way more vulnerable than DNSSEC to forged replies.
The CA cannot automatically detect when a domain has been hijacked, it will issue the certs.
In this situation (with either the present DNS world, or dnscrypt), agencies are frankly 100% as unaccountable as they would be under DNSSEC world, because they still control the TLDs.
DNSCrypt does as little as DNSSEC to fix this issue. Pinning and certificate transparency can help detect under either scenario however.
Another concern in DNSCrypt is how does it handle the MITM problem between DNS servers? Trust on first sight is a lousy unscalable model (what if keys change, what if the badguys are already there before first contact) that is way more vulnerable than DNSSEC to forged replies.
While I don't agree with the particulars, I am not in fact a DNSCrypt advocate. I think the right next step for DNS security is "do nothing".
The problem of "asshole controls the TLD" is not solvable via ANY protocol. That dosen't mean DNSSEC is worthless, or handing over the keys of the internet to the government or miscellaneous hyperventilating.
You are falling into the classic trap of "this dosent solve every problem so we cannot permit it to solve any problem" that has held back security for decades.
DNSSEC is real, it is deployable and stuff is capable of supporting it, and it does solve very real issues. That counts.
You are falling into the classic trap of "this dosent solve every problem so we cannot permit it to solve any problem" that has held back security for decades.
DNSSEC is real, it is deployable and stuff is capable of supporting it, and it does solve very real issues. That counts.
Sorry, that's simply not true. Assholes control TLDs today, and they do not get to easily bypass Gmail TLS.
My point is, of course, that DNSSEC creates more serious problems than it solves. If you think my argument is "DNSSEC isn't perfect and we should wait for perfection", you haven't read what I'm saying carefully enough.
My point is, of course, that DNSSEC creates more serious problems than it solves. If you think my argument is "DNSSEC isn't perfect and we should wait for perfection", you haven't read what I'm saying carefully enough.
you can do exactly the same things to check DANE-validated connections as you can for tradition ca validated ones. So on that front its as least as good as the CA model. The real advantages of dnssec+dane are:
Your single registrar becomes your ca (who you already have to trust isnt hijacking your domain and issuing certs for it), not (potentially) every ca on earth.
You can validate dns responses to be at least as real as the root dns servers claim.
Nonpinned certs gain a lot better gaurentees against random CAs. (google cant pin every cert in chrome)
It does not solve the problem of "what if the dns roots are lying to you", but as ca world cert aquisition is tied to that very same issue, neither does normal TLS.
Your single registrar becomes your ca (who you already have to trust isnt hijacking your domain and issuing certs for it), not (potentially) every ca on earth.
You can validate dns responses to be at least as real as the root dns servers claim.
Nonpinned certs gain a lot better gaurentees against random CAs. (google cant pin every cert in chrome)
It does not solve the problem of "what if the dns roots are lying to you", but as ca world cert aquisition is tied to that very same issue, neither does normal TLS.
I'm lost in your argument. Help me understand: if I'm reliant on key pinning and cert transparency, which exists for TLS CAs but not for DNSSEC, what exactly is DNSSEC doing for me? Why is it interesting that I only depend on one untrustworthy (and irrevocable) CA?
because its impossible to pin everyone and everything everywhere.
No matter what you are stuck trusting that dns roots arn't being evil in the case of unpinned cert.
At least with DNSSEC you arnt stuck additionally trusting every CA on earth in the case an attacker can mitm, but dosent control said tld.
No matter what you are stuck trusting that dns roots arn't being evil in the case of unpinned cert.
At least with DNSSEC you arnt stuck additionally trusting every CA on earth in the case an attacker can mitm, but dosent control said tld.
The one CA on Earth DNSSEC asks most Internet users to trust is controlled by the f^cking NSA. How is this progress?
You might not want to carry that argument any further, since Verisign, which I presume you mean, is the single biggest CA today. They can sign anything.
They can not, however, subvert the root zone any more. Not since it was singed in 2010.
They can not, however, subvert the root zone any more. Not since it was singed in 2010.
because i would rather have to deal with the NSA, than everyone else + the NSA.
The level of tampering required for the NSA to fake DNSSEC replies is very evident if you have the cert pinned, and very hard to deny.
As things stand, its very easy to deny it was the NSA when anyone and their dog can have access to a CA cert.
The level of tampering required for the NSA to fake DNSSEC replies is very evident if you have the cert pinned, and very hard to deny.
As things stand, its very easy to deny it was the NSA when anyone and their dog can have access to a CA cert.
> Assholes control TLDs today, and they do not get to easily bypass Gmail TLS.
They absolutely do, which is why we have things like key pinning.
They absolutely do, which is why we have things like key pinning.
Things like key pinning are why control over TLDs doesn't equate to control over Gmail, which is my point.
How is that relevant to DNSSEC? Key pinning works indepedently of how you validate your certificates (against public CAs, against DANE, or a combination of both).
I'm lost. Why are we deploying DNSSEC again? I agree that HTTPS security comes down to things like key pinning, and not to giant PKIs.
Key pinning only works for players large enough to get pins in the client software itself. I can not do that, the best I have available is trust-on-first-use, which would carry a giant usability problem for the end user.
I can set up DNSSEC and DANE today, everyone who cares gets an alternative validation path to me, and the Internet is safer because of it.
I can set up DNSSEC and DANE today, everyone who cares gets an alternative validation path to me, and the Internet is safer because of it.
Key pinning is not a panacea either, it just makes browser/OS vendors another authority to be compromised and subverted.
While a healthy dose of cynicism is appropriate with-respect-to government control of TLDs, in the western world they are still at least nominally accountable to their constituents. Wholesale forgery is not likely to go over well with them, most importantly not with large tech companies. Targeted one-off forgeries would be easier to get away with, but they are also still perfectly doable today.
While a healthy dose of cynicism is appropriate with-respect-to government control of TLDs, in the western world they are still at least nominally accountable to their constituents. Wholesale forgery is not likely to go over well with them, most importantly not with large tech companies. Targeted one-off forgeries would be easier to get away with, but they are also still perfectly doable today.
That's a hand-waving argument. It basically says there's not much point in being concerned about communications security because someone who owns up your endpoint can bypass it anyways.
Thankfully, the article you linked links to its sources... which don't back up the claims it makes. From the link it uses to say that DNSSEC doesn't help end users against spoofing:
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)
"Although DNSSEC solves many of the security problems with DNS, it is not widely used because of the large cost of transitioning from DNS. However, where available, DNSSEC protects against the DNS attacks in Cafe Crack and should be used by Internet users."
Almost the exact OPPOSITE of the claim.
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
DNSSEC client support is much more widely deployed and activated on servers, but implementations exist for end-user OSes, and that hop of security is clearly the goal here. It's just that no consumer OS turns on support by default, because server-side deployment numbers are so low. And the packages that do exist are a royal PITA to install (in the OSX case) or configure (in the desktop Linux case). (Side note - still no DNSSEC for desktop Windows, according to my latest Google search.)
Of course DNSSEC also protects end clients, because by design the DNS protocol between end clients and servers, and between caching servers and authoritative ones, is the same.
There is a difference between the way TCP/IP works when sites like HowStuffWorks describe it, and the way it works in the real world.
In the real world, when you type a site name into your browser bar, your browser invokes a stub resolver to send a DNS query to a DNS recursive cache server, which is virtually never running on your local machine.
So, however it's supposed to work in theory, in practice there is DNS traffic running between your machine and some server somewhere on the Internet (perhaps very far away on the Internet if you use OpenDNS or Google DNS), and DNSSEC does not protect those queries. They're flying around the network in plaintext protected only by a 16 bit plaintext query ID and somewhat less than 16 bits of entropy in source ports, if you're lucky.
I'm pretty sure I can speak reliably for what that article I linked to claims.
There is a difference between the way TCP/IP works when sites like HowStuffWorks describe it, and the way it works in the real world.
In the real world, when you type a site name into your browser bar, your browser invokes a stub resolver to send a DNS query to a DNS recursive cache server, which is virtually never running on your local machine.
So, however it's supposed to work in theory, in practice there is DNS traffic running between your machine and some server somewhere on the Internet (perhaps very far away on the Internet if you use OpenDNS or Google DNS), and DNSSEC does not protect those queries. They're flying around the network in plaintext protected only by a 16 bit plaintext query ID and somewhat less than 16 bits of entropy in source ports, if you're lucky.
I'm pretty sure I can speak reliably for what that article I linked to claims.
On most desktop Linuces I've dealt with, the "stub resolver" is dnsmasq, which is quite full-featured and DNSSEC-capable... except that distributions don't enable the feature or distribute a trust anchor. But there aren't any deep structural problems preventing them from flipping the switch [1] - not like, say, the deep coupling between layer 3 and layer 4 that killed SCTP and other TCP/UDP alternatives in practice.
[1] For example, this configuration change is all that's required to enable DNSSEC on Gentoo, and would probably also work on Ubuntu and Fedora: https://wiki.gentoo.org/wiki/Dnsmasq#DNSSEC
[1] For example, this configuration change is all that's required to enable DNSSEC on Gentoo, and would probably also work on Ubuntu and Fedora: https://wiki.gentoo.org/wiki/Dnsmasq#DNSSEC
I'm happy to concede that the desktop Linux people don't have this issue. We should look into DNSSEC once Linux wins the desktop.
Linux is a test case. If you can get Linux to use DNSSEC without cooperation from intermediate routers and caches, then it's just single-organization engineering work - Apple and Microsoft would need to write DNSSEC-capable client implementations (which Microsoft already has for Windows Server) and deploy them. This is an OS feature like any other OS feature.
The obstacles to changing to IPv6, or to making any changes whatsoever to TCP, just aren't there.
The obstacles to changing to IPv6, or to making any changes whatsoever to TCP, just aren't there.
And so it took 21 years to get to this point with DNSSEC because...
Because it takes non-zero work, and doesn't add much value on top of SSL/TLS, which got wide deployment first.
As far as I understand, IPSec + DNSSEC gets similar security guarantees to SSL/TLS without identity certification, so once you have one there isn't any real economic incentive to put massive effort into developing the other.
As far as I understand, IPSec + DNSSEC gets similar security guarantees to SSL/TLS without identity certification, so once you have one there isn't any real economic incentive to put massive effort into developing the other.
Obligatory responses to tptacek's article:
- http://blog.easydns.org/2015/08/06/for-dnssec/
- http://www.circleid.com/posts/20150318_is_dnssec_worth_the_e...
Collectively thousands of words have been written on this topic within HN - and there are stark divisions between those who oppose DNSSEC and those who believe DNSSEC is a helpful and useful method of adding a layer of security to the Internet.
We don't agree. We won't agree.
Meanwhile, those of us who want to see DNSSEC more widely deployed applaud this move by CloudFlare because it both makes deployment simpler for many people and also advances the usage of stronger crypto (ECDSA) within DNSSEC.
This is great news!
- http://blog.easydns.org/2015/08/06/for-dnssec/
- http://www.circleid.com/posts/20150318_is_dnssec_worth_the_e...
Collectively thousands of words have been written on this topic within HN - and there are stark divisions between those who oppose DNSSEC and those who believe DNSSEC is a helpful and useful method of adding a layer of security to the Internet.
We don't agree. We won't agree.
Meanwhile, those of us who want to see DNSSEC more widely deployed applaud this move by CloudFlare because it both makes deployment simpler for many people and also advances the usage of stronger crypto (ECDSA) within DNSSEC.
This is great news!
Side reminder that it's not just HTTPS and its CAs system (of which world governments are already a subset, by the way): https://blog.filippo.io/the-sad-state-of-smtp-encryption/
SMTP email is simply. not. secure. If you need your messages to be protected from world governments, don't rely on SMTP for your security.
There's an argument that DNSSEC might make a marginal dent in protecting email from for-profit criminal enterprises. I don't believe it will, but let's stipulate that it does. It accomplishes that by setting up a new PKI whose roots are de jure controlled by the Five Eyes governments. How can that possibly be worth the gain?
There's an argument that DNSSEC might make a marginal dent in protecting email from for-profit criminal enterprises. I don't believe it will, but let's stipulate that it does. It accomplishes that by setting up a new PKI whose roots are de jure controlled by the Five Eyes governments. How can that possibly be worth the gain?
I don't know about you, but I'd be VERY happy about a world where the established mail protocol (wether we like it or not) is not passively eavesdroppable (STARTTLS being enough here) and where active attacks are hard, noisy and provable (enter DNSSEC+DANE).
How would exactly have Tunisia stripped STARTTLS [0] if mail servers did DNSSEC+DANE to get pinned TLS certificates?
[0] http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf
How would exactly have Tunisia stripped STARTTLS [0] if mail servers did DNSSEC+DANE to get pinned TLS certificates?
[0] http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf
I am not worried about attacks from Tunisia. I am worried about GCHQ.
DNSSEC deters marginal threats at the cost of encouraging serious threats. That's not a good tradeoff.
DNSSEC deters marginal threats at the cost of encouraging serious threats. That's not a good tradeoff.
> I am not worried about attacks from Tunisia.
Why not?
> I am worried about GCHQ.
I don't contest this part.
Why not?
> I am worried about GCHQ.
I don't contest this part.
At least with respect to web security, even people in Tunisia can avoid Tunisian intercept just by not using Tunisian services. But virtually no one can avoid .COM.
Oh. I was expecting something like, "I have secret knowledge that Tunisia's government employs less skilled attackers than the UK's."
[deleted]
To be honest, HSTS worked for HTTP pretty well, and it is not like mail servers are not commonly connected to either.
Hmm. Think they'll adopt DNSCrypt next?
DNSCrypt, which is far better and less costly than DNSSEC and does not cede to the US Government control over TLS keys, was proposed and deployed by a Cloudflare competitor. So, no.
Which competitor?
OpenDNS isn't a competitor in any way. They provide recursive DNS, not authoritative DNS. CloudFlare provides authoritative DNS, not recursive. Simplistically: Their customers are web surfers, ours are websites. We've partnered with them on multiple initiatives, supported their technical work, and I consider David Ulevitch, their founder and CEO, a personal friend.
We are basically friends with OpenDNS. Complementary products, not competitors. Now that they are owned by Cisco, there is some competition (on premise network hardware vs. what CloudFlare offers), but that wouldn't prevent us from using a good open source tool they develop.
As far as I'm aware, OpenDNS doesn't provide CDN-esque security services and is purely a DNS provider?
Oracle don't produce a browser but still compete with Google and Microsoft in other areas
Yeah, but unless its something like Incapsula that functions as a direct replacement ... its not really competitive with Cloudflare's value proposition.
You don't use Cloudflare as a DNS provider. Their value proposition [imho] is as a CDN/WAF.
I was genuinely hoping someone like Sucuri or Incapsula had picked it up.
You don't use Cloudflare as a DNS provider. Their value proposition [imho] is as a CDN/WAF.
I was genuinely hoping someone like Sucuri or Incapsula had picked it up.
Many many people use CloudFlare as their DNS provider.
We are among the fastest if not the fastest authoritative DNS provider in the world.
We are among the fastest if not the fastest authoritative DNS provider in the world.
[deleted](1)
> and does not cede to the US Government control over TLS keys
Hold on. This is actively conflating DNSSEC and DANE.
I know your point that the "main feature" of DNSSEC is enabling DANE, and I respect that. But the two domains are still distinct: DNS security and the PKI built on top of that.
DNSCrypt only addresses DNS security, so it should be compared to pure DNSSEC, which obviously does not "cede to the US Government control over TLS keys".
Hold on. This is actively conflating DNSSEC and DANE.
I know your point that the "main feature" of DNSSEC is enabling DANE, and I respect that. But the two domains are still distinct: DNS security and the PKI built on top of that.
DNSCrypt only addresses DNS security, so it should be compared to pure DNSSEC, which obviously does not "cede to the US Government control over TLS keys".
I don't agree with you. The top-down PKI DNSSEC expresses is inextricable from the DNS lookup security it attempts to provide. That DNSCrypt does a better job of solving lookup security without resorting to a government-controlled PKI is germane.
Filo: How do you feel about pushing for enabling DNSCrypt on your DNS servers, and working with the folks at Mozilla to make sure Firefox supports it? ;)
was proposed and deployed by a Cloudflare competitor. So, no.
Bad reasoning. You think we'll not deploy HTTP/2 because the head of the committee works for Akamai? Cmon.
DNSCrypt needs a secure resolver and client software. CloudFlare doesn't have either of those things which rather hampers us deploying DNSCrypt.
Bad reasoning. You think we'll not deploy HTTP/2 because the head of the committee works for Akamai? Cmon.
DNSCrypt needs a secure resolver and client software. CloudFlare doesn't have either of those things which rather hampers us deploying DNSCrypt.
> CloudFlare doesn't have either of those things which rather hampers us deploying DNSCrypt.
Behold:
* https://dnscrypt.org/
* https://github.com/bitbeans/SimpleDnsCrypt
I'm sure with Filo on your team you could make that happen.
Behold:
* https://dnscrypt.org/
* https://github.com/bitbeans/SimpleDnsCrypt
I'm sure with Filo on your team you could make that happen.
How are cloudflare going to distribute this proxy to end users?
I don't understand your question. I'm asking if they can consider supporting it and help browser vendors (i.e. Firefox) support the client side of DNSCrypt.
What does CloudFlare have to distribute?
What does CloudFlare have to distribute?
OpenDNS will happily send you queries over DNSCrypt. Thats like 3-4% of the internet right there.
They also open sourced client implementations for end boxes to talk to them or any other recursive securely.
jedisct1 is also looking for work right now, he'd happily implement it all for you I'm sure.
They also open sourced client implementations for end boxes to talk to them or any other recursive securely.
jedisct1 is also looking for work right now, he'd happily implement it all for you I'm sure.
AFAIK DNSCrypt (as the name suggests) encrypts transfer of DNS data between client & server whereas DNSSEC authenticates (to some level) the validity of DNS data, but does not encrypt it.
How do both compare ("far better")?
How do both compare ("far better")?
DNSCrypt is to secure your connection client-server and server-client.
DNSSEC is for server-server, to propagate existing addressbook.
DNSSEC is for server-server, to propagate existing addressbook.
That's not entirely true. DNSCrypt also aims for end-to-end security. The real difference is that DNSSEC is a top-down protocol that doesn't work until every link between your browser and the DNS roots agree, and DNSCrypt is a bottom-up protocol that provides value even if just a few people use it.
It's far from the only difference, but it worth calling out:
Only DNSCrypt protects your privacy!Problem with DNSCrypt is that it also does not solve meaningful problem. Governments can subvert DNSCrypt in exactly same way as they can subvert DNSSEC. Additionally, DNSCrypt offers no way to verify that the returned RRs realy come from authoritative server and weren't modified (by another DNS server) in transit.
One additional feature that DNSCrypt has over DNSSEC is that it encrypts queries and responses and thus has some privacy value, on the other hand there probably is nothing privacy-sensitive in DNS queries and responses that will not get leaked by IP addresses and SNI anyway.
One additional feature that DNSCrypt has over DNSSEC is that it encrypts queries and responses and thus has some privacy value, on the other hand there probably is nothing privacy-sensitive in DNS queries and responses that will not get leaked by IP addresses and SNI anyway.
No. DNSCrypt doesn't set out, on day one, to thwart NSA's ability to hijack DNS records. DNSCrypt's day-one job is to prevent coffee-shop attackers from MITMing your stub resolver, a job DNSSEC is actually incapable of doing.
DNSSEC solves no meaningful problems on day 1. DNSCrypt solves one meaningful problem on day 1. Long term, if DNSCrypt is deployed widely, it will grow to solve more of the NSA problem, as end-to-end chains of DNSCrypt-protected DNS links are deployed connecting clients to authority servers. But over the long term, DNSSEC's problems don't get any better at all.
DNSSEC solves no meaningful problems on day 1. DNSCrypt solves one meaningful problem on day 1. Long term, if DNSCrypt is deployed widely, it will grow to solve more of the NSA problem, as end-to-end chains of DNSCrypt-protected DNS links are deployed connecting clients to authority servers. But over the long term, DNSSEC's problems don't get any better at all.
"there probably is nothing privacy-sensitive in DNS queries"
Actually, there's a lot. You can learn a tremendous amount from just looking at the NS traffic.
Actually, there's a lot. You can learn a tremendous amount from just looking at the NS traffic.
I'm suggesting CloudFlare support DNSCrypt of their DNSSEC-signed responses to protect end user privacy.
Certainly looking at it.
Irrelevant. Cloudflare provides authoritative DNS services, not recursive.
We should rather encourage people to use a local, validating resolver.
We should rather encourage people to use a local, validating resolver.
Putting it another way:
"Why isn’t DNSSEC good enough?
DNSSEC attempts to guarantee that domain names are resolved to correct IP addresses. However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:
- Once DNS resolution is complete, DNSSEC does not ensure the confidentiality or integrity of communication between a client and the destination IP.
- No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.
HTTPS guarantees the confidentiality and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies."
> https://https.cio.gov/faq/
And:
"Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.
DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing."
> https://security.stackexchange.com/questions/11566/how-does-...
"Why isn’t DNSSEC good enough?
DNSSEC attempts to guarantee that domain names are resolved to correct IP addresses. However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:
- Once DNS resolution is complete, DNSSEC does not ensure the confidentiality or integrity of communication between a client and the destination IP.
- No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.
HTTPS guarantees the confidentiality and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies."
> https://https.cio.gov/faq/
And:
"Registrars can still theoretically abuse their position because they're responsible for communicating your intentions to the root servers. This includes information about your DNSSec keys. This relationship will never change; if you can't trust your registrar, then get a new registrar.
DNSSec doesn't prevent MITM attacks. It absolutely prevents DNS spoofing. But there are other ways of inserting yourself into a traffic flow than just DNS spoofing."
> https://security.stackexchange.com/questions/11566/how-does-...
^"No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability"
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
-- when DNSSEC validation fails, the domain is unreachable: www.dnssec-failed.org. The browser doesn't have to warn the user, the resolver will fail to return the DNS answer altogether.
With a non-validating stub resolver you'll have no idea if DNSSEC is being used at all, much less if DNSSEC fails and it falls back to plain DNS. And most OSes up to this point use non-validating stub resolvers.
From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.
I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!
If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
From a user's perspective, DNSSEC is merely the potential to be more secure; until they personally verify it is working for them, they have no idea if they are actually more secure or not. And you have to do this per device, per OS.
I just pulled up http://www.dnssec-failed.org/ on both my laptop and my Android phone, it loaded just fine. So DNSSEC failed to prevent either of these devices from loading an invalid domain. But I had no notification that DNSSEC failed; the page just worked!
If the browser actually informed me that DNSSEC isn't being enforced at all, I would at least know i'm not as secure as I could be.
On a [EDIT:] 2.5yo chromebook and on a moto e (total value, new, unsubsidized, of both devices: $250) that site doesn't load, with "ERR_NAME_NOT_RESOLVED". You can't hold dnssec responsible for your choice of broke-ass old-n-busted clients. What other security system would be held to that standard?
I'm using Android 5.0 and Windows 7. If those are broke-ass old-n-busted clients, screw modern technology.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.
Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.
So it only works reliably when it's broken. What a fantastic security system.
None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Assuming both the client and network were correct, you still have no idea if it worked or not! If you are a really smart user who thinks a site should be using DNSSEC and you try to go to that site, and your dns resolver supports DNSSEC properly, all you get back from trying a bad site is the domain wasn't resolved.
Is DNSSEC broken? Was the domain name wrong? Do I not have an IP on the network? Did something else happen? Who the fuck knows? Not the user, who gets back a generic error message if DNSSEC is working, and gets no error message if DNSSEC is not working.
So it only works reliably when it's broken. What a fantastic security system.
None of that happens with HTTPS, of course. With HTTPS the only thing that determines the security of the connection is whether the client validates its certs (and all browsers do). If it fails, you get an error and a big scary warning page.
Even if they were old-n-busted, your network must also use a DNS resolving server that supports DNSSEC. So even if your client has the right stub resolver, the network you connect to determines whether your client can make a secure connection or not.
Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
Good point! I didn't know that. Perhaps that's what you're running into, since Android 5.0 seems to be working fine for me? For a long time we all just used whatever DNS server we got from DHCP, but I think the time for that has passed. At this point we should choose our own recursive DNS provider, and reconsider using networks that don't allow that.
> At this point we should choose our own recursive DNS provider
Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.
But otherwise, sure, that works.
Assuming you control your device (non-corporate non-government users) and know how to configure your DNS server (elite users only) and wanted to do this extra step (privacy-conscious people?), this will break for hotels, airports, cafes/restaurants, corporate/government networks, anyone with an ISP that intercepts public DNS requests, and various home routers. Not to mention making surfing the web much slower and less reliable, since we distribute name servers specifically to rely on caching to lower latency and increase availability in case of various network failures.
But otherwise, sure, that works.
Assuming you control your device...
If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
If this isn't the case, then I know that the device operates not in my interest, but in that of whoever controls it. So, I probably won't be entering any sensitive information into it.
Like your work e-mail?
Email is rarely a good place for sensitive information. DNSSEC is not a panacea, but it does make Eve's job harder. https://insights.sei.cmu.edu/cert/2014/09/-probable-cache-po...
This is a bigger problem than I think people think it is.
DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates.
I have heard that both CeroWRT and OpenWRT support DNSSEC validation. There's also DNSSEC-trigger with Unbound for local DNSSEC validation. Maybe someone on here knows more, but I believe this directly addresses this issue. DNSSEC also is completely orthogonal to things like dprive which encrypt DNS queries. I'm not that familiar with DNSCurve but I believe it functions similar to dprive.
its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
I think you're referring to DANE, and DANE is not intended to replace the CA system, but instead augment it. See my article on this here: http://metafarce.com/adventures-in-dane/. DANE simply provides another means to verify the authenticty of a TLS cert, it doesn't replace the CA system, and having multiple methods for ensuring cert integrity is a net positive for the Internet.
The foundations of our CA system are not sound. Any compromised CA threatens sites secured by all CAs. In addition to specifying a hash of a site's TLS cert, DANE allows a site operator to lock down their trust anchor to the single CA they use.
I also don't get the signing Internet cryptographic trust over to the world governments thing. Please explain how you reach this conclusion. I've deployed DANE on a .com, and I never gave any private keys to anyone. I only needed to provide a hash of my TLS cert to my DNS provider. Granted my DNS provider could change the hash to something else, or redirect my site to somewhere else. Also, the TLD operator for .com could redirect my NS records to somewhere else as well, and then sign it with the TLD's ZSK. But they can already do that without DNSSEC, and I would notice this pretty quickly and attribute the attack to them.
the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast.
This is where I will agree with you. DNSSEC is tough and complicated to deploy. However, this does not mean it has no value. If companies like Cloudflare make it easier to deploy DNSSEC then that is a net win for Internet security.
DNSSEC isn't about helping you with your security issues.
I really like being able to trust what DNS servers tell me. That's an immediate benefit to me and my security.
I have heard that both CeroWRT and OpenWRT support DNSSEC validation. There's also DNSSEC-trigger with Unbound for local DNSSEC validation. Maybe someone on here knows more, but I believe this directly addresses this issue. DNSSEC also is completely orthogonal to things like dprive which encrypt DNS queries. I'm not that familiar with DNSCurve but I believe it functions similar to dprive.
its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
I think you're referring to DANE, and DANE is not intended to replace the CA system, but instead augment it. See my article on this here: http://metafarce.com/adventures-in-dane/. DANE simply provides another means to verify the authenticty of a TLS cert, it doesn't replace the CA system, and having multiple methods for ensuring cert integrity is a net positive for the Internet.
The foundations of our CA system are not sound. Any compromised CA threatens sites secured by all CAs. In addition to specifying a hash of a site's TLS cert, DANE allows a site operator to lock down their trust anchor to the single CA they use.
I also don't get the signing Internet cryptographic trust over to the world governments thing. Please explain how you reach this conclusion. I've deployed DANE on a .com, and I never gave any private keys to anyone. I only needed to provide a hash of my TLS cert to my DNS provider. Granted my DNS provider could change the hash to something else, or redirect my site to somewhere else. Also, the TLD operator for .com could redirect my NS records to somewhere else as well, and then sign it with the TLD's ZSK. But they can already do that without DNSSEC, and I would notice this pretty quickly and attribute the attack to them.
the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast.
This is where I will agree with you. DNSSEC is tough and complicated to deploy. However, this does not mean it has no value. If companies like Cloudflare make it easier to deploy DNSSEC then that is a net win for Internet security.
DNSSEC isn't about helping you with your security issues.
I really like being able to trust what DNS servers tell me. That's an immediate benefit to me and my security.
Sorry, but your security doesn't simply depend on your own keys. It also depends on all the keys that dominate your keys in the DNS graph.
"its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs."
Exactly! A rare time when we couldn't agree more. I've taken shit on various forums when saying something similar but it's quite obvious when you look at its structure and where the trust is.
EDIT to Add: I'm bookmarking your writeup on DNSSEC. Great summary of the issues. :)
Exactly! A rare time when we couldn't agree more. I've taken shit on various forums when saying something similar but it's quite obvious when you look at its structure and where the trust is.
EDIT to Add: I'm bookmarking your writeup on DNSSEC. Great summary of the issues. :)
I have been thinking about DNSSEC2 with online signing only for example, but it would not replace DNSCurve or DNS over TLS.
"DNSSEC isn't about helping you with your security issues."
My understatnding of history as I experienced it is that the resurgence of interest in DNSSEC was due to publicized cache poisoning of shared DNS caches circa 2008.
I run my own local cache on the loopback. I run my own root and other zones. I also use DNSCurve.
Recently there was another one of these DNSSEC advertisement posts from this same company about DNSSEC on the HN front page. (Surprise. How unusual.)
I asked a simple question: What benefit would DNSSEC offer someone like me?
While I did not get any straight answers, I did get blasted with walls of text from some guy working for a domain name registrar.
Perhaps it is not only companies selling consulting and DNS appliances, e.g., on government contracts, that are behind DNSSEC. Maybe it extends to the entire "DNS industry", e.g., people "selling" (renting) domainnames to users. For readers who are unaware, Cloudflare is in this "DNS industry". Their customers must hand over control of their DNS to Cloudflare. Cloudflare's entire approach to "security" depends on this.
DNSSEC is generally a PITA to set up and maintain. This makes it the perfect "service" to sell. If you like to generalize, you could argue this is true for any sufficiently complex networking component. The more complex the set up and management for users, the easier it is to sell them services.
I am an ordinary user who happens to enjoy setting up and managing my own DNS, making databases of IP addresses and even making my own domainnames, so I need a lot of convincing to be interested in something like DNSSEC, managed by third parties.
DNSSEC, as advertised, is a system that focuses on some mythical "validation" of DNS data.
Who decides what DNS data is "valid"?
Does DNSSEC require a "web of trust" model like the CA system?
If yes, why should we trust these third parties more than the endpoint we're trying to reach?
How much will users have to pay to be "validated" in such a system?
If some third party(s) controls what is and what is not "valid" DNS data can they more easily "disable" certain domains?
I could go on.
By contrast, a system for encrypting DNS packets is something I find more interesting and useful. I can set it up without too much effort and I control it. No need for third parties. Once more, it costs me nothing. There is no built-in idea of "web of trust" and I do not need to "purchase" a "valid" dommainname to begin using it.
But I am just a dumb user so what do I know? Go get your DNSSEC, right away.
My understatnding of history as I experienced it is that the resurgence of interest in DNSSEC was due to publicized cache poisoning of shared DNS caches circa 2008.
I run my own local cache on the loopback. I run my own root and other zones. I also use DNSCurve.
Recently there was another one of these DNSSEC advertisement posts from this same company about DNSSEC on the HN front page. (Surprise. How unusual.)
I asked a simple question: What benefit would DNSSEC offer someone like me?
While I did not get any straight answers, I did get blasted with walls of text from some guy working for a domain name registrar.
Perhaps it is not only companies selling consulting and DNS appliances, e.g., on government contracts, that are behind DNSSEC. Maybe it extends to the entire "DNS industry", e.g., people "selling" (renting) domainnames to users. For readers who are unaware, Cloudflare is in this "DNS industry". Their customers must hand over control of their DNS to Cloudflare. Cloudflare's entire approach to "security" depends on this.
DNSSEC is generally a PITA to set up and maintain. This makes it the perfect "service" to sell. If you like to generalize, you could argue this is true for any sufficiently complex networking component. The more complex the set up and management for users, the easier it is to sell them services.
I am an ordinary user who happens to enjoy setting up and managing my own DNS, making databases of IP addresses and even making my own domainnames, so I need a lot of convincing to be interested in something like DNSSEC, managed by third parties.
DNSSEC, as advertised, is a system that focuses on some mythical "validation" of DNS data.
Who decides what DNS data is "valid"?
Does DNSSEC require a "web of trust" model like the CA system?
If yes, why should we trust these third parties more than the endpoint we're trying to reach?
How much will users have to pay to be "validated" in such a system?
If some third party(s) controls what is and what is not "valid" DNS data can they more easily "disable" certain domains?
I could go on.
By contrast, a system for encrypting DNS packets is something I find more interesting and useful. I can set it up without too much effort and I control it. No need for third parties. Once more, it costs me nothing. There is no built-in idea of "web of trust" and I do not need to "purchase" a "valid" dommainname to begin using it.
But I am just a dumb user so what do I know? Go get your DNSSEC, right away.
To recap the ways DNSSEC sucks for users:
The only time that a user will ever know if DNSSEC is working (for them) is if the server/nameserver are configured correctly, your client's dns resolver supports DNSSEC, your client's stub resolver verifies requests, and then the user tries to look up a known-invalid domain and it gives them a resolving error. Otherwise, they will never know if DNSSEC is in use.
Oh, and you can still MITM the data connection between the client and server even if DNSSEC works.
* The server/nameserver must have DNSSEC configured properly
(CloudFlare have solved this for their customers)
* Your client's DNS resolving server must support DNSSEC properly
(which they might not, depends on the user's network)
* Your client's stub resolver must verify all DNSSEC records
(most do not currently)
The only time that a user will ever know if DNSSEC is working (for them) is if the server/nameserver are configured correctly, your client's dns resolver supports DNSSEC, your client's stub resolver verifies requests, and then the user tries to look up a known-invalid domain and it gives them a resolving error. Otherwise, they will never know if DNSSEC is in use.
Oh, and you can still MITM the data connection between the client and server even if DNSSEC works.
DNS is often the weakest link in the chain and well worth hardening if you're doing proactive sec. Combined with DNSCrypt it can be a pretty robust setup. My only problem with DNS hardening is zero-knowledge problems. See https://en.wikipedia.org/wiki/Zero-knowledge_proof It is possible to encrypt DNS queries, but tricky for end points to deny knowledge of having requested it, and so we have zero-knowledge proof issues.
This is great news for those of us who want to see DNSSEC more widely deployed for three reasons:
1. CloudFlare already hosts the DNS for millions of domains. This is now making it VERY easy for those who use CloudFlare to sign their domains with DNSSEC.
2. Because of the competition within the DNS hosting / operator space, this move by CloudFlare will hopefully motivate the other large DNS operators to simplify their own user experience for DNSSEC.
3. For those of us who want to see stronger crypto within DNSSEC, this move by CloudFlare advances the use of an elliptic curve algorithm. Yes, ECDSA has its issues, but by getting it out there: a) it gets people looking at EC algorithms; and b) it gets software providers realizing they need to have their user interfaces adaptable to incorporate more DNSSEC algorithms. (I.e. to realize the list is NOT fixed and will grow over time.)
As I said in another comment ( https://news.ycombinator.com/item?id=10553383 ) there is a draft out there to add Ed25519 as a DNSSEC algorithm:
https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01
This draft needs to be approved through the IETF working groups - and then deployed on both the signing and validation sides of DNSSEC. This will take quite some time and so we need to start as soon as we can.
1. CloudFlare already hosts the DNS for millions of domains. This is now making it VERY easy for those who use CloudFlare to sign their domains with DNSSEC.
2. Because of the competition within the DNS hosting / operator space, this move by CloudFlare will hopefully motivate the other large DNS operators to simplify their own user experience for DNSSEC.
3. For those of us who want to see stronger crypto within DNSSEC, this move by CloudFlare advances the use of an elliptic curve algorithm. Yes, ECDSA has its issues, but by getting it out there: a) it gets people looking at EC algorithms; and b) it gets software providers realizing they need to have their user interfaces adaptable to incorporate more DNSSEC algorithms. (I.e. to realize the list is NOT fixed and will grow over time.)
As I said in another comment ( https://news.ycombinator.com/item?id=10553383 ) there is a draft out there to add Ed25519 as a DNSSEC algorithm:
https://tools.ietf.org/html/draft-sury-dnskey-ed25519-01
This draft needs to be approved through the IETF working groups - and then deployed on both the signing and validation sides of DNSSEC. This will take quite some time and so we need to start as soon as we can.
Also of relevance:
https://www.mail-archive.com/[email protected]/msg00142.htm...
Comcast published TLSA records the other day. So when people like myself who have enabled TLSA in Postfix send email to Comcast users, the SMTP connection is guaranteed to be both encrypted, and the SSL cert validated.
https://www.mail-archive.com/[email protected]/msg00142.htm...
Comcast published TLSA records the other day. So when people like myself who have enabled TLSA in Postfix send email to Comcast users, the SMTP connection is guaranteed to be both encrypted, and the SSL cert validated.
I may or may not use Cloudflare's core service but would it still be a reasonable place to host my DNS entries?
I am not sure if Clouflare would advocate this use case, but quick DNS is actually a crucial part of a quick loading site, and it is surprisingly hard to get reasonably priced high performance DNS. I have been using Cloudflare just for DNS for my hobby site and it has been working great.
That's what I want to do: enabled dnssec in dnsmasq and run it on my router.
Yep, dnsmasq finally supporting DNSSEC is an excellent thing.
Alternative router firmwares such as Tomato Shibby support DNSSEC validation out of the box, thanks to this.
I wish more and more routers (most of them running dnsmasq) would also do this.
Alternative router firmwares such as Tomato Shibby support DNSSEC validation out of the box, thanks to this.
I wish more and more routers (most of them running dnsmasq) would also do this.
On recent Ubuntu releases, you can enable DNSSEC resolving by adding the following to "/etc/NetworkManager/dnsmasq.d/dnsmasq.conf":
dnssec
#dnssec-check-unsigned
conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
Why isn't is enabled by default?
A big step towards making the Internet more secure.
Kudos to Cloudflare for the amazing work they did.
No, it doesn't. DNSSEC secures server-to-server DNS lookups, not the client-to-server lookups that your browser generates. DNSSEC is far less valuable than its proponents would like you to believe, and it comes at a significant cost to Internet trust: its real use case, that of replacing the CAs with DNS TLD operators, has the net effect of signing Internet cryptographic trust over to the world governments that control the most important TLDs.
It's understandable that Cloudflare would jump on DNSSEC: the protocol is famously annoying to deploy and has caused major outages, including breaking the first day of HBO Now across all of Comcast. DNSSEC is an opportunity for a company like Cloudflare to make the case that they should manage your infrastructure, not you; the more features like DNSSEC Cloudflare can find, the more market share they'll acquire.
But make no mistake: DNSSEC isn't about helping you with your security issues.
Obligatory: http://sockpuppet.org/blog/2015/01/15/against-dnssec/