Authentication of Domain Name System (DNS) names for Transport-Layer Security (TLS) endpoints is a core security challenge in many Internet protocols, most famously Hypertext Transfer Protocol (HTTP). Today, the cryptographic bindings that underlie TLS authentication are asserted in Public Key Infrastructure for X.509 (PKIX) certificates issued by third-party certification authorities (CAs). The DNS-based Authentication of Named Entities (DANE) working group is developing protocols that allow certificates to be bound to DNS names using Domain Name System Security Extensions (DNSSEC). These protocols will enable additional assurances for the traditional, PKIX-based model, as well as enabling domain holders to assert certificates for themselves, without reference to third-party certificate authorities. With this increased responsibility, however, DNS operators will play a more critical role in securing applications. So while DANE holds the promise of more direct authentication, it will also create some new security challenges.
TLS is used as the basis for security features in many modern Internet application service protocols in order to provide secure client-server connections (RFC 5246). It underlies secure HTTP and secure email (RFC 2818, RFC 2595, RFC 3207), and provides hop-by-hop security in real-time multimedia and instant-messaging protocols (RFC 3261, RFC 6120). In all of these applications, the service that the user ultimately wants to connect to is identified by a DNS domain name (RFC 1034). A user might enter “https://example. com/” into a web browser or send an email to “email@example.com”. One of the main purposes of using TLS in these cases is thus to authenticate the server as a legitimate representative of the domain name, in other words, to assure the user that the entity on the other end of the connection actually represents “example.com”. Note that this applies to DTLS as well, since it uses the same handshake as TLS.
Today, a server asserts its right to rep- resent a domain by presenting a PKIX digital certificate (RFC 5280). A client then has to evaluate the certificate to decide whether or not the certificate is sufficient to establish the server’s identity. This decision is usually based on two criteria:
- whether the certificate contains the desired domain name (RFC 6125), and
- whether the certificate is issued under a trusted certification authority (in the PKIX parlance, a “trusted CA” or “trust anchor”).
In order to apply this second criterion, the client must choose some set of trust anchors. In current systems, the choice of trust anchors is mostly out of the user’s hands. For example, all modern browsers and operating systems come with default trust anchor lists. Users can add to this list, using their browsers’ “Accept this certificate?” dialogs, al- though it can be very difficult to remove trust anchors from the default list.(1)
The result of the current, manual model is that trust anchors end up having very broad authority. With no way to discover which trust anchor should be vouching for a particular set of domain names, current systems allow any trust anchor to issue certificates for any domain name. The risks of having broadly trusted CAs have recently become clear, as attackers were able to break into two small CAs and create fraudulent certificates for Google and Facebook, among others.(2),(3) The importance of default trust lists has also driven up the cost to application providers of deploying TLS, leading some to rely on self-signed certificates, which provide no authentication at all (with- out some out-of-band negotiation).
The IETF DANE working group(4) was chartered to develop ways to use DNSSEC to improve TLS authentication of domain names. With the advent of DNSSEC, it is possible for clients to obtain authenticated data directly from zone operators. In the context of TLS in particular, DNSSEC should allow clients to securely ask the operator of a domain about which certificates they should accept as credentials for that domain. The domain operator might specify constraints on certificate validation or even supply a new trust anchor. As with most new technologies, there will be a few challenges in migration; most notably, DNS operators will play a far larger role in the security of Internet applications. But if these challenges can be overcome, then DANE should increase both the security of applications and the ability of domain operators to secure the services they offer.
If the goal of DANE is to allow domain operators to make statements about how clients should judge TLS certificates for their domains, then what sorts of statements should DANE allow them to make? The DANE use cases document (draft-ietf-dane-use-cases) lays out three major types of statements:
- CA Constraints: The client should only accept certificates issued under a specific CA.
- Service Certificate Constraints: The client should only accept a specific certificate.
- Trust Anchor Assertion: The client should use a domain-provided trust anchor to validate certificates for that domain.
All three of the above statements can be viewed as constraining the scope of trust anchors. The first two types limit the scope of existing trust anchors; the third provides the client with a new trust anchor (still within a limited scope). More on these in a moment.
The current draft DANE protocol defines a DNS Resource Record type TLSA for describing TLS associations—statements about what certificates are associated to a domain (draft-ietf-dane-protocol). Each TLSA record has three basic fields:
- Usage: Which type of statement this record is making
- Selector/Matching: How a TLS certificate chain should be matched against this record (e.g., by exact match, by public key, or by SHA-1 digest)
- Certificate for Association: The actual data against which the TLS certificate chain should be matched
These records are stored under the target domain with a prefix that indicates the transport and port number for the TLS server. For example, if Alice runs a secure web service at example.com, and wants to tell clients to only accept certificates from Charlie’s CA, she could provision a TLSA record under _443._tcp.example.com with the following contents:
- Usage: CA constraint
- Selector/Matching: SHA-1 digest
- Certificate for Association: SHA-1 digest of Charlie’s certificate
When client Bob wants to connect to “https://example.com,” he can find these TLSA records and apply Alice’s constraints when he validates the server’s certificate.
Adding Constraints to PKIX
The major objective of the CA constraints and service certificate constraints is to guard against mis-issue of certificates. A certificate is mis-issued when a CA issues a certificate to an entity that does not represent the domain name in the certificate. Mis-issue can come about in many ways, including via malicious CAs, compromised CAs (as in the Comodo and DigiNotar example above), or CAs that are simply misled as to the attacker’s identity through fraud or other means. Today, mis-issue can be difficult to detect, as there is not a standard way for clients to figure out which CAs are supposed to be issuing certificates for a domain. When an attacker issued false certificates for the Google Gmail service under the DigiNotar CA, it was noticed only because a vigilant user posted to a Gmail help forum.(5)
By contrast, domain operators know exactly which CAs they have requested certificates from, and, of course, which specific certificates they have received. With DANE, the domain operator can securely convey this information to the client. For example, to guard against the DigiNotar attack, Google could have provisioned a TLSA record expressing a CA constraint with their real CA (which is not DigiNotar) or a certificate constraint with their actual certificate. Then DANE-aware clients would have been able to immediately see that the DigiNotar certificates were improperly issued and possibly indicative of a man-in-the-middle attack.
Empowering Domain Operators
According to data from the EFF SSL Observatory, which scans the whole IPv4 address space for HTTPS servers and collects their certificates, approximately 48 percent of all HTTPS servers present self-signed certificates.(6) A number of other servers present certificates issued under CAs that are not in the major default trust anchor lists. For example, the United States Air Force web portal(7) uses a certificate issued under a Department of Defense CA that is not trusted by Firefox. In the current environment, most clients cannot authenticate these servers at all; they have to rely on users manually accepting certificates, hopefully with some out-of-band information. As a result, these servers and their users are highly vulnerable to man-in-the-middle attacks against their supposedly secure sessions.
DANE trust anchor assertions enable the operators of a domain to advertise a new trust anchor, under which certificates for that domain are issued. Using these records, clients can dynamically discover what trust anchors they should accept for a given domain instead of relying on a static list provided by a browser or operating system.
It may seem odd to talk about a domain supplying a client with trust anchors, since trust anchor provisioning is typically a very sensitive activity. If an attacker is able to install a trust anchor into a victim’s trust anchor store, then the attacker can masquerade under any name by issuing certificates under that name. In fact, the PKIX working group has defined an entire protocol for managing trust anchors (RFC 5934).
DANE ensures that trust-anchor provisioning is secure by applying scoping, and verifying its scoping using DNSSEC. DANE trust anchor assertions are scoped to a particular domain name, so even if an attacker can introduce a false trust anchor, he can only use it to spoof a single name. Furthermore, trust anchor assertions must be DNSSEC signed, meaning clients can verify that the entity providing the trust anchor represents the domain in question. Ultimately, the client still has to have a list of trust anchors configured, but DNSSEC trust anchors instead of PKIX trust anchors. Of course, in principle, a client only needs one trust anchor for DNSSEC—the root zone trust anchor. Since control of the DNS root doesn’t change often, it makes sense that it be statically configured!
The ability of a domain operator to explicitly indicate a trust anchor for a domain is obviously very powerful. It may be tempting to ask whether this is really the only use case that DANE needs, i.e., whether the constraint cases above are needed at all. The answer is that the constraint cases are useful as a way to fold in PKIX validation with external CAs, in addition to domain-asserted trust anchors. Most obviously, this feature is useful in transition, when not all clients are DANE-aware. But even in the longer term, it’s possible that CAs will provide added value over DANE. For example, although DANE is designed to bind certificates to domain names, CAs can vouch for bindings of certificates to other things, including the legal identity and physical location attested to in Extended Validation certificates.(8)
As described above, DANE offers valuable new security properties for TLS authentication. But, as with most IETF technologies—especially security technologies—there are both challenges to overcome and potential pitfalls.
The most significant constraint for DANE deployment is DNSSEC deployment. On the server side, this is not a huge issue considering DNSSEC support is spreading fairly rapidly. On the client side, things may be more difficult. While there are DNS libraries with robust DNSSEC support, many of the major DNS APIs that are used by applications do not provide information about the DNSSEC status of the results returned. In order to implement DANE, application developers may have to refactor their DNS support, in addition to querying for new record types. If more sites come to rely on DANE, this could also draw increasing attention to the various types of intermediaries that cause DNSSEC breakage (e.g., home gateways that improperly set DNS flags).
Adding DNSSEC to the TLS connection process can also add significant latency to the TLS connection process. In addition to completing the TLS handshake and certificate validation, the client has to wait for several DNS round-trips and then validate the chain of DNSSEC signatures. These combined delays can add up to multiple seconds of latency in connection establishment. Especially for real-time protocols such as HTTPS, SIP, or XMPP, such delay is clearly undesirable.
The primary mechanism proposed to mitigate these delays is to have the server pre-fetch all of the relevant DNSSEC records (i.e., DS, DNSKEY, and RRSIG records chaining back to the root). Then the server can provide a serialized version of the DNSSEC records in the TLS handshake, saving the client the latency of the required DNS queries. The details of this mechanism, however, are still being worked out among the DANE, TLS, and PKIX working groups (draft-agl-dane-serializechain). A prototype version is now available in the Google Chrome web browser.(9)
From a security perspective, the major impact of DANE is the new role that DNS operators will play in securing Internet applications. DNSSEC has meant that DNS operators have more security functions; DANE deployment will give them an explicit impact on application security, acting as arbiters of who can authenticate under a given name in TLS. Particularly if services make use of trust anchor assertions, DNS operators will play an analogous role to the one CAs play today—meaning, a compromise in a DNS operator will enable an attacker to masquerade as a victim domain (albeit for a more limited set of domains due to DANE’s constraints on names). In this way, DNS operators are likely to inherit many of the security troubles that CAs experience today and will need to strengthen their security posture accordingly.
Another more subtle risk arises from the fact that the operator of a DNS zone is not always the same as the entity that is authorized to control the contents of the zone, which we can call the domain holder. We used the phrase domain operator above, since DNSSEC only protects DNS information between the operator’s name server and the client—it doesn’t say that what’s provisioned in the name server is authorized by the domain holder. When a domain is operated by a third party, the third party is a point of vulnerability between the client and the holder of the domain. If the domain operator provides false DANE information through malice or compromise, then a client will not be able to distinguish it from genuine DANE information. To some extent, this risk is not new; many current CAs authenticate requests for domain certificates based on information under the control of the domain operator, domain operators can already influence the credentialing process. With DANE, however, the vulnerability is much easier to exploit as the DNS operator needn’t trick a third party. This vulnerability is also fundamental to protocols that rely on DNSSEC for security. The implications for DANE are discussed in detail in the DANE use cases document (draft-ietf-dane-use-cases). The main mitigation is simply increased care on the part of domain holders to ensure that domain operators are not behaving badly.
For many years now, Internet applications have relied on assertions by third-party certification authorities to ensure that a server holding a particular private key was authorized to represent a domain. The promise of DANE is a more direct interaction between clients and the domains they interact with, secured by DNSSEC. In the short run, DANE can be deployed as an adjunct to the current system of certificates and authorities, adding constraints to better protect domains. In the long run, DANE will enable domain operators to vouch for their own names.
The transition and security issues that face DANE are largely the growing pains of DNSSEC. It’s not that DANE is causing these problems itself; rather, the problems arise because DANE is the first real usage of DNSSEC that is expected to be widely deployed. So while it may be difficult to mitigate some of the security issues raised by DANE and to enable more robust DNSSEC support in applications and gateways, these changes will ultimately make it simpler for applications to use DNSSEC for other purposes.
The DANE working group is making consistent progress on its deliverables and there already exist some prototype deployment tools. Their use cases document has been approved by the IESG (draft-ietf-dane-use-cases), and the document defining the TLSA record type is maturing (draft-ietf-dane-protocol). On the client side, a variant of DANE has been implemented in Google Chrome; on the server side, there are prototype tools available to generate DANE records and to generate DNSSEC-stapled certificates based on DANE records.(10),(11)
- http://arstechnica.com/apple/news/2011/09/safari-users-still-susceptible-to- attacks-using-fake-diginotar-certs.ars
- http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a &hl=en