DNSSEC drastically improves the security of the internet and systems that rely on it. Sadly, there is a lot of FUD out there and we wanted to both debunk that FUD and explain why DNSSEC is vital to the security of the internet.
DNSSEC makes DNS verifiable: it allows domain owners to sign their DNS records and client to verify their authenticity. Securing domains with DNSSEC and deploying validating resolvers on the client side would eliminate most DNS spoofing attacks and a wide range of MITM attacks.
However, DNSSEC would also allow DNS to serve as public key infrastructure for other protocols, such as HTTPS and TCP. DNSSEC will not interfere with key pinning (e.g. TACK) and triangulation (e.g. Convergence, Perspectives, WoT, etc.) schemes and these techniques can be applied to DNS to mitigate against attacks by ICANN, TLDs, and DNS service providers. DNSSEC will dramatically improve the security and privacy of the internet.
Unfortunately, the popular notion of DNSSEC is that it somehow degrades the security of the internet. But when followed to their logical conclusions, most arguments against DNSSEC misunderstand DNSSEC or are tirades about the governance structure of the traditional domain name system. This post debunks popular DNSSEC FUD, outlines the security benefits of DNSSEC, and explain why DNSSEC is vital to decentralized DNS.
- DNSSEC is a Government Controlled PKI
- DNSSEC Doesn’t Protect Against MITM Attacks
- There are Better Alternatives to DNSSEC
- DANE vs Certificate Authorities
- DNSSEC vs Key Pinning & Triangulation
- DNSSEC Bloats Record Sizes
- DNSSEC is Cryptographically Weak
- DNS Based Authentication is Architecturally Unsound
- DNSSEC is Unnecessary
- The Best Alternative is to Do Nothing
- DNSSEC is Complex
- DANE is Slow
- DNSSEC Leaks Information
DNSSEC is a Government Controlled PKI
Had DNSSEC been deployed 5 years ago, Muammar Gaddafi would have controlled BIT.LY’s TLS keys.
DNSSEC improves the security of both government controlled naming systems and alternatives such as .bit.
Gaddafi could have gotten a valid TLS certificate for Bit.ly without DNSSEC:
- Switch the nameservers to
ns.gaddafi.ly. - Publish a CNAME or TXT zone record to verify domain ownership.
- Switch the nameservers back.
If anything, DNSSEC would allow one to prove that the .ly TLD had published bogus DNS records.
The “government controlled PKI” criticism ignores the fact that traditional TLDs are a government controlled naming system. This is much worse than a government controlled PKI because Gaddafi could have just taken over Bit.ly directly.
The only way to escape governmental control is to use overlay networks, like Tor, and non-traditional TLDs, such as .bit and .p2p. But even if you choose a domain with a TLD that isn’t controlled by a government, you still need DNSSEC to securely delegate to a nameserver and to communicate application level cryptographic information.
DNSSEC Doesn’t Protect Against MITM Attacks
DNSSEC doesn’t secure browser DNS lookups. …a coffee-shop attacker would still be able to use DNS to man-in-the-middle browsers.
Computers are fast enough now that clients should perform validation locally.
While it was originally envisioned that DNSSEC validation would not occur locally, this antiquated deployment plan was created during the early 90’s when personal computers couldn’t handle the overhead. Now virtually everyone agrees that clients should perform validation locally. Doing so will defend against cache poisoning and MITM attacks.
There are Better Alternatives to DNSSEC
There are better DNS security proposals circulating already. They tend to start at the browser and work their way back to the roots. Support those proposals, and keep DNSSEC code off your servers.
There are no serious alternatives to DNSSEC.
There are no other proposals that offer what DNSSEC is designed for: a method for secure delegation of domains. This means that the root authority can declare the valid public keys for a domain and for the domain owner to declare the valid public keys for any subdomains. The three proposals most commonly cited as “alternatives” to DNSSEC (DNSCurve, key pinning, and triangulation) are almost entirely unrelated to this core functionality.
DNSCurve (the proposal the system is referring to) primarily provides lookup privacy by encrypting lookups between the client and a DNS resolver. This is not a bad idea but it does not offer any workable method for root authorities or domain owners to sign the records they publish. DNSCurve is also fully compatible with DNSSEC.
Key pinning simply means that a client relies on credential information provided by the first connection, just like SSH. Marlinspike’s Convergence uses triangulation to enable a client to check with other peers to ensure that the same cryptographic information is being presented to everyone and is a form of WoT. As explained in DNSSEC vs Key Pinning & Triangulation DNSSEC doesn’t interfere with HTTPS level implementation of these techniques and a local DNSSEC validating resolver could employ these techniques as well.
These proposals came to be seen as “alternatives” because their creators criticized the use of government controlled TLDs as a trust anchor when they introduced their proposals. However, as covered in the DNSSEC is a government controlled PKI section, signing of domains not only improves the security of sites using traditional TLDs, it’s also required by TLDs that are beyond governmental control, such as .bit and .p2p. Thus none of these proposals constitute a valid “alternative” to DNSSEC. As Kaminsky states in his rebuttal of DJB’s talk on CurveCP and DNSCurve,
… this is essentially a walk of Zooko’s Triangle, and does not represent an effective or credible solution to what we’ve learned is the hardest problem at the intersection of security and cryptography: Key Management. I conclude by pointing out that DNSSEC does indeed contain a coherent, viable approach to key management across organizational boundaries.
DANE vs Certificate Authorities
DANE is more secure than the traditional Certificate Authority system!
With DANE, you only have to trust ICANN, the country your TLD resides in, and your DNS service provider. This is far from ideal, but the traditional CA system requires trusting all of those entities and over 600 others.
Even domains which use .bit to bypass third-party-trust will need DNSSEC to securely delegate to a nameserver and communicate valid TLS certificates.
DNSSEC vs Key Pinning & Triangulation
Both Techniques can be Applied to DNSSEC
Key pinning simply means that a client relies on credential information provided by the first connection. Marlinspike’s Convergence enables a client to triangulate public key information by checking with peers to ensure that the same cryptographic information is being presented to everyone. Forms of key pinning and triangulation have been around since the inception of public key cryptography and can be found in SSH and GPG’s WoT.
DNSSEC does not interfere with their use at the application level (such as SSH and HTTPS) and a DNS-level implementation would extend those protections to protocols beyond HTTP. A DNS-level implementation would also help mitigate the common criticisms leveled against DNSSEC’s reliance on trusting ICANN, TLD operators, registrars, and DNS service providers. Public DNS resolvers (such as OpenDNS and Google) could detect and even mitigate attacks perpetrated by malicious or compromised TLD operators – such as temporarily altering MX records to intercept email for a short period of time. This would be in addition to the key pinning and triangulation protections that a local validating DNSSEC resolver would offer.
Key pinning is not without downsides and the HTTPS implementation severely limits the protection it offers. Since key pinning (and HSTS) can be used as a super cookie, the Tor Browser Bundle clears this information when it quits. Thus Tor clients are only protected on their first connection if the website is in Firefox’s preload list … but this list can be used to pinpoint Tor versions, so it is unclear how often it will be updated. A local validating DNS resolver capable of checking the TLS fingerprints in the DNS record would protect against malicious Tor exit nodes.
Another problem with key pinning is that it leaves little recourse if the master key is lost, say through a failure of a cold-storage system. Any business that has lost their key would have to cope with customers being presented with a scary warning screen. DANE/TLSA significantly reduces the need for key pinning because it allows the DNS record to specify a specific public key and reduces the number of trusted entities from 600 to 3.
DNSSEC Bloats Record Sizes
Using ECC, you can get records down to 512 bytes.
The industry is already migrating to ECC and CloudFlare has been able to reduce their average response size down to 512 bytes, small enough to fit into a single packet. CloudFlare’s initial experiments with ECC signatures found a single public validating resolver that didn’t support ECC-based signatures.
DNSSEC is Cryptographically Weak
The deployed system is littered with 1024-bit keys. … A modern PKI would almost certainly be based on modern elliptic curve signature schemes, techniques for which have coalesced only in the last few years.
1Kb keys are temporary and the industry is already migrating to 256-bit ECC.
1024 bit keys were chosen to reduce response sizes and are temporary. The current threat model assumes that it would take a nation-state a year to factor a 1Kb key and the .com, .net, and .org ZSKs are rotated every 3 months. And while we aren’t privy to the NSA’s budget, cracking a 1Kb key in under a year would probably cost tens of millions of dollars … far more than hacking into a website’s server directly or compromising one of 600+ Certificate Authorities (who can produce a valid certificate for ANY domain).
DNSSEC could use some improvements in terms of algorithmic agility (like support of Ed25519) but the industry is already migrating to ECC. Most DNSSEC deployments will offer the standard 128 bits of security.
DNS Based Authentication is Architecturally Unsound
A casual look at the last 20 years of security history backs this up: effective security is almost invariably application-level and receives no real support from the network itself.
Securing a lower level of the networking stack makes everything more secure.
Not building encryption into the lower levels of the networking stack was a mistake and improving the security of DNS improves the security of everything that relies on it. Take, for example, a service provider that offers a REST API and wants to ensure their clients only trust specific public keys. They would have to build a custom library for every language and reimplement basic functionality in languages that do not support specifying TLS keys natively.
DNSSEC also gives us a universal interface for communicating cryptographic information. The DNSSEC is Unnecessary section outlines how this can be leveraged to drastically improve the security of our online communications.
… security is about policy, and policy is about choices. DNSSEC tries to make a single set of choices for the entire Internet.
DNSSEC will allow a TLD to delegate ownership of a domain by publishing the nameserver and public keys of the domain owner. Any client that has the public keys of the TLD to can follow this chain of trust, and this a sane default security policy. However, the validation logic is explicitly left to the client system,
… authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set.
The client can use key pinning and triangulation (both at the application and DNS level) to mitigate against attacks perpetrated by the governmental root zone authority, the gTLD operator, or ICANN itself. As covered in the DNSSEC is a government controlled PKI section, DNSSEC only improves the security of a system that is already controlled by governmental authorities. And even non-governmental TLDs, like .bit, need DNSSEC to securely delegate to nameservers and communicate application level cryptographic information, such as an HTTPS certificate.
DNSSEC is Unnecessary
All secure crypto on the Internet assumes that the DNS lookup from names to IP addresses are insecure. Securing those DNS lookups therefore enables no meaningful security.
In reality, most online systems rely on the improbability and cost a network level MITM attacker.
Cryptographic information, such as the hash of a program or the public keys for a virtual machine, is usually sourced from services that rely on DNS. In practice, SSH security relies the improbability of a MITM attacker intercepting the connection to the server. Very few hosting providers will publish the public key and looking them up generally requires logging in over HTTPS.
Securing DNS will enhance the security of SSH, HTTPS, e-mail, and other protocols. Using .bit or .p2p, you can chain islands of cryptography to a trust anchor beyond the control of any government.
The burden of proof should be on anyone suggesting we change a core Internet protocol.
MITM attacks a real problem and DNSSEC is vital even to systems beyond governmental control.
Moxie Marlinspike and other researchers have proven that MITM attacks which simply downgrade to HTTP have a near 100% success rate. MITM attacks by exit nodes on Tor are common enough that Facebook and Blockchain.info have setup .onion URLS. A local DNSSEC validating resolvers would make most MITM attacks prohibitively expensive.
We might see a day when HTTPS key pinning and the preload list is implemented across all major browsers, but we will never see these protections applied in a uniform fashion across all major runtime environments (Node.js, Java, .NET, etc.) let alone in the thousands of other protocols and applications that don’t use HTTPS, such as SSH. Both HPKP and HSTS (HTTPS key pinning and strict transport security standards) can be used as a super cookie, so the Tor Browser Bundle clears them on exit. This means that Tor users are still vulnerable to a MITM on the first connection unless a site is in the preload list. The preload list itself can be used to pinpoint TBB versions and it’s unclear on how quickly it will be updated.
DNSSEC is also our only viable path for universal encryption of network communications. The Let’s Encrypt CA will cost hundreds of thousands of dollars per year to operate and will require site operators to sign up for and manually install their certificates on a yearly basis. DANE reuses existing infrastructure, so large service providers can roll out encryption to their customers without having to pay a certificate authority.
Beyond HTTPS, DNSSEC offers a universal interface for communicating cryptographic information to applications. A hosting provider could mitigate against a MITM attack on the first SSH connection. TCPCrypt would allow us to encrypt the connection at a lower level, ensuring every connection is protected by at least two layers of encryption!
DNSSEC is vital to decentralized DNS.
Namecoin’s .bit is a TLD that shares codebase and miners with Bitcoin and is beyond the control of any central authority. However, storing all DNS information in a blockchain will not scale – the blockchain should only store a valid nameserver and hashes of valid public keys.
And without DNSSEC acting as an interface for application level cryptographic information, supporting secure connections to a .bit domain requires adding support to every application. For example, adding browser support for HTTPS checking on .bitwebsites currently requires using undocumented API’s that differ between browsers or resorting to hacks involving SOCKS proxies and messing with TLS certificates.
The Best Alternative is to Do Nothing
… “Do nothing” is also a viable option; it’s what we’ve been doing for 20+ years.
A “do nothing” stance is reprehensible: it enables range of attacks against our civil liberties.
Doing nothing is not an option: an insecure domain name system undermines the security of the internet itself. While an imperfect standard, DNSSEC will put an end to a range of attacks and make others more costly.
A special ring of Robot Hell is reserved for anti-NSA features that admit to feasible but complicated or costly attacks.
Information security is about increasing the cost of an attack. DNSSEC makes many attacks infeasible for all but the most elite and well-resourced of attackers. Other proposals such as key pinning, triangulation, and encrypting lookups all admit to “feasible but complicated or costly attacks.” Even Namecoin, which powers .bit and is based on Bitcoin, cannot protect against a local machine that has been compromised. The combination of these various proposals will dramatically increase the cost of dragnet surveillance and opportunistic MITM attacks against the lay public and enable others to defend themselves from targeted attacks perpetrated by well-resourced of adversaries.
DNSSEC is Complex
DNSSEC is harder to deploy than TLS. TLS is hard to deploy (look how many guides sysadmins and devops teams write to relate their experience doing it). It’s not hard to find out what a competent devops person makes. Do the math.
Over 2/3 of TLDs are signed and major DNS service providers are getting into the act.
While we are sympathetic to technical challenges, any engineer worth their salt understands the folly of clean-slate solutions. DNSSEC has gone through three revisions and the outcome is pretty much the best possible standard given the specific requirements that were imposed by DNS and the process.
Building on what we have is an order-of-magnitude easier than pushing for a clean slate solution. We can improve tooling to make it easier and more foolproof to deploy, and we will.
DANE is Slow
… each extra lookup is more latency and another chance for packet loss to cause an expensive timeout and retransmit. – Adam Langley (a Google Chrome developer)
DANE will not incur additional latency in all but the most obscure of edge cases.
DNS isn’t a major source of latency because 80% of requests are cached and browsers engage in DNS prefetching. The DNS packet format allows submission of multiple requests in the same packet, so it can request the DNS and DANE record in the same request.
But even if we ignore caching and assume that the DNS resolver doesn’t supporting batching requests, local validation usually won’t realistically incur additional latency. A DNS resolver would dispatch the query for the DNS and DANE records at the same time. The only instance in which this would incur additional latency is if the lookup for the DNS record succeeded but DANE lookup failed. Normally, these requests would be sent to the same authoritative server and occur over backbone connections and it is unlikely one request would fail while the other succeeded.
DNSSEC Leaks Information
For everyone who accepts the default, every hostname in their DNS zones are public information.
There are methods for preventing zone enumeration even when using DNSSEC.
Zone enumeration basically means obtaining a list all of the subdomains for a domain. It is possible to prevent publishing all of your subdomains by only returning a record when a specific subdomain is requested. If an attacker or a spammer wanted to visit every subdomain, they would have to correctly guess each one.
The default configuration for DNSSEC makes it easier to guess these domains because when someone requests a non-existent domain, the DNS server must prove that the domain does not exist. The simplest way to do this is by giving the client an ordered list of subdomains that do exist. So if an attacker asks if b.example.com exists, the DNSSEC server would say that a.example.com and c.example.com exist and there are no domains between them.
But a DNSSEC server can also tell a white lie, such as claiming that a subdomain does exist, but they don’t have the specific record type that was requested. So, if you want to prevent trivial enumeration of subdomains accessible on the public internet, it’s possible when using DNSSEC.
This works for the kind of person who works on standardizing DNS extensions, because their hostnames are things like “dec-multia-in-my-basement.greybeard.com”. It does not work so well for Bank of America.
Bank of America shouldn’t rely on security through obscurity for access control.
Techniques to prevent trivial zone enumeration are, at best, a convenient method for reducing the volume of misbehaving web crawlers and passive attackers. The whole point of publishing a record to the public domain name system it to enable anyone to retrieve that record! With or without DNSSEC, trying to “hide” login.example.com is a waste of time because it would be among the first domains an attacker guesses. Any bank relying on these techniques for access control shouldn’t be in business.
This post was written by Indolering.
Also See:
- Why you must learn to love DNSSEC
- Set-and-Forget DNSSEC™ – set it up in 1-click.
Leave a Reply