{"id":3569,"date":"2014-04-14T16:50:01","date_gmt":"2014-04-14T16:50:01","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=3569"},"modified":"2022-10-19T16:23:38","modified_gmt":"2022-10-19T23:23:38","slug":"dns-based-authentication-of-named-entities-dane","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/dns-based-authentication-of-named-entities-dane\/","title":{"rendered":"DNS-based Authentication of Named Entities (DANE)"},"content":{"rendered":"

Most people like you who are reading an\u00a0Infoblox<\/a>\u00a0blog are familiar with the benefits of using\u00a0DNSSEC<\/a>\u00a0to provide authentication and integrity for your DNS information.\u00a0 DNSSEC is a lot like dental floss: we all know that it is good for our health, but few enterprise organizations actually put forth the effort to implement the best practice.\u00a0 If organizations do not use DNSSEC then they are susceptible to a variety of DNS-based attacks.\u00a0 Attackers could falsify DNS responses or attempt a DNS cache poisoning attack.\u00a0 The good news is that now that the large Top Level Domains (TLDs) have been signed, more and more organizations are deploying DNSSEC.<\/p>\n

Most Infoblox blog readers are also familiar with how\u00a0Certificate Authorities<\/a>\u00a0(CAs) issue digital certificates that can be used to secure web communications using Transport-Layer Security (TLS) (formerly Secure Sockets Layer (SSL)). \u00a0If an organization does not use X.509 certificates issued by Certificate Authorities with TLS to protect their applications, then any of their TCP-based communications are subject to eavesdropping or hijacking.\u00a0 There could also be\u00a0errant self-signed SSL certificates<\/a>\u00a0lurking about along with mobile apps and other software that do not check for the validity of the certificate.\u00a0 The good news is that, due to the most recent revelations about government eavesdropping on communications, more organizations have a desire to use HTTPS instead of less-secure unencrypted HTTP web services.<\/p>\n

These two methods of DNSSEC and TLS provide two forms of validating the authenticity of a domain name or a web site. However, they use two different methods of validating the service.\u00a0 DNSSEC provides a method to digitally sign the DNS records and authenticate the entries via a chain of trust that starts with the root zone.\u00a0 CAs provide an independent third party verification that the named subject of the certificate is valid thus creating a Public Key Infrastructure (PKI) system.\u00a0 When a CA issues an X.509 certificate to a web service, the key is used to aid in the negotiation of a TLS session key to encrypt the web page contents.<\/p>\n

Problems with These Two Systems<\/h2>\n

The problem that has existed for many years is that these two methods of providing authenticity for a domain-name or a Fully-Qualified Domain-Name (FQDN) for a web site have not been tied together.\u00a0 The DNSSEC and the CA\/TLS chain of trust have been independent and are not linked together.<\/p>\n

The TLS certificate does not confirm that the organization running the web server officially owns that domain-name.\u00a0 Also, the DNS information for the FQDN does not have information about which CA is preferred by this organization.\u00a0 The security of the certificate is only as strong as the weakest of the 60-to-100 trusted CAs pre-loaded into the web browser.\u00a0 This has led to security issues related to either the DNS database information or CA issuer being\u00a0compromised.\u00a0 Examples of this include the March 11th<\/sup>\u00a0Comodo<\/a>\u00a0security\u00a0incident<\/a>\u00a0and the\u00a0DigiNotar<\/a>\u00a0SSL Certificate security breach in the summer of 2011. These incidents lead to the generation of false certificates.<\/p>\n

Therefore, relying solely on the security of DNSSEC or the security of a certificate is not the ideal practice.\u00a0 History has taught us that the most secure systems are those that use a combination of \u201cdiversity of defense\u201d and \u201cdefense in depth.\u201d<\/p>\n

DNS-based Authentication of Named Entities (DANE)<\/h2>\n

The idea behind\u00a0DANE<\/a>\u00a0is that it provides a way to cross-verify the domain-name information and the CA-issued certificate being used.\u00a0 DNSSEC provides authenticity of the named-entity (the domain-name and the FQDN of the web server) and has a digest of the CA\u2019s certificate that it prefers clients use to validate its CA-issued certificate.\u00a0 The client can then check that the CA vouches for the authenticity of the named-entity and that the FQDN within the certificate matches the web site the client wants to visit.\u00a0 This cross-linking of the authenticated information in DNS and the certificate provides an additional dimension of validation and thus security.<\/p>\n

This can be likened to the two-factor authentication systems that we are familiar with.\u00a0 Multi-factor authentication systems could use a token (something you have) and a pin (something you know) or a finger print, palm scan, or retinal scan (something you are).\u00a0 In the case of DANE, the two-factors are a DNSSEC authenticated authoritative DNS entry about the valid certificate and an actual certificate that can be validated by a trusted CA.<\/p>\n

The Internet Engineering Task Force (IETF) created a\u00a0DANE working group<\/a>\u00a0back in 2011.\u00a0 Since then, the group has created two critical RFCs that define the DANE method.<\/p>\n