SSL DNSSEC

by John Bayne (stephan@scandinode.com)

DNSSEC is a promising technology that will increase trust on the Internet.

DNSSEC stands for Domain Name System Security Extension and adds security to domain name lookups.  DNSSEC enables you to identify sites on the Internet so that you really know that you are communicating with the correct one.  The technology came into the spotlight during 2008 because of two events:

  1. Dan Kaminsky.1  You have some serious reading to do if you don't know who that is.

  2. The U.S. Federal government announced that they would sign the .gov top-level domain.  The Office of Management and Budget (OMB) issued a memorandum requiring agencies under .gov to sign their domains.2

TLS, that more popularly is being referred to as SSL, works by installing a digital certificate on the web server, allowing users to connect via secure HTTPS instead of HTTP.  We have all seen HTTPS in action and most readers probably have a general knowledge of how it works.

Some people think that DNSSEC will save the world and that everything will be safe after implementing DNSSEC.  Some think that it will prevent spam and guarantee that senders aren't forged.  Some even think that it will stop phishing attacks.  I think that DNSSEC is a nice addition that complements existing technologies.

For one particular problem, DNSSEC and SSL overlap.  Both DNSSEC and SSL are designed with integrity as a goal.  That is, how certain we are that the site we are visiting actually is the one it claims to be.  As both technologies solve the same problem, one can question if we need to use them both?

This article is a seven-round match up between the two technologies.  I will analyze which integrity mechanisms the technologies can provide, how they are implemented, and how they differ.

Just to be clear, both technologies provide additional security benefits that are not covered in this article.  The technologies will never be mutually exclusive.  For example, SSL can encrypt data to guarantee confidentiality.  DNSSEC allows for authenticated denial of existence (very useful?).

Round 1: Trust

How is trust implemented in each technology?

Both technologies provides endpoint authentication of the server you are communicating with.  The authentication stems from the fact that there is a chain of trust that you can follow to verify the identity.  Both technologies have higher authorities that vouch for an identity.  In SSL this higher authority is the issuer of the certificate.  Those higher authorities are listed in your browser.

In DNSSEC, you normally specify the higher authorities with trust-anchors in your resolving DNS.  It is very likely that DNS software will come preconfigured with trust anchors in the future, much like browsers come preconfigured with a list of certificate authorities to trust.

Security is never stronger than its weakest link.  We must therefore analyze the process of how the public key gets signed and how the certificate is obtained to be able to score this round.  In DNSSEC there is no certificate sent back to the requester, instead trust is established by special DNS records that are published and signed by the top-level domain.  The end result, however, is the same.

In SSL, the certificate issuer is supposed to check the identity of the requester before a certificate is issued.  In DNSSEC, the parent domain (typically the top-level domain) should check the identity of the child before the records are signed and published.  Not that much of a difference between the technologies there, either.

Recently, a security researcher, Eddy Nidd, managed to get an SSL certificate for a domain that he wasn't affiliated with.3  His little experiment exposed a weakness in the SSL certificate issuing process.  The issuer did not authenticate the requester correctly.  The experiment undermined the trust of SSL certificates in general.  As we no longer can trust that the certificate issuers are doing their jobs correctly, we can no longer trust SSL certificates in general.

DNSSEC will face the same control and regulation challenges as SSL certificates do.  Each top-level domain (such as .se, .org, .mil, .uk) needs to have an authentication process in place to make sure that only valid requests get signed and published.  So far, there is no central policy on how the authentication must be performed and there are no control mechanisms in place to control the top-level domains.  Some top-level domains (yes, you guessed it) use SSL to secure communication when users are being authenticated.

There are about the same number of certificate issuers in a browser as there are top-level domains, so implementing controls will face the same type of challenges in both technologies.  In fact, the challenges are even worse in DNSSEC as most top-level domains use third-party registration partners to do the actual authentication of the requester.  There are thousands of third-party registration partners that have to authenticate the requester in a secure way.

How do we make sure that every top-level domain and every registrar implements the controls correctly?  We can't, and therefore the trust in DNSSEC can be questioned.

SSL has some obvious flaws when it comes to authenticating the requester of the certificate.  There is no central body that oversees and audits the certificate authorities.  On the other hand, DNSSEC suffers from the same dilemma, and there is no way of knowing that the DNS community would do a better job.

This round is a draw; both technologies lack control mechanisms for how trust is implemented.

Round 2: Algorithms

How strong are the algorithms that are in use?

In the beginning of 2009, Alexander Sotirov found an issue with SSL allowing him to create a rogue Certification Authority (CA) certificate trusted by all common web browsers.4

This certificate allows us to impersonate any website on the Internet.  He took advantage of the weak MD5 security algorithm that is in widespread use in SSL certificates.  In fact, one certificate out of seven is using this old and deprecated MD5 security algorithm.5

The SSL community should have ditched MD5 a long time ago.  The Certificate Authority in question was RapidSSL, owned by Verisign.  Tim Callan of Verisign quickly wrote an article on Securityfocus claiming that "MD5 Hack Interesting, But Not Threatening".6

What he forgot to explain is that there might be one or more fake Certificate Authorities out there that can issue valid certificates for any server.  (If you ever feel that you would like to stop trusting a particular CA, you can do so by going to "Tools -> Options -> Advanced -> View certificates -> Delete" in Firefox)

The MD5 algorithm is deprecated in DNSSEC.  Therefore, DNSSEC is the winner in this round.

Round 3: End-to-End

Does the technology provide true end-to-end security?

SSL provides near end-to-end security, as the traffic is secured between the browser and the web server.  The only way to interfere with SSL would be at the end nodes.  SSL is implemented on top of the communication protocol it is securing.  It is therefore impossible to tamper with the communication, even if you have access to a computer or router in its path.

DNSSEC is not end-to-end.  It is typically only secure between the resolving DNS server and the authoritative DNS server and not all the way up to the client.  We need to wait for full DNSSEC support from the client operating system before we can have a true end-to-end security.  The next version of Windows will only ship with a "non-validating, security-aware stub resolver."  These types of resolvers are not true end-to-end.7  Instead, the resolving DNS server at the client side validates the records and notifies the client about the outcome.

The lack of end-to-end security makes DNSSEC vulnerable for attacks in the last hop between the resolving DNS server and the client.  An attacker could potentially tamper with the packets between the resolving DNS and the client to trick the client into thinking that the digital signature of the requested resource record is valid.  The RFC recommends that IPsec be used as a mechanism to prevent this.  That would, however, be hard to implement and maintain in a real world environment.  It is yet to be seen how DNSSEC will handle this.

DNSSEC only secures the DNS lookup, and not the communication.  To make an analogy, you are securing the phone book lookup but not the actual call.  Somebody with access to a computer in the path between the sender and receiver can potentially tamper with communication.

The true end-to-end capabilities of SSL makes it a winner in this round.

Round 4: User Warnings

How clear is the warning that the technology present to the user about invalid certificates/resource records?

SSL is often criticized for the visual warnings (or lack thereof) that are presented to the user.  The visual warning is determined by how it is implemented in the browser.  The warnings usually consist of a small padlock icon, or a green background in the address field.  Although the warnings have become better and clearer with the newer versions of browsers, they are still not up to the challenge.  Most users don't check to make sure that they are on a secure site when they are, for example, doing online banking.

DNSSEC faces the same issues with user warnings and has yet to prove if it is up to the challenge.  There is very little client-side support in operating systems and browsers for DNSSEC, and the few implementations that are out there don't look very different from what SSL is providing.8

Even with the identified problems with SSL, it still wins this round.  DNSSEC has a chance to catch up in this category if they implement a better warning system.

Round 5: Centralized Configuration

How easy is it to implement a centralized policy for the technology?

To be able to centrally configure a policy on what is allowed, instead of relying on users, is obviously a huge advantage on any network.  Most people argue that one of the biggest challenges for SSL is the fact that the user can override and continue to a site even if a certificate is invalid (for example, expired or issued to another host).  Perhaps less known is that this can be blocked at the network layer in a proxy or similar device.  Some proxy servers can be set up in such way that a centralized certificate policy is enforced.  For example, a proxy server can be set up in such way that it disallows users to continue if the certificate is invalid.

In DNSSEC, you have a resolving DNS server between the client and the site that you are communicating with.  The resolving DNS server is typically where you configure the trust anchors and where the validations of signatures occur.  The client will be prevented from continuing if the validation fails, as the associated bogus records will not be sent back.  However, this behavior can be circumvented by the client by setting the Checking Disabled (CD) bit in the query.9.  This will force the resolving DNS server to respond, even when the signature doesn't validate.  This behavior is a requirement in the RFC, so there is not that much we can do about it.  There is really no good way to implement a centralized configuration in DNSSEC.

SSL can be configured with a central policy, DNSSEC can't.  SSL wins this round.

Round 6: Adoption

How widespread is the technology?

SSL has been around for many years and is a technology that is much more widespread in use than DNSSEC.  There is extensive support for SSL in both browsers and servers.

DNSSEC has a shorter history and is not widely adopted.  The technology has suffered from the chicken and the egg dilemma.  As no zones were signed, it didn't make sense to implement DNSSEC on the client-side and, as clients never checked the signatures, it didn't make sense for domain owners to sign their domains.  Furthermore, just a few top-level domains support DNSSEC so, for the vast majority, it is next to impossible to implement DNSSEC even if they wanted to.  The egg is about to crack with initiatives such as the OMB mandate, but it will take several years before DNSSEC will be adopted in such scale that it will be usable for any real life scenarios.  Right now, DNSSEC can only add security in the rare cases when you know that both endpoints support the technology, such as for internal communication or communication with a partner.

SSL is the clear winner in this round; DNSSEC has a lot of catching up to do.

Round 7: Scope

How broadly will the technology protect you?

A security technology should have a broad scope, to be able to provide protection for many different servers and applications.

Although it is possible to purchase a wildcard SSL certificate that can be used on any server in your domain, it is more common to purchase individual certificates per server.  Usually only external facing web servers gets the privilege of having a real SSL certificate.  Each application needs to be secured individually and there is typically a secured counterpart to each insecure application (FTP vs. FTPS, HTTP vs. HTTPS, LDAP vs. LDAPS).  The scope of SSL is normally limited to one application on one server.

DNSSEC is implemented on a per zone basis.  Signing additional resource records can be done with little extra effort.  This makes DNSSEC a winner in this round.

Summary

Both DNSSEC and SSL aim at solving the integrity problem and both are doing a pretty good job.  Time has proven that SSL is a usable and reliable technology.  DNSSEC is a promising technology, but is much less mature.  SSL wins four rounds, DNSSEC wins two, and one is a draw.  DNSSEC has the possibility to catch up.  As DNSSEC gets implemented on a broader scale, we will see if the technology is up to the challenge.

Back to the Questions

Can I turn SSL off if I'm using DNSSEC?

No, even if encryption is solved by some other means, I would strongly advise against turning off SSL just because you implemented DNSSEC.  DNSSEC doesn't really protect communication, just DNS lookups, and DNSSEC is not truly end-to-end.  SSL is here to stay.

Do I really have to implement DNSSEC if I already have SSL?

If you are only looking to secure one server and one application and you already have SSL, there is not much to be gained by implementing DNSSEC.  SSL is designed to provide the required protection by itself.  But if you are looking at security from a broader perspective, you would probably want to add DNSSEC.  DNSSEC has a broad scope and it is easy to add security all your servers and applications with little extra effort.  Of course, the best thing is always to implement both technologies.

To sum it up: Both DNSSEC and SSL are needed.

References

  1. Dan Kaminsky, U.S. CERT advisory: www.us-cert.gov/cas/techalerts/TA08-190B.html

  2. OMB DNSSEC Mandate: www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf

  3. Eddy Nidd, SSL Certificate Hijack: blog.startcom.org/?p=145

  4. Alexander Sotirov, Rough CA: www.phreedom.org/research/rogue-ca

  5. Use of MD5 in SSL: news.netcraft.com/archives/2009/01/01/14_of_ssl_certificates_signed_using_vulnerable_md5_algorithm.html

  6. Tim Callan, Securityfocus: www.securityfocus.com/columnists/488

  7. DNSSEC in Windows 7: blogs.technet.com/sseshad/archive/2008/10/30/dnssec-in-windows-7.aspx

  8. Drill Extension to Firefox: www.nlnetlabs.nl/projects/drill/drill_extension.html

  9. RFC 4035, the CD bit, Section 3.2.2: www.rfc-archive.org/getrfc.php?rfc=4035
Return to $2600 Index