Less is More: Cipher-Suite Negotiation for DNSSEC ∗
Amir Herzberg
Haya Shulman
Bruno Crispo
Department of Computer Science Bar Ilan University Ramat Gan, Israel
Fachbereich Informatik Technische Universität Darmstadt Darmstadt, Germany
Department of Information Engineering and Computer Science (DISI) University of Trento, Italy
[email protected]
[email protected]
[email protected]
We propose a transport layer cipher-suite negotiation mechanism for DNSSEC standard, allowing name-servers to send responses containing only the keys and signatures that correspond to the cipher-suite option negotiated with the resolver, rather than sending all the signatures and keys (as is done currently). As we show, a lack of cipher-suite negotiation, is one of the factors impeding deployment of DNSSEC, and also results in adoption of weak ciphers. Indeed, the vast majority of domains rely on RSA 1024-bit cryptography, which is already considered insecure. Furthermore, domains, that want better security, have to support a number of cryptographic ciphers. As a result, the DNSSEC responses are large and often fragmented, harming the DNS functionality, and causing inefficiency and vulnerabilities. A cipher-suite negotiation mechanism reduces responses’ sizes, and hence solves the interoperability problems with DNSSEC-signed responses, and prevents reflection and cache poisoning attacks.
Keywords Cipher suite negotiation, DNSSEC, DNS security, DNS interoperability.
1.
INTRODUCTION
A cipher-suite is an ordered set of (one or more) cryptographic algorithms, each implementing a corresponding function among the functions used by a cryptographic protocol. For example, the RSA_WITH_RC4_128_MD5 cipher suite uses RSA for key exchange, RC4 with a 128-bit key for bulk encryption, and MD5 for message authentication. Cipher-suite negotiation refers to the process of selecting the cipher-suite to be used in a protocol between two (or more) parties, among multiple cipher-suites supported by each of the participants. Many standard cryptographic protocols, e.g., IKE, SSH, SSL and TLS, [RFC2409, RFC4253, RFC6101, RFC5246] ∗Part of this research was conducted while the first author was visiting Technische Universtät Darmstadt and CISPA, Saarland University.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ACSAC ’14 Dec. 8-12, 2014, New Orleans, LA, USA Copyright 2014 ACM 978-1-4503-3005-3/14/12 ...$15.00. http://dx.doi.org/10.1145/2664243.2664283.
use cipher-suite negotiation to ensure that the parties select the ‘best’ cipher-suite among those they jointly support, in order to avoid broken algorithms and to facilitate migration to better (more secure, more efficient) algorithms. Currently, DNSSEC is an exception: it allows the use of multiple signature algorithms and hash functions, e.g., RSA and elliptic curves (see [10] for a complete list of cryptographic algorithms), however, no mechanism was designed to enable parties to select the strongest option that they support. As a result, during a DNS transaction between a resolver and a name server, all the keys and signatures, supported by the target zone, have to be exchanged. Namely, the name server always returns all these values to the resolver, even if some of these algorithms are unsupported or unvalidated by the resolver. The lack of cipher-suite negotiation in DNSSEC implies larger DNSSEC-signed DNS responses, due to inclusion of multiple keys and signatures; Figure 1 plots the responses’ sizes from Top Level Domains (TLDs) and top 1 million domains according to Alexa www.alexa.com. The measurements show that the overhead of signed DNS responses is significant in comparison to plain DNS responses. For instance, non-existent domain (NXD) is a very common response, which often occurs due to a typo in a DNS query: the size of NXD responses without DNSSEC is less than 400 bytes while with DNSSEC 70% the responses exceed 1000 bytes and 10% are even larger than link Maximal Transmission Unit (MTU) (which also holds for more than 30% of DNSKEY responses). Signed responses for ANY query type can reach even 5000 bytes and more, while plain ANY type responses are less than 1000 bytes. This huge overhead is twofold and has implications both on computation and communication complexity.
100 Legend DNSKEY (TLDs) NXD signed (TLDs) NXD (TLDs) ANY (TLDs) ANY signed (TLDs) ANY signed (Alexa)
80
Domains (%)
ABSTRACT
60
40
20
0 0
1000
2000 3000 Response Size (bytes)
4000
5000
Figure 1: Length of responses for signed and non-signed Alexa and TLDs, for ANY, DNSKEY and A RRs.
Communication overhead. Large responses cause noticeable overhead: (1) on the name server that is required to transmit them,(2) on the recepient that needs to receieve and process them (allocate buffers to store and reassemble) and (3) on the network, and intermediate devices, e.g., routers and proxies, causing load spikes and increasing processing. Indeed, recent measurements, e.g., [14], show that a significant increase in the DNS infrastructure, both in resolvers and name servers platforms, is required in order to migrate to DNSSEC. Not only much more data, than needed, is sent: the name server sends all the keys and signatures that correspond to the cryptographic options that the zone supports, but also such large responses often result in fragmentation or cause resolvers to use TCP for the DNS transaction. The communication overhead also depends on the frequency at which the resolvers request the records from signed zones; the frequency is dictated by the time-to-live (TTL) value, set by the zone operators, and the resolvers cache the records until the TTL value expires. In Figure 2 illustrates the TTL values of name servers records from TLDs and Alexa domains: 60% of the TTL values are less than a day (86400 seconds) and almost 50% are less than one hour. Furthermore, these large responses, when causing fragmentation, may even expose to DoS and DNS-poisoning attacks, see [4]; more details in Section 2. Computation overhead. Signatures generation increases the computational overhead on name servers and is significant for dynamic zones, e.g., the common content distribution networks. Signatures verification imposes overhead on busy resolvers and is prohibitive for mobile devices, making support of DNSSEC on endhosts impractical. We believe that these problems with large responses, and the lack of cipher-suite negotiation mechanism, motivate administrators to use only a limited number of cipher-suites. In particular, without cipher-suite negotiation mechanism administrators are likely to avoid algorithms with longer keys/signatures, e.g., 2048 or 4096 bit RSA; these may offer better security, but surely will increase response length significantly and as a result also exacerbate the interoperability problems and exposure to attacks. Paradoxically, for a different motivation, administrators are also 100 90 80 % of NS RRset
70 60 50 40 30 20 10 0
20000
40000
60000 80000 100000 120000 140000 160000 TTL value (in seconds)
Figure 2: Distribution of the time-to-live (TTL) values in DNSKEY records in TLDs and Alexa domains. likely to avoid offering alternative algorithms which may offer good security even with shorter keys/signatures, e.g., elliptic curves. Without ciphersuite negotiation, there is no motivateion to offer such shorter alternatives, since when sent in addition to the existing keys/signatures, e.g., 1024-bit RSA (which is mandatory to support), the resulting length of the response is even larger. With the growing awareness of the existence of powerful, nationstate adversaries, who may be able to crack such key length, we find it alarming that 1024-bit RSA implementations are still dom-
inant. Furthermore, 1024-bit RSA is entrenched, by being the default algorithm for DNSSEC, as mandated by NIST and IETF standards [RFC4033-4035], and further by the lack of cipher-suite negotiation in DNSSEC. Indeed, as Figure 3 shows, the current adoption of DNSSEC algorithms by signed domains appears to support our conclusions: the 1024-bit RSA algorithm, already considered not-sufficientlysecure, is, by far, the most popular, while the elliptic curve (EC) variant, in spite of its shorter keys and signatures, and although it was standardised [RFC6605], is still not deployed. This lack of adoption of non-default algorithms by name servers, also demotivates resolvers from supporting such algorithms, e.g., elliptic curve. This creates a vicious cycle, as zones are further de-motivated from using non-default signature algorithms, which are likely to be compatible only with few resolvers. Elliptic curve signatures (e.g., EC-DSA) also have some significant drawbacks, including long verification time and concerns for potential trapdoors; further research may identify secure signature mechanisms that are more suitable for this challenge. We conclude that cipher-suite negotiation for DNSSEC is essential to security, interoperability and efficiency of DNS and DNSSEC. Furthermore, it may allow end-to-end cryptographic protection of DNS, in particular, in mobile devices. Downgrade attacks and existing ciphersuite negotiation mechanisms. In a downgrade attack, a MitM attacker tries to trick a client and server into using a weak cryptographic mechanism, although both the client and the server support and prefer a stronger cryptographic mechanism. For example, such attack is known against version 2 of SSL, which supports cipher-suite negotiation, but insecurely, see, e.g., [16, 11]. Existing standardised cipher-suite negotiation mechanisms, were all designed for authenticated keyexchange protocols, e.g., IKE and TLS. These mechanisms are interactive, i.e., operate in two rounds. In the first round, the client sends its list of cipher-suites, typically in order of preferences, and the server responds by identifying the chosen cipher-suite (from the client’s list). The second round uses the authenticated key exchanged by the protocol, to validate that, earlier, the server received the correct cipher-suite (i.e., the one sent by the client). Authentication is done by exchanging the Message-AuthenticationCode (MAC) computed over the cipher-suites sent by the client (and other exchanged values, including random nonces to prevent replay). However, such a two-round, interactive mechanism, would add too much overhead to a DNS transaction and is not suitable for DNS, which is a pure request-response protocol. In contrast, our proposed secure cipher-suite negotiation protocol is non-interactive; it only adds few, short fields, to the messages exchanged during a DNS transaction. This is important, since adding another round would cause significant extra delay, as well as make deployment much harder. Note that our single-round, ‘piggybacked’ mechanism is possible since in DNSSEC, the entire set of supported public keys and algorithms, is signed (‘certified’) together; this holds for both Key Signing Keys and Zone Signing Keys. This is in contrast to typical PKI certificates, as used by both IKE and TLS, where the same entity may have multiple keys, algorithms and certificates, and has no signature over its entire set of keys, algorithms and certificates. Our proposed DNSSEC cipher-suite negotiation mechanism also has a security advantage, cf. to the negotiation mechanisms previously specified, e.g., for TLS. Namely, known negotiation mechanisms are vulnerable, if the attacker can expose the cryptographic keys in real time, allowing the attacker to compute the MAC and thereby trick the parties into believing that cipher-suite negotiation was done correctly. Such an attack was presented against TLS
[13]. In this paper, we focus on host-by-host (transport layer) ciphersuite negotiation for DNSSEC. An alternative, which we present in [7], is an end-to-end approach, whereby the signaling is in application layer. In the design in [7] the signaling is performed by concatenating a list of DNSSEC algorithms as subdomains, to the query; the preferences for ciphers are expressed via the order of concatenation after the query. The obvious disadvantage of the mechanism in [7] is, therefore, that any possible difference in the order of preferences, results in request to different record. On the other hand, the mechanism in [7] supports well the case of a ‘forwarding resolver’ which provides resolution services to several ‘proxy resolvers’, which may each have different cipher-suite policy (order of preference). We compare between the approaches in [9].
Contributions In this work we carry out a study of DNSSEC deployment status and challenges and design a transport layer cipher-suite negotiation for DNSSEC. We implemented our proposed design as userspace modules, for resolver and name server, and evaluated it with standard Bind-9.9.3 DNS software. The deployment of cipher-suite for DNSSEC would alleviate deployment obstacles, and would speed up adoption of DNSSEC both by resolvers and zones.
Organisation In Section 2 we discuss deployment status of DNSSEC, review factors impeding deployment and argue that the main ostacle towards deployment is large DNSSEC-enabled responses. We also show that signed domains currently mainly support weak ciphers. We then provide a design of cipher-suite negotiation for DNSSEC in Section 3, and describe its implementation and evaluation. In Section 4, we provide an overview of DNS. We conclude this work and discuss future research in Section 5.
2.
INTEROPERABILITY CHALLENGES AND VULNERABILITIES
Zones that adopt DNSSEC typically support a number of cryptographic keys, which results in large DNSSEC enabled responses; however, as we next show, mostly weak cryptographic options are supported. Signed DNS responses may often cause problems to resolvers, name servers and Internet clients and services. In particular, due to their increased size, signed responses are often exploited for attacks, e.g., cache poisoning and DDoS, or may disrupt DNS functionality and availability. As a result, zone operators are often hesitant about signing their zones, and resolvers’ operators typically do not enforce validation. The outcome is impeded deployment of DNSSEC. Indeed, most DNS resolvers do not support DNSSEC validation, and many zones are not signed with DNSSEC. The fact that there is currently limited deployment of DNSSEC further reduces a motivation for early adopters, since protection of DNSSEC only ‘kicks in’ when all the entities, involved in a resolution of some domain, support DNSSEC. DNSSEC Validation at Resolvers. A significant fraction of the resolvers currently signal DNSSEC support; however, less than 3% actually enforce DNSSEC validation [12]. Obviously, for such nonvalidating resolvers, DNSSEC does not provide added security. In fact, non-validating resolvers are open to cache-poisoning attacks, in particular attacks exploiting the fact that such resolvers receive large DNSSEC responses (but do not validate them) [4]. DNSSEC Deployment at Zones. To make DNSSEC validation ef-
fective in resolvers the zones have to adopt DNSSEC. However, most do not. Recently, the root and some important top-level domains, such as com, net and org, were signed; through experimental study we found that currently 62% of the TLDs are signed, however, less than one percent (0.46%) of top million Alexa domains are signed. We summarise the deployment status in Table 1. The first column, Table 1, lists the domains in the forward and reverse DNS trees that we tested. The second column contains the number of registered domains that were tested. This is mainly relevant in the reverse DNS tree, where a large fraction of the domains (that correspond to IPv4 address blocks) are not registered; in those cases our queries were answered with non-existing domain responses. The third column contains the number of name servers in each domain space (rounded to thousands, i.e., K ≡ 1000). Then, in subsequent columns, we report on our measurement of the number of signed domains. In forward DNS, we found that 62% of the Top-Level Domains (TLDs) are signed and less than one percent (0.46%) of top million Alexa domains are signed. Even worse results were found by NIST, [15], who checked DNSSEC adoption among 1070 large industrial and financial US domains; out of those, they found only 1.4% to have adopted DNSSEC. In the reverse DNS tree, we found even lower percents: only 0.07% of the zones are signed. We found this surprising, since the reverse DNS is used by several common security mechanisms. Note that DNSSEC validation requires a ‘chain of trust’, hence, adoption is meaningful only when all the zones in the path from the root are properly signed. In what follows we outline the impact of large responses on stability and availability of DNS and Internet networks and services. As we argue, concerns for attacks and interoperability problems are among the main obstacles impeding wide adoption of DNSSEC.
domain
registered
name servers
signed
failure w/DNSSEC
Forward DNS Alexa Forward DNS TLDs rDNS x.in-addr.arpa. rDNS y.x.in-addr.arpa. rDNS z.y.x.in-addr.arpa.
50K 568 229 28K 27, 67K
32.5K 3.2K 1.5K 97K 9, 687K
0.46% 62% 84% 0.4% 0.06%
23% 2% 2% 32% 34.5%
Table 1: DNSSEC deployment and failures among domains in forward and reverse DNS trees.
2.1
Interoperability Problems with DNSSEC
DNSSEC enabled DNS responses are significantly larger than the corresponding ‘legacy’ DNS responses since they contain, in addition to the ‘regular’ DNS records, also DNSSEC-related records, mainly for signatures and public verification keys. Such responses often exceed the 512B maximal DNS size specified in [RFC1035], requiring use of the EDNS [RFC6891] extension mechanism; EDNS is also used to signal support of DNSSEC. Some firewalls drop these DNS packets, due to the response length. Indeed, DNSSEC responses often exceed the maximal transmission unit (MTU) on the path, and thus may get dropped or fragmented. Fragments are also blocked by some firewalls, mainly for security concerns. Due to concerns for the interoperability issues with large signedDNS responses, many resolvers that support DNSSEC, accept and cache unvalidated responses, thereby exposing themselves to a downgrade attack, [RFC4035]; for instance, to avoid interoperability problems, unbound resolver supports a ‘permissive’ mode, accepting responses with missing or incorrect signatures. In a downgrade attack an attacker sends fake responses that appear similar to responses passing through non interoperable devices. If DNS passes the forged responses to the application, then the attacker successfully performed a downgrade attack on the system, and poisoned the cache of the resolver, causing it to accept a forged response. For instance, consider an attacker that poisons the NS and glue A RRs, and provides a forged delegation NS RR to redirect the clients to a host of attacker’s choosing. The resolver will simply revert to plain DNS without the DNSSEC protection and will accept the spoofed records.
2.2
Deployment of Weak Cryptography
In our recent study, [7], where measured the DNSSEC algorithms, as well as the key sizes, supported by signed zones (among Alexa top million domains and TLDs), and found that most support different variations of RSA (with SHA1 or SHA256 hash functions) with weak keys, 1024 bits. The results are plotted in Figure 3. The categories are grouped according to key sizes1 ranges and according to different variations of the RSA cipher; since all the domains were found to support different versions of RSA algorithm, we do not mention ‘RSA’ in the figure. The measurements are consistent with the recommendations by NIST and IETF [RFC4641] for a mandatory support of RSA and also to avoid using large keys (specifying a range of 512-2048 bits for (ZSK) key size and recommending a default value of 1024 bits), in order to avoid fragmentation, communication and computation overhead and other problems with large keys and signatures. There is hardly any support of cryptographic algorithms that produce short signatures, such as ECC, since the motivation to add more overhead to the transmitted data is low. This supports our argument that cipher1 The transmitted keys and signatures are encoded in Base64 thus contain an extra byte of redundancy for every three bytes of actual data.
30
25
20
15 Alexa% TLDs% 10
5
0
Figure 3: Distribution of the ciphers and public key sizes supported by TLDs and Alexa top million domains.
suite negotiation mechanism is essential not only for deployment of stronger cryptography and adoption of new cryptographic ciphers, which currently the zone operators are hesitant to support, but also to mitigate the interoperability and overhead problems associated with DNSSEC.
2.3
Attacks on (Oversized) DNSSEC Responses
We discuss two potential abuses of ‘oversized’, large signedDNS responses: for amplification Denial-of-Service (DoS) attacks, and to manipulate responses, in particular, for cache-poisoning. We argue that part of the problem is partially due to the design of DNSSEC, which results in transmission of potentially unnecessary keys and signatures, especially if domains decide to support multiple keys and algorithms (as is highly desirable), and we propose possible (long-term) solutions. We note that oversized DNSSEC responses can be exploited mainly when served over UDP, hence one simple countermeasure is to only use TCP for long responses. Indeed, this is done by some large servers, most notably of the com and net top-level domains. Notice, however, that the use of TCP increases overhead on both network and server, for all responses - which can be significant. Furthermore, [12, 8] recently showed that clients that retrieve DNS records over TCP have high failure rates. We hope future research will result in UDP-based solutions, avoiding this overhead. Amplification Attacks. The size of DNSSEC responses significantly exceeds the size of traditional DNS responses. Such re-
sponses are often abused by attackers to launch amplification DoS attacks [17] to clog victim networks and hosts. In a DNS amplification DoS attack, the attacker sends to one or more DNS servers many requests, with spoofed (fake) source IP address of the victim. Name servers respond to such requests by sending (much larger) responses to the IP address that originated the DNS request. The amplification factor is the ratio between the number of response bytes sent by the amplifying (benign) DNS server, to the number of request bytes sent by hosts controlled by the attacker, in the corresponding requests. With DNSSEC, the ratio can be as high as a hundred. Indeed, while DNSSEC deployment is still very limited, it has already been abused in the largest DoS attacks in the recent years, with reported bandwidths of 100Gbps in 2010, 60Gbps in 2011 and 2012 (Arbor Networks Report) and 300Gbps (launched in 2013 against Spamhaus and Cloudflare). Sometimes, the victim of the DNS amplification attack is the amplifying DNS server itself, which wastes computation and network resources on sending the (amplified) response packets; however, more often, the victim is a network or host, which receives the responses. DNS servers use various mechanisms, to prevent their abuse as vectors in amplification attacks, in particular, to avoid wasting their own resources due to such attacks. In fact, the concern for amplification attacks, may be one of the considerations against adoption of DNSSEC by zones. Defences for name servers against their abuse as amplifiers include: • Imposing a maximal quota of queries from the same source IP address. This defence may help against attacks against a remote host or network, using the same (or related) IP addresses, but not against attacks on the amplifying server itself, where the source IP address is not important. Furthermore, this defense fails if there are many spoofed IP addresses, connected via the same victim network, as in the Coremelt attack [20]. Finally, DNS request quotas are prone to false-positives, i.e., identification of a benign sending resolver as an attacker. • Challenge-response mechanisms, mostly based on redirection of the request to another domain name, where the new domain name includes a random challenge (‘nonce’) used to ensure that the request did not contain a spoofed IP address. However, existing designs, e.g., [2, 21, 6], either do not support DNSSEC validation or are not widely deployed. • As mentioned above, some servers, most notably those serving the large top-level domains com and net, defend against this threat by sending long responses over TCP rather than over UDP. Attacks on Fragmented Responses. DNSSEC responses are often large enough, that they can exceed the MTU of networks in the path from the name server to the resolver (see size measurements in Figure 1) and hence, get fragmented by the name server or by a router along the path. Ironically, an attacker can exploit fragmented DNS responses for IP defragmentation cache-poisoning: by sending spoofed fragments, the attacker can trick the defragmentation mechanism into reassembling them together with the fragments sent by the legitimate source (name server). IP defragmentation cache-poisoning can be applied for DoS attacks, disrupting resolver to name server communication, for name server pinning, or even for DNS cache-poisoning, [4, 19]. (Note
that other DNS poisoning techniques are known, e.g., [3, 5].) Furthermore, due to the currently-common case of permissive validation, the resolvers will accept and cache the altered (reassembled) DNS responses.
3.
HOP-BY-HOP CIPHER-SUITE NEGOTIATION FOR DNSSEC
In this section we present the design for a cipher-suite negotiation mechanism for DNSSEC. According to our design, resolvers signal to name servers the list of ciphers that they support and the name servers select the strongest cipher from the list and return only the keys and signatures that correspond to the selected option. Recently, [RFC6975] standardised new options in EDNS0 enabling clients to signal the supported ciphers to the name servers. The signaling of deployed ciphers allows zone operators to determine whether they can adopt new cryptographic algorithms. However, the zones would still have to support the other algorithms, to serve resolvers which have not adopted the new cipher. We design cipher-suite negotiation mechanism, that utilises the signaling of the supported ciphers to produce a full fledged ciphersuite negotiation mechanism. Our design does not require changes to the DNS software or protocol, and can be easily integrated into the existing DNS infrastructure. We implemented our cipher-suite negotiation mechanism as two separate user space modules, ciphersuite client and cipher-suite server (Section 3.3). The modules, along with a DNS transaction supporting cipher-suite negotiation, are illustrated in Figure 4. The modules are configured to capture all DNS requests and responses exchanged between the resolver and the name server, and to perform cipher-suite negotiation between the resolver and the name server. The outcome is that the server only returns the cryptographic material that corresponds to the strongest cipher that was negotiated. Furthermore, our design uses the DNS packets themselves for signaling of the supported cryptographic options and thus does not add an additional round trip of communication. According to our design, the resolvers signal the cryptographic options via an EDNS0 OPT resource record, [RFC6891], Section 3.1. EDNS0 is already supported by the resolvers and name servers and is a prerequisite requirement for adoption of DNSSEC. EDNS0 was designed to allow adoption of new mechanisms, such as DNSSEC, by utilising existing EDNS fields; see Section 4 for background. Our mechanism requires a modification of the current signature procedure dnssec-keygen which currently signs each DNS record in a zone file which all the supported keys. We show how to extend it to enable cipher-suite negotiation, in Section 3.2. To test our implementation, we extended the dig (domain information groper) DNS lookup utility2 , with support for signaling of a list of ciphers. To integrate support of cipher suite also into the process of signing the zone file - instead of signing the same zone file with multiple ciphers, we create separate copies of the zone file, such that each copy corresponds to a single cipher. We next describe the cipher-suite mechanism, the implementation of the prototype and its evaluation.
3.1
Extending EDNS0 with New Cipher-Suite Options
EDNS0, [RFC6891], was designed to provide extra space for new flags and codes. We propose a new EDNS0 Extension Mechanism to negotiate a DNSSEC cipher option for a transaction between a 2 dig is a tool for performing DNS lookup by interrogating DNS name servers, and displaying the responses.
resolver and a name server. Since EDNS0 is compatible with legacy servers that do not support new options, our cipher-suite negotiation mechanism is also interoperable with existing resolvers and name servers. To signal support of cipher-suite negotiation, we introduce a new (cipher-suite ok) CO bit in the extended flags of the EDNS0 OPT record, see Figure 5. Resolver requests to perform ciphersuite negotiation by setting the CO bit in the EDNS0 OPT record, in the DNS request. We also reserve two new record types: ciphers and cipher. When signaling the CO bit, the resolver also places in the EDNS0 a list of cryptographic ciphers, that it supports, in the ciphers field, to convey the ciphers to the name server. A name server that supports cipher-suite negotiation mechanism responds with the CO bit set, and also places the selected cipher, from the ciphers list, into the cipher field in the EDNS0 record of the DNS response. The name server also places in ciphers field a list of cryptographic algorithms which the zone (for which it is authoritative) supports, along with a digital signature, stored in RRSIG record, over the server’s ciphers list, to prevent downgrade attacks. The algorithms conveyed in records ciphers and cipher are encoded as numbers. Each algorithm in DNSSEC contains a code number that corresponds to a DNSSEC public key (stored in DNSKEY record). The Delegation Signer (DS) and Hashed Authenticated Denial of Existence (NSEC3) use digests (hashed values as part of their resource record data). These hash algorithms also have code numbers. These codes signal to validating resolvers which cryptographic algorithm was used to generate the digital signature and the hash digest. Next to each cipher number, we also add a priority number in ascending order (highest priority is 1). In order to ensure a deterministic outcome from the ciphers negotiation process, the ciphersuite client must assign different priorities to each ciphers that it supports (and cannot assign the same priority to two distinct ciphers); e.g., in case a number of ciphers are considered equally secure by the resolver or by the target zone.
3.2
Splitting the Zone File
When supporting a number of cryptographic options, zone operators sign, typically using dnssec-keygen procedure, the same zone file with a number of algorithms. The signing process of DNSSEC creates a signature per each RR set, i.e., set of resource records of the same type; for instance, all the name servers (NS) records (of a specific domain) are signed as a single unit, and for each supported cryptographic option a signature is attached to NS RR set. When a number of cryptographic options are supported (as is typically the case) a number of signatures are created and attached to the RR set. The same applies to other DNS records, such as DNSKEY, i.e., all the DNSKEY RR set is signed with all the supported algorithmic options. As a result, DNS responses typically contain a number of signatures (that correspond to all supported cryptographic ciphers) for each RR set that they return. Similarly to [7], to encorporate support for cipher-suite negotiation, we extended the dnssec-keygen procedure, to generate a separate zone file, per each cryptographic cipher that the zone supports. Our ednssec-keygen (extended dnsseckeygen) performs the same number of signing operations as would have been performed by dnssec-keygen. However, instead of signing the same zone file with different keys (which results in a zone file where every RR set is coupled with a set of signatures per each supported cipher), it creates a separate copy of the zone file for each supported cryptographic cipher. Each resulting RR set in a signed zone file contains the signature that cor-
ednssec-keygen(ciphers, zone_file){ signed_zone_file1 = dnssec-keygen(ciphers[1], zone_file) signed_zone_file2 = dnssec-keygen(ciphers[2], zone_file) signed_zone_file3 = dnssec-keygen(ciphers[3], zone_file) return (for i to ciphers: return signed_zone_file_i) }
responds only to the cipher which was used to sign that copy of the zone file.
3.3
Cipher-Suite Negotiation Protocol
The steps of the protocol are illustrated in Figure 4. In step 2, cipher-suite client receives a DNS request (sent by the resolver in step 1). Cipher-suite client adds a list of supported ciphers to the ciphers field, of the EDNS0 record (in the additional section of a DNS request). Upon receipt of a DNS request, in step 3, with the CO bit set, cipher-suite server performs cipher-suite negotiation according to the preferences specified by the resolver and those supported by the zone, and forwards the request to a zone file that corresponds to the selected cipher. The name server retrieves the DNS records from the correct zone file and sends a response, step 5. Upon receipt of a response from the name server, cipher-suite server attaches the list of ciphers which the name server supports, along with a signature over that list and specifies the selected cipher in cipher field, then returns the request to the resolver, step 6. When cipher-suite client receives a response, it checks that the selected cipher is correct (according to the options supported by the resolver and the zone), validates the signature over the ciphers field, and forwards the response to the resolver, step 7. If one of the validation steps fails, the response is discarded. Cipher-Suite Client. Cipher-suite client adds signaling of ciphersuite negotiation along with a list of supported ciphers, to DNS requests, and validates that the DNS records in the responses are signed with the correctly negotiated cipher. Handling DNS Requests. Cipher-suite client adds to EDNS0 record the ciphers field with a list of ciphers that it supports and sets the CO bit. Handling DNS Responses. Upon arrival of a DNS response, ciphersuite client extracts from the EDNS0 record the content of ciphers, and checks that the value in cipher record contains an intersection between the ciphers supported by the server and the client. If so, it proceeds to validating the signature over the ciphers field transmitted in RRSIG record. For signature validation the cipher-suite client uses the key signing key (KSK) of the target zone; the KSK of the target zone can be obtained from the parent zone or by alternative means, e.g., via email or public key repository such as DLV, [RFC5074]. If the signature is valid, the cipher suite negotiation is successful. The resolver can then proceed to DNSSEC validation of the received DNS records with the negotiated cipher. Cipher-Suite Server. Cipher-suite server runs on the name server side. It obtains a list of all the ciphers that the zone supports, signed with the KSK of the zone; signing with a KSK is essential to prevent downgrade attacks (details within). This list of ciphers is placed into the ciphers field in EDNS0 record of the DNS responses sent to resolvers that signal support of cipher-suite negotiation in their requests. Handling DNS Requests. Upon receipt of a DNS request with the CO bit set, cipher-suite server extracts the ciphers list from ciphers record, signaled by the cipher-suite client. It then selects a cipher based on the ciphers list signaled by cipher-suite client and the list of ciphers supported by the target zone, while also applying the respective priorities (specified by the cipher-suite client
and the zone). Once the negotiated cipher is established, ciphersuite server identifies the zone file on the name server that corresponds to the selected cipher, from which the DNS records are retrieved. Handling DNS Responses. Cipher-suite server then adds to the ciphers field in EDNS0 record of the response from the name server a signed list of ciphers supported by the zone, and adds the selected cipher to the cipher field. The cipher-suite client uses the signed list of ciphers from the name server to validate that the cipher-suite negotiation was correct and that the ciphers list, that it sent in the DNS request, was not altered by an attacker, e.g., to cause a downgrade attack.
3.4
Resilience to Downgrade Attacks
Our cipher-suite negotiation is resilient to downgrade attacks. In particular, any attempt by the attacker to cause the communicating parties to use a weaker cipher version than the optimal one supported by them both, will be detected. In order to downgrade the defence to a weaker cipher the attacker can tamper with one of the following exchanges: Request to Target Zone. Attacker can tamper with the request of the resolver, and remove the strong ciphers from the ciphers field. The name server will not detect the attack since the request is not signed, and will send the response from the zone file that corresponds to the cipher selected by the attacker. However, the DNS response contains a signed list of ciphers supported by the zone, which allows the resolver to calculate the cipher which should have been selected by the name server. Since the outcome of the cipher selection process is deterministic, computation of the optimal cipher by the cipher-suite client, at the resolver, should yield the same outcome as the computation performed by the ciphersuite server, running on the name server. Response from Target Zone. If the attacker tampers with the response, sent by the name server, and removes ciphers from the ciphers list of the name server, signature verification by ciphersuite client will fail, and tampering will be detected. Downgrade of Chain-of-Trust. In order to authenticate the public verification (ZSK) keys of the target zone, DNSSEC validating resolver establishes a chain-of-trust from the root to the target zone. Attacker can tamper with the referral response from the parent zone, by removing all the DS records that correspond to strong ciphers supported by the target (child) zone. However, notice that the signature of the parent is over all the DS records, hashed public verification (ZSK) keys, of the child zone. Furthermore, the ZSK key is subsequently used to sign the ciphers list, which allows the resolver to authenticate the keys and to detect tampering during computation of optimal cipher.
3.5
Implementation and Evaluation
In this section we describe the implementation of cipher-suite client and cipher-suite server modules. We configured an iptables firewall rule to capture all packets to/from port 53 (DNS requests/responses) and to pass them to our cipher-suite client (on the resolver side) and cipher-suite server (on name server side) user space C modules for processing. In our implementation of the cipher-suite client and server we used the libipq module to retrieve the packets from the kernel queue for user space processing. Cipher-suite client (resp. cipher-suite server) module can be placed on the same physical host as the DNS resolver (resp. DNS name server) or can be configured on a separate host, with a suitable firewall rule to redirect the DNS traffic via the cipher-suite client (resp. cipher-suite server).
Cipher-suite server can be configured to support online and offline DNSSEC signing. According to the original design, DNSSEC required offline signing, i.e., the zone file is signed on a separate host, and then it is distributed to all name servers via a zone update. However, this setting was not suitable for many domains, e.g., especially dynamic domains, where the zone file is updated frequently. To accomodate for those scenarios an online signing was standardised, [RFC4470, RFC4471]. Online signing is more flexible and is already integrated into a number of DNS proxies, both proprietary and free, e.g., Secure64, PowerDNS, and an increasing number of signed zones adopt an online signing procedure. Our cipher-suite server can be integrated into an online signing proxy, without requiring any changes to the DNS software or to zone files. The configuration only requires to apply the processing of cipher-suite server to requests, prior to passing them to the online signing proxy, and then on responses from the proxy. To be able to identify which cipher corresponds to the response returned by the name server, the proxy should maintain state, between the arrival of the request, and until a response is served by the name server. The state is composed of query, TXID, source IP address, and the selected cipher, from the list sent by the client. In an offline signing, the name server has to identify the correct zone file that corresponds to the optimal negotiated cipher. Extended DNS Lookup Utility. To evaluate cipher-suite negotiation, in addition to implementation in resolvers and name servers, we also extended dig DNS lookup utility, to support cipher-suite negotiation mechanism, and to set the required cipher-suite negotiation options in EDNS0; see screen capture in Figure 5. Evaluation. We evaluated the communication overhead for signed DNS responses with transport layer cipher suite negotiation, and without. The evaluation compared the amount of bytes transmitted, Figure 6. For our evaluation we configured cipher-suite client and ciphersuite server as modules on separate hosts, such that cipher-suite client was set up on the resolver’s network and cipher-suite server on name server’s network. We added firewall rules to redirect the DNS traffic via the modules. We wrote a script that was stripping all the keys and signatures from responses of the name servers and was adding keys and signatures according to a cipher that we selected - simulating the cipher-suite selection process. Due to short keys and signatures size, we used EC cipher, and the keys and signatures were computed with an EC secret signing key that we generated for this experiment; the resolver was configured with a corresponding trust anchor, i.e., public verification key, which enabled it to establish a chain of trust and to successfully verify signatures on responses. The DNS response with the new keys and signatures was then passed to cipher-suite server, which added the signed ciphers list, set the CO bit on, and specified the selected cipher (EC) in cipher field. Cipher-suite client module captured the requests and responses from the resolver, added cipher-suite negotiation options to EDNS0, and then validated cipher-suite negotiation in responses (using the trust anchor that we configured in it especially for this experiment). We performed two series of evaluations of requests’ latency over a list of Alexa top sites and TLDs: (1) we wrote a python script that receives in an input a list of TLDs and Alexa top domains, invokes the dig utility on each domain, and measures the time between transmission of request and receipt of the response as well as the number of bytes received in the response; we used Bind-9.9.3 software to set up a recursive DNS resolver. (2) Then, to measure the impact of cipher-suite negotiation, we
DNS DNS Resolver Resolver
Cipher-Suite Cipher-Suite Client Client
Cipher-Suite Cipher-Suite Server Server A?www.foo.bar A?www.foo.bar
Name Name Server Server
A?www.foo.bar A?www.foo.bar
Add list of ciphers to EDNS
DNS request
1
A?www.foo.bar A?www.foo.bar
2
CIPHERS: 13(1),8(2),10(2)
3
4
Store ciphers list and forward to name server 1. Check CIPHER contains correct negotiated option. 2. Validate signature RRSIG over CIPHERS. 3. Forward to Resolver
DNS response
www.foo.bar www.foo.bar IN IN 1.2.3.4 1.2.3.4
CIPHERS: 13(1),8(2),10(2) CIPHER: 13(1) RRSIG: ...
www.foo.bar www.foo.bar IN IN 1.2.3.4 1.2.3.4
8
www.foo.bar www.foo.bar IN IN 1.2.3.4 1.2.3.4
7
6
5
Figure 4: Cipher-suite negotiation for DNSSEC.
dig A .www.foo.bar +dnssec +ciphers=RSASHA512(1), ECDSAP256SHA256(1), RSASHA1(2), RSAMD5(3) ; DiG 9.7.3 A www.foo.bar +dnssec +ciphers=RSASHA512(1), ECDSAP256SHA256(1), RSASHA1(2), RSAMD5(3)
;; global options: +cmd ;; Got answer: ;; ->>HEADER
