DPRIVE P. Zuo Internet-Draft H. Li Intended status: Informational N. Kong Expires: January 3, 2016 X. Lee G. Deng, Ed. J. Yao, Ed. N. Wang, Ed. CNNIC July 2, 2015 Approach on encrypting DNS message over UDP draft-zuo-dprive-encryption-over-udp-00 Abstract This document offers an approach to encrypt DNS queries and responses between the stub resolver and the recursive server over UDP to protect user privacy. The public key of the recursive server is distributed to the stub resolver through the Certificate Authority infrastructure, and the public key of the stub resolver is sent to the recursive server together with the DNS query where the public key is inserted to the additional section of the DNS query. Then the recursive server encrypts the DNS responses sent to the stub resolver with the public key of that stub resolver, and similarly the DNS query sent to the recursive server is encrypted by the stub resolver with the public key of that recursive server and thus the user privacy is protected. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 3, 2016. Zuo, et al. Expires January 3, 2016 [Page 1] Internet-Draft dns encryption over UDP July 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol changes . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Encryption flag . . . . . . . . . . . . . . . . . . . . . 3 2.2. Public key of the stub resolver . . . . . . . . . . . . . 4 2.3. Use by the stub resolver . . . . . . . . . . . . . . . . 5 2.4. Use by the recursive server . . . . . . . . . . . . . . . 6 3. Performance Considerations . . . . . . . . . . . . . . . . . 7 4. IANA consideration . . . . . . . . . . . . . . . . . . . . . 7 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Zuo, et al. Expires January 3, 2016 [Page 2] Internet-Draft dns encryption over UDP July 2015 1. Introduction Nowadays, almost all DNS queries and responses between the stub resolver and the recursive server are sent unencrypted, which makes the user privacy (in terms of query names and source IPs) vulnerable to attackers that has access to the network channel. Towards this issue, multiple methods are proposed to protect the user privacy. DNSCurve [draft-dempsky-dnscurve] defines a method to add confidentiality to the link between DNS clients and servers with a new cryptographic protocol; ConfidentialDNS [draft-wijngaards-confidentialdns] and IPSECA [draft-osterweil-dane-ipsec] use opportunistic encryption to offer privacy for DNS queries and responses. Unlike these three methods, DNS-over-TLS [draft-ietf-dprive-start-tls-for-dns] and DNS-over-DTLS [draft-ietf-dprive-dnsodtls] use existing standard protocols such as TLS and DTLS to fully encrypt the DNS queries and responses and these two approaches attract much attention now. However, DNS service is latency sensitive, for many other Internet applications such as web browsing and E-mail begin with DNS resolution. And thus how to encrypt the DNS queries and responses with low DNS latency becomes one issue that needs more consideration. In this draft, one encryption approach is proposed to provide fully as well as opportunistic encryption for DNS queries and responses without additional transmission latency. In this approach, the asymmetric encryption technology is used where the stub resolver and recursive server generate their own private and public keys independently. The public key of the recursive server is distributed to stub resolver through Certificate Authority infrastructure [RFC5280] while that of the stub resolver is sent to the recursive server together with the DNS query packet where a public key encapsulation method is built so that the public key can be inserted into the additional section of the DNS query. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Protocol changes 2.1. Encryption flag To upgrade the current unencrypted DNS into encrypted one, one encryption flag is needed for both stub resolver and recursive server to check whether one DNS message is encrypted or not. In this draft, the first octet after the Header of the DNS message is extended to be one encryption flag. Specifically, if the value of the above octet Zuo, et al. Expires January 3, 2016 [Page 3] Internet-Draft dns encryption over UDP July 2015 is not larger than 63, both the stub resolver and the recursive serve process the DNS message just as usual. If the value of the first octet is larger than 64 (255, for instance), the corresponding DNS message is an encrypted one, which should be processed just as described in the following sections. Of course, for those stub resolvers and recursive servers that do not support the encryption approach proposed in this draft, the encrypted DNS message should be discarded. 2.2. Public key of the stub resolver The public key of the stub resolver is appended to the RDATA part of EDNS0 meta-RR as one OPTION in the DNS query sent by the stub resolver to the recursive server. The encapsulation of the public key is shown in figure 1. Just as defined in [RFC6891], the public key is formatted into three parts, namely the option-code (16 bits), option-length (16bits) and option-data (variable length) for the public key. And the option-code needs to be assigned according to [RFC6891]. +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | option-code for the public key | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: | option-length for the public key | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4: | | / option-data for the public key / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- Figure 1. The encapsulation of the public key of stub resolver The format of the option-data for the public key is shown in figure 2. The first 16 bits is named as Algorithm and is used to specify the specific encryption algorithm that is supported. The next 16 bits is reserved as flag for future use. And then the last part is the actet string of the corresponding public key. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Public Key / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. The structure of the public key Zuo, et al. Expires January 3, 2016 [Page 4] Internet-Draft dns encryption over UDP July 2015 2.3. Use by the stub resolver The stub resolver can independently determine whether to encrypt the DNS queries or not. If the query name is very common and not relating to user privacy, the stub resolver can do name resolution through traditional unencrypted way and thus does not need to implement the approach proposed in this draft. While if the query name relates to user privacy, the stub resolver can use the method presented in this draft to encrypt the DNS queries. And accordingly, the recursive server also encrypts the DNS response with the public key extracted from the DNS query. The process of the stub resolver encrypting the DNS query is as follows. First, the stub resolver needs to configure the public key of the corresponding recursive server through the current Certificate Authority infrastructure [RFC5280]. Second, the stub resolver generates the normal DNS query (namely unencrypted one) and then extracts all the parts after the DNS query Header and encrypts them with the public key of the recursive server. Third, add a prefix of three octets before the encrypted content where the first octet is the encryption flag just as shown in the previous section while the other two octets are used to store the length of the encrypted content. Fourth, append the above content (namely a three bytes of prefix plus the encrypted content) to the DNS query Header and thus the encrypted DNS query is formed, just as shown in figure 3. If the stub resolver encrypts the DNS query, the recursive server must encrypt the corresponding DNS response whose format is the same as shown in figure 3. And the process of encrypting the DNS response by the recursive server is shown in the following section. The process of processing the DNS response at the stub resolver side is as follows. First, check the Encryption flag. If it is less than 64, the DNS response is processed just as usual; otherwise, the DNS response must be encrypted one and the corresponding decryption process is as follows. First, extract the encrypted content with the help of the Length field and decrypts the encrypted content with the public key of the recursive server. Third, append the decrypted content to the Header of the DNS response and thus the original DNS response is formed. The structure of the encrypted DNS query is as follows: the Zuo, et al. Expires January 3, 2016 [Page 5] Internet-Draft dns encryption over UDP July 2015 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / / / Header / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Encryption flag | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Length | / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / encrypted content / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Figure 3. The structure of the encrypted DNS message 2.4. Use by the recursive server When receiving one DNS query where the Encryption flag is not larger than 63, the recursive server process the DNS query just as usual. While if the Encryption flag is larger than 63, the recursive server can throw away the DNS query if it does not support the mechanism proposed in this draft; otherwise, the recursive server processes the DNS query like this: extract the encrypted content with the indication of Length field shown in figure 3 and decrypts them with the private key of the recursive server. Then the recursive server combines the Header of the DNS query and the decrypted content and thus the original DNS query is formed. Note that the public key of the stub resolver is available in the decrypted DNS query and thus the recursive server can obtain it easily. After obtaining the original DNS query, the recursive server executes normal DNS lookups and then forms the corresponding unencrypted DNS response. If the DNS query received by the recursive server is encrypted, then the corresponding DNS response also should be encrypted. The way to encrypt the DNS response is as follows: first, the recursive server encrypts all the parts of the DNS response except the Header with the public key of the stub resolver. Second, add a prefix of three octets to the encrypted content where one octet is the encryption flag while the other two octets are for the length of the encrypted content in terms of byte. Third, append above content to the Header of the DNS response and thus the encrypted DNS response is formed. Zuo, et al. Expires January 3, 2016 [Page 6] Internet-Draft dns encryption over UDP July 2015 3. Performance Considerations Additional DNS message transmission delay is not added by the method proposed in this draft since the public key of the stub resolver is inserted into the DNS query as one part of it. Higher CPU usage is caused by the use of the encryption and decryption with asymmetric keys. The recursive server can choose to discard the new DNS query if the CPU limit is exceeded. More bandwidth is needed because the DNS message is increased due to the insertion of the public key of the stub resolver to the DNS query message. Also the encryption of the DNS message enlarges both the DNS query and response. 4. IANA consideration This draft extends the first octet after the Header of each DNS message to indicate whether the DNS message is encrypted or not. IANA is requested to assign one new value (255, for instance) for the above octet as the flag of DNS message encryption. Also, IANA is requested to assign the option code for the public key of the stub resolver in the EDNS0 meta-RR. 5. Security considerations The encrypted DNS message may be blocked by the middleware devices such as the firewall which does not support the method proposed in this draft. The recursive server becomes a bit more vulnerable due to higher CPU usage caused by the encryption of DNS responses especially when the DDOS attack occurs. 6. References 6.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Zuo, et al. Expires January 3, 2016 [Page 7] Internet-Draft dns encryption over UDP July 2015 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 6.2. Informative References [draft-dempsky-dnscurve] Dempsky, M., "DNSCurve: Link-Level Security for the Domain Name System", August 2010, . [draft-ietf-dprive-dnsodtls] Reddy, T., "DNS over DTLS", June 2015, . [draft-ietf-dprive-start-tls-for-dns] Hu, Z., "TLS for DNS", May 2015, . [draft-osterweil-dane-ipsec] Osterweil, E., "Opportunistic Encryption with DANE Semantics and IPsec: IPSECA", February 2014, . [draft-wijngaards-confidentialdns] Wijngaards, W., "Confidential DNS", March 2015, . Authors' Addresses Zuo, et al. Expires January 3, 2016 [Page 8] Internet-Draft dns encryption over UDP July 2015 Peng Zuo CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 2629 Email: zuopeng@cnnic.cn Hongtao Li CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3164 Email: lihongtao@cnnic.cn Ning Kong CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 Email: xx@cnnic.cn Xiaodong Lee CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3020 Email: xl@cnnic.cn Guangqing Deng (editor) CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3680 Email: dengguangqing@cnnic.cn Zuo, et al. Expires January 3, 2016 [Page 9] Internet-Draft dns encryption over UDP July 2015 Jiankang Yao (editor) CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3007 Email: yaojiankang@cnnic.cn Nan Wang (editor) CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3275 Email: wangnan@cnnic.cn Zuo, et al. Expires January 3, 2016 [Page 10]