DNSSEC: Don’t throw the baby out with the bath water
A recent report raiseed concerns about the abuse of DNSSEC to conduct DDoS attacks. The article reported that DNSSEC-signed domains can be used to conduct reflected DDoS attacks with large amplification factors (averaging 28.9x in their study) that could potentially cripple victim servers. The report went on to recommend that organizations deploying DNSSEC should configure their DNS servers to prevent this and other types of abuse.
While this report presents some useful information about the potential for misuse of DNSSEC, it has the side-effect of casting doubt on the overall value of the DNSSEC protocol itself. It would be a shame if someone reading this report concludes that DNSSEC creates more problems than it solves. In fact, DNSSEC is an essential protocol that continues to add critically needed trust to internet communications.
Most IT and security professionals know that DNS is the protocol that maps domain names to IP addresses that computer systems require to communicate. But the DNS is much more than this – it is a globally distributed ‘database’ that can be used to store a wide variety of information and retrieve it from any computing system anywhere in the world. Its architecture has been proven over decades of use to scale effectively to the size of the internet.
DNSSEC adds a missing ingredient to this globally distributed, highly scalable database – trust. Trust means two things – first, knowing that data received from a domain came from the owner of the domain; and second, knowing that the data has not been altered while in transit. It is important to note that DNSSEC does not provide confidentiality to the DNS – it makes the DNS a trustworthy place to publish and retrieve public information, but it does not make it a place to publish confidential or sensitive information.
Up to this point, most implementations of DNSSEC focused on ensuring the trustworthiness of only one piece of information – the IP addresses of servers associated with a domain name. While this is an important piece of information to protect, because it eliminates the risk that an attacker can hijack an organization’s web or email servers, it is only the first of many pieces of information that can be published in a trustworthy fashion in the DNS. In this article, I would like to focus on two pieces of information that have the potential to significantly increase the security of internet communications – email certificates, and web (TLS) certificates.
Theoretically, anyone can send an encrypted email to anyone else today. The only thing needed is to have the email certificate of the recipient. Once this information has been saved, most email clients will happily encrypt a message so that it can be read only by its intended recipient. In practice, this process has proven to be difficult – how does each recipient get a certificate? How do they send the certificates to anyone that might want to send them an encrypted email? These are the two critical challenges that have prevented widespread adoption of email encryption.
DANE (DNS-Based Authentication of Named Entities) SMIMEA records are a recent addition to the DNS that defines how email certificates can be published in in the DNS and secured with DNSSEC. Organizations that wish to enable encrypted email can publish an email certificate for some or all of their employees in their DNS, and these certificates can be retrieved by DANE-enabled email clients to automatically encrypt sensitive communications. The use of DNSSEC in conjunction with this new protocol is critical, as it prevents attackers from hijacking these certificates in order to snoop on sensitive emails. By making it easy to publish and retrieve email certificates, DANE removes one of the two barriers to widespread adoption of end-to-end email encryption. The second barrier – generation of email certificates and management of them throughout their lifecycle – can be addressed by commercial products, as this problem does not require any new internet standards in order to be tackled effectively.
Web servers also utilize certificates (in this case, TLS certificates) to encrypt web communications. These certificates are issued by Certificate Authorities (CA) that certify that the owner of a domain is the owner of the certificate. There are two main problems with this trust model, however. First, if you trust one CA, you must trust them all. Any CA can issue a certificate for any domain, and there are now dozens or even hundreds of CAs that are directly or indirectly trusted by today’s web browsers. Second, if you trust a CA to issue one type of certificate, you must trust them to issue any type of certificate. As a result of the CA trust model, a breach of a CA can result in the issuance of forged TLS certificates for ANY domain, and this, in turn, can allow web sites to be hijacked without detection. Such a breach actually occurred in 2011, when a Dutch CA was compromised and fraudulent certificates issued and again in 2013 as a result of the compromise of a Turkish CA.
DANE is also used to increase the trust in TLS certificates by allowing a domain owner to indicate to a web browser which CA is authorized to issue certificates on its behalf, which certificate the browser should expect, or whether the domain owner is self-publishing its own certificates. The net effect is a significant reduction in the risk of compromise of these critical certificates.
DNSSEC is a valuable security protocol, not just because it authenticates IP addresses to prevent domain hijacking, but also because it can be used to authenticate a wide variety of information that is controlled by a domain owner. We have seen how the recently published DANE standard enables increased trust in both email and web communications. Future standards may expand the set of information that can be published in the DNS and secured with DNSSEC. DNSSEC is simply too important to the future of internet communications to ignore or dismiss.