This is a post of the DNSSEC microsite containing a bunch of information (not sure who the poster is, it's not someone from CloudFlare) whereas that's a link the announcement blog.
If DNSSEC had been deployed a few years back, Muammar Gadaffi could conceivably controlled BIT.LY's TLS keys. Yesterday, today, and tomorrow, DNSSEC gives the NSA immense control over the TLS keys of sites in .COM, .ORG, .NET, .CO.UK, .IO, .COM.AU, and many more.
That's what it means to have a domain in Libya - you're subject to the jurisdiction of the officially recognized Libyan government. If you don't want to have to deal with the whims of a crazy dictator, don't register your business in his country.
and exactly what country is safe from the whims of politics? I was just reading about censorship in the Netherlands and other Euro states because of fear of offending religious people, especially muslims. If the far left Europeans can't protect speech, then who can? DNNSEC just enables centralized government control on a level that's not needed. DNS is fine as-is. Domain authentication should be done via the transport layer like SSL. That's the way things are going now anyway.
even in the case of existing CA model+key pinning (at least before the key is pinned) you are still trusting the governments controlling the TLDs are not going to fuck you.
Id rather trust a handful of cctld nation states, than the nation states + everybody with access to a CA cert.
Also the idea that dnssec tld keys cannot be rotated is pure FUD, the root key signing keys themseves cannot, but they were extremely careful there.
If tampering is detected, do you really think TLD keys are going to be left alone, and not regenerated and the process extremely closely scrutinized?
That's the trust that government always requires. Being on the internet doesn't change the fact that the point of government is a monopoly on authorized use of force. They can always just send men with guns to your office, DNSSEC or no.
If you don't trust your government not to abuse their power, that's not a problem that Cloudflare can help you with.
We're required to trust them for the DNS today. We aren't required to trust them for TLS keys. But DNSSEC/DANE formally and irrevocably gives them that authority.
I know a lot of people seem to think that, but that's just not right.
You can pin a certificate with X.509 CA TLS, and you can theoretically pin a certificate against DNSSEC/DANE (no browser does and it's unlikely they ever will; browsers flirted with DNSSEC a few years ago and that code has been withdrawn).
But when you pin an X.509 CA cert, you can also punish CAs that issue fraudulent CAs that break pins. This has already happened several times.
When you break a DNSSEC/DANE pin, you have no recourse. Everyone relies on the same .COM keys.
The whole concept of certificates in the first place relies on your ability to keep the private key secret. You know what you really have no recourse to? The police coming when you are asleep and "interrogating" you until you give them access to the key.
I feel like I'm trying to give you detailed technical answers, and that your responses are mostly about abstractions. I'm not thinking about DNSSEC abstractly. I am concerned with its specifics, which I have studied for a long time and am convinced will harm the Internet.
That's the nicest way I can say that your response to what I just said seems like a non sequitur. I just explained what I meant by recourse. I'm sorry, but I think you're wrong.
You can make your DNS server ignore root certificate and use anchors stored locally for specific TLD.
If then you contact a TLD that's owned by 3rd party you essentially trusting whoever owns that TLD. For example .google is owned by Google, so whatever is under it is under their full control.
One of the flaws about talking with an overloaded term like "security". If even abstractly, something does not work, what's the point of arguing about its technical details?
As you said before, DNSSEC is fine if you concede .com to the US government. This has already happened, we're just putting it in writing.
So you're excuse is that it's insecure but only to the government and you should be okay with systems insecure to the government? That's a sad state affairs if that's where the security community is.
It's not. The "security community" does not generally support DNSSEC. Most people in the security community don't think about DNSSEC, or DNS security, at all.
DNSSEC is being driven by three forces today:
1. The IETF, which has been working on it for 21+ years and has for the last 10 expressed continuing and increasing frustration that they can't just get the damn thing deployed.
2. The US Government, which is mandating its deployment in some circumstances.
3. CDN services like Cloudflare, who are interested in an Internet where standing up a server presence involves technology so complicated that almost nobody will DIY it. See: what happened with SMTP mail.
The only thing even theoretically secure to a government is another government, and reality almost always falls short of that. That has nothing to do with technology, just politics.
The nice thing about DNSSEC and the ccTLDs is that you can pick what country you trust. So you can get a domain in a country that is compatible with what you are trying to do.
Of course, with domain validated SSL certificates, you also have to trust DNS completely, because anyone who controls your domain can get a cert for that domain.
I hear this a lot too and it blows my mind. How is it a nice thing about DNSSEC that your choice of domain names will have a major impact on your security? That seems like a straightforwardly bad thing.
That's a good thing. Because the same applies to just about anything else. Where your servers are, who announces your IP space. Or outside the internet, where you are living, where your company is registered, where you do business.
The current CA system is the odd one out. Any CA in any country can create a cert for your domain that is recognized everywhere.
Still sounds like an improvement over the current PKI where any CA can sign any cert for any domain.
How many roots do you have in your browser's trust store? How many of them would roll over and mis-issue certs if presented with a secret warrant in their country of residence? (All of them.)
There are 3873497 CAs your browser has to trust today. DANE adds a 3873498th and a 3873499th, and the ones it adds are controlled by NSA.
The solution to the CA problem is to drastically reduce the power CAs have, which is what is happening with key pinning and certificate transparency and whatever follows that.
The solution to the CA problem can't possibly be "create a new super-CA controlled by governments".
How does having a new super-CA controlled by the NSA impede key pinning and certificate transparency?
I agree that CAs + DANE is just as shitty or shitter than CAs.
But:
a) In the event DANE replaced the CA system, one super-CA controlled by the NSA is better than 300 CAs essentially controlled by 50 different governments including the NSA.
b) Nobody's making you use DANE. Signed DNS records are an improvement over the status quo regardless of what you think of tying TLS to it.
The difference between DNSSEC's government-controlled super CA and a normal TLS CA is that when Google spots a normal TLS CA misbehaving because of an alert from a broken pin or CT log, it can shitcan the CA, either evicting it from the trust store or placing onerous restrictions on it. Both of these things have happened and will keep happening.
Google cannot do that to .COM or .IO. If the government-controlled super-CA that runs .COM misbehaves, we have no recourse.
DNSSEC essentially takes the worst feature of the HTTPS trust model and bakes it permanently into the core fabric of the Internet.
What do you think would happen under a DNSSEC-DANE TLS world if that started being detected via key pinning/CT ?
There is just no way the NSA is going to risk it except in very very specific circumstances they can easily control, (exactly the same situation as HPKP) because, they too will be forever burned just like an ssl CA would, except now they cant just switch to one of hundreds of other CAs, they have burned the root keys to a tld. This will be obvious, this will be screamed about from the rooftops, the key will be rotated + a ton greater scrutiny applied to the process.
Its not like browsers and other people pinning certs are just going to shrug their shoulders and say "aw shucks, i guess we wont worry about it"
the same way it can help in the case of the CA, parties like Google will set strict standards + see them compiled with or DANE etc will be ignored from the suspect TLDs.
What does it mean to "set strict standards" on .COM? Google can eliminate whole CAs, or scope them down to only a subset of names. It can't do that with .COM.
> it can shitcan the CA, either evicting it from the trust store or placing onerous restrictions on it
None of which prevents it from happening again with another one of the 300 CAs whenever another government gets antsy.
> If the government-controlled super-CA that runs .COM misbehaves, we have no recourse.
As a westerner I trust the super-CA that runs .COM 1000x more than some random CA in China or Iran or whatever. But even that's beside the point. If they abused their trust (which would be caught by CT) the whole system would collapse because, like you said, you can't shitcan .COM. Everyone would move to keypinning and/or a decentralized blockchain-based DNS solution and we would gain real security.
One thing I love about DNSSEC threads is that I get to join the anti-NSA faction on HN. Unlike you, I do not trust the giant corporation that controls .COM under charter from the US Government.
The USG has repeatedly abused its trust, often directly with respect to .COM. The Internet has not fled .COM.
The idea that we would deploy a forklift upgrade of a core protocol, at immense expense (look at Cloudflare's own marketing material!), ostensibly to improve security but in reality to put ourselves in the position of "fleeing .COM IF the US Government abuses it trust", boggles my mind.
The problem DNSSEC purports to solve is not cryptographically hard. DNSSEC made it hard because it was designed in 1995, at a time when designers felt it would be implausible for DNS servers to sign records.
We are talking about deploying this fiasco of a protocol with all its compromises purely because of the momentum of a 21+ year long standardization effort. Once we deploy it, any notion of solving the problem correctly dies. That's a terrible, terrible mistake.
Once we deploy it, any notion of solving the problem correctly dies.
This seems to be the nut of the disagreement. Why do you expect that to be the case? Will good people like Marlinspike decide to just hang it up and throw in the towel now that CloudFlare have rolled out another service? Will CloudFlare themselves decide this is the last new security measure that anyone would ever want?
So far I have seen no technical reason why DNSSEC inhibits development of possibly more worthy security techniques. Sociological arguments are less convincing.
DNSSEC will kill any meaningful future work in DNS security, but like I keep saying, I'm not anti-DNSSEC because I'm pro-DNSCurve; I just think DNS security is a stupid problem. Draw a layer diagram of TCP/IP up through HTTPS. Somewhere on that diagram you have to draw a line and say "below this line we're not going to attempt cryptographic security". That's not a new insight; it's basically the core argument of Saltzer-Reed-Clark, the foundational design paper for the Internet.
I tried to keep my issues with DNSSEC terse and clean here:
* It does create a new government-controlled PKI, which some people will depend on, to the detriment of safety and privacy.
* It's a cryptographically weak protocol designed by 90s-non-cryptographers.
* It breaks applications, as 'peterwwillis has been pointing out here for days.
* It's so expensive to deploy that Cloudflare is the biggest news to happen to it in 21 years.
* It doesn't protect browser lookups.
* It doesn't encrypt DNS requests and, in fact, actually forces sites to reveal more about their hosts than normal DNS does.
* Like I said up top, it's architecturally incoherent in a way that the End to End paper actually used as its motivating example all the way back in 1981.
I have spent a lot of time over the past 10 years arguing with people about DNSSEC. I'm not just making random stuff up in HN threads about this. You're probably not going to "gotcha" me on any of this.
Without the proposition "Once we deploy it, any notion of solving the problem correctly dies", which you seem to repudiate here, much of the sound and fury on HN in recent days would evaporate.
People doing dumb shit on the internet is typically not a problem for me, so while the end-to-end argument suffices to dismiss DNSSEC as worthy of investigation, I remain confused by all the attention drawn to this. If it's all a CloudFlare marketing stunt, has no one heard of the Streisand Effect? If it's all an NSA email-reading effort, why don't they just keep reading our email in the same fashion they already do? Confusing...
I vigorously disagree that the "sound and fury" on HN is about DNSSEC sucking all the oxygen out of the DNS security problem. It is on its face a PKI that gives control over .COM keys to the NSA.
The "Kaminsky Attack" from 2008 was an extension of a well known attack from the late 1990s (Kaminsky's innovation was to combine the two best-known attacks from the 90s: request ID prediction and authority record poisoning).
When he announced it, Kaminsky's attack impacted BIND (the de facto standard server) but not djbdns. That's because djbdns randomized ports and request IDs, making the attack difficult (not impossible, but not practical). Djbdns started out randomized that way.
Back in the 1990s, when request ID attacks were first being demonstrated, it was suggested on NANOG that BIND randomize ports as well. IIRC, Vixie even claimed to have performance numbers for a "scoreboarding resolver" that used randomization. But he objected to the deployment of that software, because the "right" solution was DNSSEC.
(I was on NANOG at the time because I had written exploit code for both sets of problems).
Fast forward a decade and Kaminsky has "broken the Internet", forcing BIND to finally fully randomize (a countermeasure that more or less killed his attack). The irony is: Kaminsky's attack was seized on as a reason to deploy DNSSEC!
The motivating use case for DNSSEC is DANE. DANE stores TLS certificates in DNSSEC-signed DNS records. But the top of the DNSSEC tree is --- de jure! --- controlled by governments.
1. Get a signed CA certificate for your domain at gun-point.
2. Send a forged DNSSEC record?
In which case, it's not significantly worse than the current state? And even though we can't burn a TLD, we can burn the CA that signed the certificate in the first place?
Or is there some magic in DANE that subverts CA verification?
I don't understand your question. If the government can't subvert CAs, DNSSEC is pointless; let's all just rely on the CAs. It can subvert them. Now, what problem is DNSSEC solving?
2. Evil NSA subverts DNSSEC for COM to publish a bad CA certificate
3. Some combination of Google Certificate Transparency + HPKP discovers this, the CA in BFE gets removed from browsers
If your point is "DNSSEC is pointless", OK. But it sounds like you're saying it makes us less secure. I'm just trying to figure out how that could even be.
I'm not sure why your question is being side-stepped, I also had the same wonder. It seems from reading though that the reason this is a problem is CAs are not involved at all in the DANE/TLS scenario. Instead, the X.509 cert. stored in DNS is trusted for TLS purposes simply because it is DNSSEC signed rather than CA issued. However, it seems at this time, no mainstream browser actually supports this natively (some have released plugins).
What I (and you) seem to have assumed was that this was DNS based certificate pinning, which to me would have made a lot of sense.
No. Seizing the domain does not help them if millions of browsers have the correct certificate pinned.
Meanwhile: we're all pretty unhappy that the USG does just seize domains. How can it possibly be reasonable for us to support a forklift upgrade of a core protocol that burns that capability permanently and cryptographically into the core of the Internet?
How is that worse? You already have US government in your CAs, for example Federal Common Policy CA. At least with DNSSEC only the organization that owns the TLD can issue certificates. With CA system in the browsers a country you might never heard of can issue certificate for google.com (which already happened).
Yes, the danger could be root certificate is managed by a single organization, but this can be easily solved in software of DNS server (for example ignore root and store certificate for every TLD, or implement policy to trust it only for certain TLDs). I would not be surprised if that's already implemented.
Now with ICAAN move (which I personally am not a big fan of) there are TLDs that are owned by private organizations, so it is possible to have entire chain without any government being involved in it.
But it is an essential part of it and those certificates are provided to you upstream.
Disabling them is discouraged, if you disable them you might start having issues (for example I disabled CA's on my Android phone) then noticed that many of my apps started crashing or had weird issues without providing meaningless messages.
If you disable them chances are that new version of the software will enable them back. You're essentially forced to live with them.
This is the fourth time in the last 30 days I have seen some blog post about DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one about email and DNSSEC written by a Cloudflare employee.
But still no discussion of cache poisoning.
So if a user runs their own personal cache bound to the loopback do they need DNSSEC?
What if they run their own root?
What if they have local copies of all the zones they need?
DNSSEC gives control to untrusted third parties to periodically determine what is and what is not a "valid" domain name.
What are the protections against abuse of this control?
I would not call DNSSEC "secure DNS". I would call it "validated DNS".
The question is who is doing the "validation"?
And why should we as users trust them more than the endpoint we're trying to reach?
> This is the fourth time in the last 30 days I have seen some blog post about DNSSEC on the front page. Three overtly pushing Cloudflare DNSSEC and one about email and DNSSEC written by a Cloudflare employee.
Absolutely, this is getting out of hand.
Would be easier to just buy HN and replace all top stories with your crappy DNSSEC ads..
It's great to see this microsite (and the announcement yesterday) as this rollout by CloudFlare will do two major things to help move DNSSEC forward:
1. Simplify the process of setting up DNSSEC-signing for so many people; and
2. Advance the usage of stronger crypto through the used of ECDSA (DNSSEC algorithm 13).
The first point will help with getting many more domains signed. The second point will help those of us who want to see even stronger crypto used within DNSSEC.
On that last note, I'd also note that there is an Internet Draft submitted about adding Ed25519 as a new DNSSEC crypto algorithm. You can find it here:
2. As recently as months ago, those keys were 1024-bit RSA.
3. If the zones above those Cloudflare manages are RSA, it doesn't matter if Cloudflare's own zones are ECDSA.
4. ECDSA is itself outmoded and dangerous.[1]. Cloudflare has the first significant deployment of curve-based DNS on the Internet, and because of standards group torpor, they're forced to use bad NIST-curve DSA, while the rest of the world has moved on to better curves and deterministic signatures.
5. It takes just a few hours to write a new draft for ED25519. Pretty much the entire browser vendor community agrees that TLS needs a standardized Curve25519; a draft for that was submitted over a year ago, and still hasn't made it out of committee because of bikeshedding. Worse: browsers can enable Curve25519 piecemeal, because TLS is a negotiation protocol. DNS isn't. Because DNSSEC advocates have pushed deployment of broken '90s crypto, it could take close to a decade to get Ed25519 deployable in DNSSEC.
The idea that better DNSSEC crypto is just a standards document away is a pretty good illustration of what has gone wrong with 21+ years of attempted DNSSEC standardization.
There's a better alternative than DNSSEC, and it isn't DNSCurve: it is literally "do nothing". Don't break the Internet. Don't create a massive new deployment of embarrassing old curve crypto. Don't effectively sign keys over to the NSA. Billions of dollars of commerce flow over the Internet every week and none of it, not one bit, is protected by DNS security. DNSSEC isn't useful, it isn't needed, it certainly isn't a priority. It's in this case a way for Cloudflare to make some extra money, and nothing more.
tptacek - the root keys will remain RSA-keyed for some time. The root Key Signing Key (KSK) is 2048-bit RSA. The root Zone Signing Keys (ZSKs) that are CHANGED every 3 months (a ZSK key ceremony is in fact happening TODAY) are 1024-bit RSA.
There was strong interest in changing the algorithm when the KSK is rolled (when that occurs is still to be decided), but for the moment an algorithm change will not be part of that.
I don't deny that deployment of ED25519 will take some time. Once approved it has to be integrated into the signing software. It's also got to be integrated into the validation side. It's going to take time. So lets get started!
How about, instead of getting started, we accept that DNSSEC is a failed 21-year-long experiment, and figure out a better way to get the moral equivalent of HSTS and HPKP for email links?
The concern I have with DNSSEC is that if it's adopted --- where "adopted" means "by the major email providers and by browsers" --- there's not much you can do to protect yourself from the SIGINT agencies that control the top of the DNS tree.
If there was a significant benefit to users for DNSSEC adoption, I'd be my normal tedious "maybe it's good, maybe it's bad" self. But the benefits aren't there. Instead, DNSSEC will impose immense operational costs and in some ways reduce security:
The essense of "MITM" isn't the Middle but the fact that the Man is unauthorized, Eve to Alice and Bob. If Alice and Bob agree to put CloudFlare (oh, look, the C already works!) in between them, there's a Middle but there's no [unauthorized] Man.
SSL's purpose isn't to create some sort of quasi-mythical "direct connection" between Alice and Bob, it's just removing the general Internet as a vector for many attacks. An utterly critical building block of the global Internet, but nothing more; certainly not a magic invocation that casts the spell of Security +1 across the entire communication, neither in fact nor in intent.
It's worth taking a moment to try to explore what the idea of "direct connection" is that you have in your head, in a world where Bob is probably already a program generating HTTP with no human interaction in an arbitrarily-complicated manner, with arbitrarily-complicated combinations of SSL accelerators, WAFs, and whoknows what other network appliances, even before we consider what it means to assemble a page from JS and images from 10 different domains representing other entities, and where Alice is using a browser and arbitrary plugins, each of which she is implicitly trusting, and possibly a proxy. If you examine this closely it becomes surprisingly complicated.
They allow "SSL termination" where traffic to/from Cloudflare's Edge is protected with TLS, as well as full TLS, where you also provide your own certificate and the entire chain is protected.e.
So, you can very easily opt out of the "MITM" if you buy your own certificate. You can use a self-signed one to get a little more safety within Cloudflare's network, or a CA-signed one for a lot more safety.
I think the parent is referring to CloudFlare not requiring SSL between CloudFlare and their customers.
An SSL-terminating load balancer is in plaintext between the LB and your servers, whereas CloudFlare Universal SSL can be plaintext over the internet.
Since the latter still shows users it's a secure connection, it would be reasonable for CF to require HTTPS between themselves and their customers. Last time I asked CF about this, their answer was "yes, but not our problem".
I mean, I feel like adoption is so low for DNSSEC already - does it even matter if it's 0% for DNSCurve or 1% adoption for DNSSEC? Why even bother with a 20 year old protocol?
DNSSEC and DNSCurve are completely different matters.
As far as I understand (I may be wrong!):
1. DNSCurve establishes an encrypted and, optionally, authenticated channel between you and upstream nameserver. It doesn't do anything about the data that is served over that channel.
2. DNSSEC protects the integrity of the data that is served by authoritative nameserver (and redistributed further) from some rogue adversaries (except for registries).
About DNSCurve - you should ask your upstream nameserver provider (usually, an ISP) to support it. Although everyone running a nameserver should do so. But it's purpose is completely different from DNSSEC is about - even though the latter's concept is flawed.
Let's not lose sight of the fact that DNSSEC purports to make client connections more secure.
Does it?
- If the server in question doesn't have DNSSEC set up: No.
- If there is a problem with one of the pieces of DNS infrastructure between the server and client: No.
- If the DNS resolver server the client is using doesn't support DNSSEC: No.
- If the client's stub resolver isn't a validating one: No.
- The user is never notified if DNSSEC is working for them or not. They can only determine this by making queries with a command-line tool, or when they get a 'could not resolve domain' error on an invalidly-configured domain.
---
Compare this to HTTPS, where the only thing the client needs to verify a secure connection is:
- The server delivering its certificate and certificate chain to the client
- The client validates the certificates
- If it isn't validated the user knows immediately.
You can go ahead and implement DNSSEC for your server, but when it comes to HTTPS connections, this does not improve user security over what we have now.
It's good to see CloudFlare continuing to embrace security as it evolves. I saw the AMA Matthew Prince did where he said he was concerned about ICANN giving control to the UN, which is a bigger deal than most admit, and he also said he was against regionalization of the net, another issue that doesn't get enough attention. Keep up the good work.
I know one thing I would like is Cloudflare doing something magical with Sub Resource Integrity.
Maybe if the source HTML specifies a SRI string, check that the hash in the HTML matches the hash of the resource before allowing it in your cache for that website. If it doesn't match, don't cache that resource and don't serve it.
This would allow sites to enable and enforce SRI without browser support.
Wow. Cloudflare is the perfect company to push DNSSEC forward. DNSSEC seems incredibly complicated and prone to amplification attacks, and I trust Cloudflare to get it right. :)
If you don't know for sure that that is a post by a cloudflare employee then I suggest you change the text or delete the comment.
When google rolls out a new feature there are 10's of submissions around the theme and surely not all of those are by google employees, why should cloudflare be any different?
Exactly. And why should it matter anyways who posted the article here on HN? The community here decides what is or is not worthy of discussion, not any single company.
