We discuss what the DANE technology for authenticating domain names via DNS entails and why it hasn't gained widespread adoption in browsers.
/ Unsplash /
What is DANE
Certificate authorities (CAs) are organizations that cryptographic credentials . They apply their electronic signature to these credentials, confirming their authenticity. However, situations can arise where certificates are issued with violations. For example, last year, Google initiated a 'Trust Termination Procedure' for Symantec certificates due to their compromise (we covered this story in detail on our blog — and ).
To avoid such situations, a few years ago, IETF the DANE technology (although it hasn't gained widespread adoption in browsers — we will discuss why later).
DANE (DNS-based Authentication of Named Entities) is a set of specifications that allows using DNSSEC (Domain Name System Security Extensions) to control the authenticity of SSL certificates. DNSSEC is an extension for the domain name system that minimizes attacks related to address spoofing. By utilizing these two technologies, a webmaster or client can contact one of the DNS zone operators and verify the validity of the used certificate.
Essentially, DANE acts as a self-signed certificate (with its reliability assured by DNSSEC) and complements the functions of CAs.
How it works
The DANE specification is described in . According to the document, a new type was added to the , called TLSA. It contains information about the transmitted certificate, the dimensions and type of the transmitted data, as well as the data itself. The webmaster creates a digital fingerprint of the certificate, signs it using DNSSEC, and places it in the TLSA.
The client connects to the website and compares its certificate with the 'copy' obtained from the DNS operator. If they match, the resource is considered trusted.
On the DANE wiki page, the following example of a DNS query to the example.org server on TCP port 443 is provided:
IN TLSA _443._tcp.example.orgThe response looks like this:
_443._tcp.example.com. IN TLSA (
3 0 0 30820307308201efa003020102020... )
DANE has several extensions that work with other DNS records besides TLSA. The first is the DNS record SSHFP for checking keys during SSH connections. It is described in , and . The second is the OPENPGPKEY record for exchanging keys using PGP (). Finally, the third is the SMIMEA record (the standard is not formalized in RFC, there is only ) for cryptographic key exchanges over S/MIME.
What is the problem with DANE
In mid-May, the DNS-OARC conference took place (this is a nonprofit organization that deals with security, stability, and development issues of the domain name system). At one of the panels, experts , that the DANE technology has failed in browsers (at least in its current implementation). Geoff Huston, a prominent researcher , one of the five regional internet registries, DANE as a 'dead technology.'
Popular browsers do not support certificate authentication using DANE. In the market, , which reveal the functionality of TLSA records, yet their support is .
The issues with the distribution of DANE in browsers are attributed to the long validation process via DNSSEC. The system is forced to perform cryptographic calculations to confirm the authenticity of the SSL certificate and must traverse the entire chain of DNS servers (from the root zone to the host domain) upon the first connection to the resource.
/ Unsplash /
This drawback was attempted to be addressed in Mozilla with the mechanism for TLS. It was supposed to reduce the number of DNS records that the client had to review during authentication. However, within the developer group, disagreements emerged that could not be resolved. Ultimately, the project was abandoned, even though it was approved by the IETF in March 2018.
Another reason for DANE's low popularity is the limited adoption of DNSSEC globally — Experts believe this is insufficient for the active promotion of DANE.
Most likely, the industry will evolve in a different direction. Instead of using DNS to verify SSL/TLS certificates, market players will promote DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) protocols. The latter was mentioned in one of our on Habr. They encrypt and verify user requests to the DNS server, preventing attackers from substituting data. At the beginning of the year, DoT already in Google for its Public DNS. As for DANE — whether the technology will be able to "get back in the saddle" and become widespread remains to be seen in the future.
What else do we have for further reading:
Source: habr.com
