New opportunity for DANE for web
RFC 9102 published, first implementations in progress
Publication of RFC 9102 in August 2021 opened the way for the complete chain of DNS(SEC) records required for DANE validation to be included in the TLS exchange itself (in-band). Consequently, when setting up a secure connection (e.g. HTTPS), no extra DNS queries are required in order to check the authenticity of the presented TLS server certificate using DANE.
The advantage of the new approach is clear: it means that a TLS connection can be established more quickly than if all the necessary records (or, more precisely, resource record sets) have to be requested separately (out-of-band). That applies not only to general TLS connections, but also to DoH and DoT, for which fewer connections therefore need to be initiated.
Because some middleboxes and access routers won't forward DNSSEC records, they can't always be obtained via the DNS system. Complete in-band DANE/DNSSEC chains represent a solution in those situations as well.
It should be noted, however, that the new technology is currently still experimental. NLnet Labs is working on an extension that will enable their validating stub resolver Stubby to perform in-band DANE validation on its DoH/DoT connections. A little further ahead is a DoH plugin for Apache and Nginx, which will provide them with support for the new technology.
DANE and DNSSEC
Although the DANE security standard is more than ten years old, it has only recently started to break through. Even now, only about half of mail domains use it. The standard is defined for general use (in RFC 6698, 7218 and 7671): TLS server certificates (based on X.509) are anchored by publishing the hash of each certificate in a TLSA record. Because DANE requires the use of DNSSEC, the authenticity of a certificate is cryptographically assured by anchorage to the DNSSEC trust anchor via the chain of trust.
As well as the hash value itself, TLSA has a 'Usage' field, which determines how the hash should be interpreted:
0) PKIX-TA: anchors a particular CA certificate in the TLS chain of trust (in addition to traditional validation)
1) PKIX-EE: anchors a particular server certificate (in addition to traditional validation)
2) DANE-TA: anchors a particular CA certificate in the TLS chain of trust, enabling it to function as a trust anchor
3) DANE-EE: anchors a particular server certificate, which has to match the certificate provided by the server
DANE for web and DANE for mail
Usages 0 and 1 anchor the certificate of, respectively, a CA and a server, to supplement conventional validation on the basis of trust anchors provided in the client (typically a browser). Hence, the first two options are described as 'restrictive' (they add another security constraint to the existing system). Usages 2 and 3 operate independently from conventional TLS validation, meaning that they are (additionally) suitable for self-signed certificates. They also enable clients without trust anchors to be served. Those two options are therefore described as 'additive' (they provide an option not offered by the existing system).
One protocol under which clients do not have trust anchors is SMTP, for the transport of e-mail messages. RFC 7672 specifies how DANE can be used for mail exchange between MTAs. Because mail servers do not have trust anchors, only usages 2 and 3 are permissible in this context. Furthermore, DANE for mail is an opportunistic protocol: a TLSA record authenticates a particular server certificate for a client, implying support for STARTTLS, but does not require the client to use TLS for message transfer.
In practice, DANE for web is currently barely used [1, 2], while DANE for mail [1, 2] is quickly gaining traction (or was).
A long history
The history of the TLS extension to the DNSSEC chain of trust for DANE – the 'chain extension' – goes right back to the development of DANE itself more than ten years ago. The first implementation of a DANE-like chain extension for Chrome (by Adam Langley) disappeared from the browser within two years because it proved unsuitable and was consequently not used. In Langley's proof-of-concept, the DNS(SEC) chain was included in an extension to the certificate itself (a 'DNSSEC stapled certificate'). TLSA records didn't exist at that time, so a TXT record was used.
However, the approach proved unpopular with CAs, because it implied including a new block in every signature. It also meant that the certificate had to be renewed whenever the DNSSEC signatures were renewed. Use of Langley's system would therefore have involved various undesirable and impractical dependencies between the PKI/CA system and DNSSEC.
A new approach
The period 2015 to 2018 saw development of the current specification's predecessor. The new solution involved the addition of an option to the TLS protocol, enabling the client to request the relevant DANE/DNS(SEC) chain. In this model, the server functioned as an intermediary: it requested the required records locally and sent them to the client in serialised form via the existing connection, thus utilising the resolver functionality and caching capability already present. A further advantage was that the client got end-to-end validation (at the application level), even if it only had a (non-DNSSEC-validating) stub resolver.
A crucial difference between the new solution and the previous one was that DANE was no longer dependent on the CAs. Both the TLS community and the browser builders were enthusiastic about the new approach. The DNS Security article series written by Richard Barnes, then working for Mozilla, is available here.
Disagreement
Although Mozilla already had an implementation ready for its Firefox browser, the proposed new approach didn't catch on. For one thing, it supported only the additive DANE usages, and the chain extension was restricted to the communication of DANE/DNS(SEC) records. In addition, Victor Dukhovni, now best known for his DANE adoption measurements, pointed out that the approach was vulnerable to a downgrade attack by a man-in-the-middle (MITM). If you rely on an alternative channel without checking the DNS system itself, and the alternative channel reports that no DNSSEC records are present, you cannot be certain whether that is really the case.
However, the two objections are related, and have been used as cover for protecting the commercial interests of the CAs: as long as the available DANE functionality cannot completely replace the PKI/CA system, there will be no support for additive DANE.
Dukhovni argued that the proposed system had a serious security flaw, and that certificate pinning should therefore be supported as well. However, as well as taking exception to Dukhovni's tone, the web community has had some negative experiences of pinning (e.g. HPKP, the predecessor of HSTS). Consequently, after a year of discussion, both the TLS Working Group and Barnes withdrew.
New opportunity
Now joined by Dukhovni and security software engineer Paul Wouters, the group developed the chain extension proposal into the Independent Submission Stream. With pinning now added by Dukhovni, the experimental specification is now ready for implementation.
Although end users have little interest in DNSSEC, Willem Toorop (developer and researcher at NLnet Labs and co-author of the RFC) is hopeful about adoption of the chain extension. "We shouldn't try to add this security to long-established TLS applications, such as IMAPS and POPS (in the mail client). New technologies such as DoH and DoT represent much better opportunities. A lot is currently happening with DoH in web browsers."
"For example, a method for encrypting TLS from the very start is under development, known as Encrypted Client Hello (ECH). That's significant, because the TLS handshake isn't currently encrypted, meaning that the service to which a connection is established isn't secure. With ECH, the public element of the key pair used to encrypt the handshake will be included in a special DNS record: the SVCB or HTTPS record. The idea is that the records will be available to browsers via their inbuilt DoH. In order to assure the authenticity of the records (and thus the security of the TLS handshake), you need DNSSEC."
"So DNSSEC keeps cropping up in these new, emerging standards (see this example). And, as browser-builders make more use of DNS in their software, the opportunities for DNSSEC and DANE increase."
