Whither DANE?

At the recent DNS-OARC workshop, I gave a short talk on current prospects for DANE adoption. This generated a fair amount of subsequent discusion and commentary, including a blog article by Geoff Huston, so I thought I’d elaborate in this post.

Some background first ...

DNSSEC (DNS Security Extensions) is a system to verify the authenticity of data in the Domain Name System (DNS). One of the more exciting prospects for DNSSEC has always been the possibility that it might be used by applications for core security functions.

DANE, which stands for ‘DNS-based Authentication of Named Entities’, is one framework for doing this, that uses signed DNS records to securely associate domain names with cryptographic keying material such as public keys and X.509 certificates (or hashes of them).

In theory, at least, DANE could provide an alternative to the existing Internet PKI (Public Key Infrastructure) system that has had a long history of security problems. Many of these problems are quite fundamental to the design of this system.

Applications need to be configured to absolutely trust a very large number of public Certification Authorities (CAs). These CAs have no constraints on the namespace for which they can issue certificates. Any of them can issue a certificate for any of our services, whether we have a business relationship with them or not. So the collective security of the system is equivalent to the CAs with the laxest policies and worst security. It gets worse – many of these CAs, in turn, issue subordinate CA certificates to other organizations (mostly) without any name constraints. An excellent paper from 2013, “Analysis of the HTTPS Certificate Ecosystem”, describes the extent of the problem.

Additionally, there are functional deficiencies. Today’s Public CAs are only capable of issuing certificates with the most basic capabilities. If you need to deploy a certificate with some more advanced features – such as a URI or Service Name field to better compartmentalize the security of an application – you are basically out of luck.

Great effort has been expended on designing and deploying bandaids such as the Certificate Transparency system, where Public CAs are now required to log all certificates they issue into verifiable logs operated by yet another set of additional trusted parties – so that mis-issuance of fraudulent certificates can be detected after the fact. But it would be far better to have a more proactive system that can prevent these kinds of mis-issuances in the first place.

Application services on the Internet are identified by their DNS names. If the DNS is secured by DNSSEC, then it’s very natural to consider using that same system to authenticate these applications, and DANE provides exactly this capability. DNSSEC is truly hierarchical with a single trusted root, operated with a high degree of security and transparency. In contrast, the Web PKI is flat and has far too many roots with unlimited authority that are operated by entities with highly variable track records of security – this exposes a much larger attack surface that is very challenging to defend. Delegation and trust in DANE already follow the existing DNS delegation hierarchy, and critically, it automatically inherit namespace constraints – zone owners can designate certificates only for their own portion of the DNS namespace.

The vast majority of certificates issued these days are ‘domain validated’ anyway, so the WebPKI ultimately relies on the security of the DNS infrastructure.

(Note: For folks that distrust a hierarchical system, the solution is not a reversion to the WebPKI, but to move to fully decentralized trust architectures. Such systems do exist today in various forms, and I sometimes advocate for them myself, but they are not currently in a state where they are ready for mass adoption and mass usability.)

Back to the subject of my talk ...

Whenever I attend DNS focussed conferences or meetings, I often hear discussions of DANE, and there is usually an air of inevitability about them: DANE will comprehensively solve such and such set of problems, and it’s only a matter of time before it is adopted and deployed. Having been involved in some lengthy struggles to standardize the use of DANE in applications, I knew this was not the case. So, at OARC-30, I delivered a short lightning talk on the topic to highlight the adoption challenges.

The one area where DANE has had some deployment success to date is in SMTP Transport Security, where it provides a downgrade-resistant way to perform TLS authentication of an SMTP server. Viktor Dukhovni publishes a monthly report on DANE uptake in this arena, and the numbers are quite impressive. There are over one million domains with mail servers that can be authenticated with DANE, and <a href=http://stats.dnssec-tools.org/#graphs”>adoption is growing over time</a>. Many of these domains are hosted on large shared email hosting providers – so the actual number of zones hosting mail servers that publish DANE records is far smaller though (around 4,500).

The killer application that could have a major positive impact on DNSSEC and DANE adoption, of course is the Web. This was always going to be a challenging proposition since it involves introducing a competitor to the Web PKI, a highly dominant authentication system with many entrenched interests.

DANE and the Web

Nevertheless, there have actually been a number of attempts to design DANE solutions for the Web. An early attempt by Google in the Chrome browser, which was ultimately abandoned, involved publishing certificate data in the DNS and DNSSEC record chains inside X.509 certificates. Building on this work, I was involved, with collaborators from both the DNS and web communities, in a newer, more complete effort within the Internet Engineering Task Force (IETF) – the organization that standardizes Internet protocols. This was to develop the ‘TLS DNSSEC Chain Extension’ – an extension to the Transport Layer Security (TLS) protocol that allows a web server to deliver its DANE record(s) and associated DNSSEC authentication chain inside the TLS handshake, which the web browser then authenticates.

You might be curious why such a mechanism is needed instead of the web browser just querying the DANE and DNSSEC records itself? There are a number of reasons. The first is that that browsers (and endstations generally) sometimes find themselves behind “middleboxes” that impede their ability to lookup DANE and DNSSEC records. Another reason is latency reduction. DANE authentication involves additional queries, and having the TLS server deliver all the (pre-built and cached) chain of DNS answers in one shot eliminates any additional latency. And lastly, delivering the DNSSEC chain via the TLS channel and having the browser directly authenticate it, means that there is no requirement for the endsystem to run a validating stub resolver (which isn’t common) or to have a channel protected connection to an external validating resolver (also not very common).

In the early days of this effort, Mozilla had even funded an implementation of the TLS DNSSEC chain extension in the Firefox browser. The extension was on the verge of being approved as an IETF standards track specification in March 2018, when a huge technical fight broke out in the working group. A few DANE proponents argued that this extension did not provide downgrade resistance against Web-PKI attacks (that is, an attacker that is able to fraudulently obtain a valid Web-PKI certificate can strip away the extension and preclude DANE authentication). Ironically, I had long ago described this limitation in the protocol along with possible workarounds (Section 8 of the spec), but it was only after the DANE proponents were made aware of this that it suddenly became a show-stopping technical issue.

A pinning mechanism was proposed, whereby web clients would remember whether a server had offered DANE authentication, and then subsequently require it from that server, unless the server could provide proof that they had removed DANE. Note also, that this is a Trust On First Use (TOFU) mechanism that is vulnerable to attack on initial contact. But the Web browser folks were unanimously opposed to this pinning mechanism. A protracted argument ensued in the TLS working group, with opposing sides unwilling to compromise and ultimately a decision to abandon the work. The unfortunate result is that DANE, as an authentication option, is effectively dead for the Web for the foreseeable future.

DNSSEC proponents will naturally desire a DANE authentication mechanism that always trumps the Web-PKI (and provides downgrade resistance against Web-PKI attacks). But we need to consider the objections of the other side seriously.

What were the objections

First, many Web folks do not agree with the premise that DANE needs downgrade protection against the Web-PKI, because they do not see DANE authentication as inherently superior to the Web-PKI. You will often hear the argument that the Web-PKI has moved to 2048-bit RSA keys as a security floor, whereas today’s DNSSEC deployment is still littered with weak 1024-bit RSA keys. This is a real problem. The DNSSEC authentication chain is only as strong as its weakest link.

Of the nearly 1,400 DNS top-level domains that are signed at the current time, 65% of them use 1024-bit or smaller RSA Zone Signing Key, and only 9% have a 2048-bit or greater RSA key (ECDSA keys are still in the extreme minority in this landscape). 1024-bit RSA keys are believed to be in the realm of attack by nation-state actors and/or very large corporations, and the fact that 1024-bit RSA remains in widespread use by DNSSEC is frequently criticized, and rightly so. Anyone trying to position DANE as a superior alternative to the Web-PKI will need to figure out a solution to this problem. (Can we get ICANN to mandate the elimination of weak keys in the generic TLD infrastructure, for example?)

Second, even if the web community agreed with the premise, they have strong objections to pinning, based on their negative experiences with other pinning mechanisms that they have attempted, such as HTTP Public Key Pinning (HPKP). Admittedly, the object of the pinning mechanism that was proposed here (knowledge of DANE existence) was not quite as fraught as pinning public keys. But recovery from incorrect pins remains a challenging issue. The DANE pinning proponents eventually did back down somewhat by proposing that the pinning behavior could be optional or specified later, as long as the extension contained a pinning field, but the Web camp was not swayed by this either.

Was there a way forward?

Given there is no easy way to reconcile these fundamental disagreements, one side was going to have to compromise, and it should have been the DNSSEC side. It can be argued that there were intransigent positions on both sides. But like it or not, the reality is that the adoption of new features in the Web is highly dependent on the actions of a small number of organizations that dominate the web browser market. This is just one aspect of the increasing centralization of the Internet, which is a concerning topic in its own right.

Some of my colleagues in the DANE camp strongly believe that there were members on the Web side acting in bad faith, throwing up obstacles so as to defeat this effort. I have no way of confirming or disconfirming this claim, so I will limit myself to speaking about the technical aspects of this argument.

The strategy I advocated was to give up on the downgrade protection requirement, get our foot in the door with DANE first, and then pursue a strategy of gradual improvement. Some web browsers work by introducing a new feature tentatively, collecting telemetry on the use of the feature, and, if positive, proceeding on subsequent enhancements. This could have worked in favor of DANE. If DANE usage was taking off, the user community could have come back and asked for enhancements that mandate DANE usage, whether that be a pinning mechanism or even something like a DANE preload list (similar to what has been done with HSTS). The adoption of DANE, even in one browser, might cause others to later follow suit by peer or market pressure.

If DNSSEC/DANE proponents are so insistent and uncompromising in our stance that we can’t even get our foot in the door of an important and widespread application community, then we’ve lost the battle even before it’s begun. As it stands today, the prospects for DANE authentication in the web are quite bleak.

Are there alternative approaches?

In an ideal world, endsystems and applications running on them would be able successfully lookup DANE and DNSSEC records without traffic interference from middleboxes. If widespread use of DNS over HTTPS takes off in the future, then that might be a way to effectively address the middlebox problem (HTTPS generally traverses middleboxes without impediment). The latency concern could also be substantially addressed by newer enhancements to the DNS protocol like the EDNS Chain Query Extension, but so far there has been little uptake or implementation of it.

What's next?

The TLS DNSSEC Chain Extension is not completely dead. While it failed to be standardized in the IETF’s TLS working group, we have a plan to publish a version of it through the IETF’s Independent Stream. The first likely use case for it will be for DNS over TLS servers, to allow in-band DANE authentication of a DNS server. There may be other possible applications such as IMAP, POP, and SMTP submission. I’ll try to be optimistic and hold out hope that Web browsers can be persuaded to look at DANE again at some point in the future.

Shumon Huque