idnits 2.17.1 draft-zuo-dprive-encryption-over-udp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 162 has weird spacing: '...-length for t...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2, 2015) is 3220 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 129, but not defined == Unused Reference: 'RFC1035' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC4033' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC4034' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'RFC4035' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'RFC4560' is defined on line 320, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE P. Zuo 3 Internet-Draft H. Li 4 Intended status: Informational N. Kong 5 Expires: January 3, 2016 X. Lee 6 G. Deng, Ed. 7 J. Yao, Ed. 8 N. Wang, Ed. 9 CNNIC 10 July 2, 2015 12 Approach on encrypting DNS message over UDP 13 draft-zuo-dprive-encryption-over-udp-00 15 Abstract 17 This document offers an approach to encrypt DNS queries and responses 18 between the stub resolver and the recursive server over UDP to 19 protect user privacy. The public key of the recursive server is 20 distributed to the stub resolver through the Certificate Authority 21 infrastructure, and the public key of the stub resolver is sent to 22 the recursive server together with the DNS query where the public key 23 is inserted to the additional section of the DNS query. Then the 24 recursive server encrypts the DNS responses sent to the stub resolver 25 with the public key of that stub resolver, and similarly the DNS 26 query sent to the recursive server is encrypted by the stub resolver 27 with the public key of that recursive server and thus the user 28 privacy is protected. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 3, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Protocol changes . . . . . . . . . . . . . . . . . . . . . . 3 79 2.1. Encryption flag . . . . . . . . . . . . . . . . . . . . . 3 80 2.2. Public key of the stub resolver . . . . . . . . . . . . . 4 81 2.3. Use by the stub resolver . . . . . . . . . . . . . . . . 5 82 2.4. Use by the recursive server . . . . . . . . . . . . . . . 6 83 3. Performance Considerations . . . . . . . . . . . . . . . . . 7 84 4. IANA consideration . . . . . . . . . . . . . . . . . . . . . 7 85 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 88 6.2. Informative References . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 91 1. Introduction 93 Nowadays, almost all DNS queries and responses between the stub 94 resolver and the recursive server are sent unencrypted, which makes 95 the user privacy (in terms of query names and source IPs) vulnerable 96 to attackers that has access to the network channel. Towards this 97 issue, multiple methods are proposed to protect the user privacy. 98 DNSCurve [draft-dempsky-dnscurve] defines a method to add 99 confidentiality to the link between DNS clients and servers with a 100 new cryptographic protocol; ConfidentialDNS 101 [draft-wijngaards-confidentialdns] and IPSECA 102 [draft-osterweil-dane-ipsec] use opportunistic encryption to offer 103 privacy for DNS queries and responses. Unlike these three methods, 104 DNS-over-TLS [draft-ietf-dprive-start-tls-for-dns] and DNS-over-DTLS 105 [draft-ietf-dprive-dnsodtls] use existing standard protocols such as 106 TLS and DTLS to fully encrypt the DNS queries and responses and these 107 two approaches attract much attention now. However, DNS service is 108 latency sensitive, for many other Internet applications such as web 109 browsing and E-mail begin with DNS resolution. And thus how to 110 encrypt the DNS queries and responses with low DNS latency becomes 111 one issue that needs more consideration. In this draft, one 112 encryption approach is proposed to provide fully as well as 113 opportunistic encryption for DNS queries and responses without 114 additional transmission latency. In this approach, the asymmetric 115 encryption technology is used where the stub resolver and recursive 116 server generate their own private and public keys independently. The 117 public key of the recursive server is distributed to stub resolver 118 through Certificate Authority infrastructure [RFC5280] while that of 119 the stub resolver is sent to the recursive server together with the 120 DNS query packet where a public key encapsulation method is built so 121 that the public key can be inserted into the additional section of 122 the DNS query. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2. Protocol changes 132 2.1. Encryption flag 134 To upgrade the current unencrypted DNS into encrypted one, one 135 encryption flag is needed for both stub resolver and recursive server 136 to check whether one DNS message is encrypted or not. In this draft, 137 the first octet after the Header of the DNS message is extended to be 138 one encryption flag. Specifically, if the value of the above octet 139 is not larger than 63, both the stub resolver and the recursive serve 140 process the DNS message just as usual. If the value of the first 141 octet is larger than 64 (255, for instance), the corresponding DNS 142 message is an encrypted one, which should be processed just as 143 described in the following sections. Of course, for those stub 144 resolvers and recursive servers that do not support the encryption 145 approach proposed in this draft, the encrypted DNS message should be 146 discarded. 148 2.2. Public key of the stub resolver 150 The public key of the stub resolver is appended to the RDATA part of 151 EDNS0 meta-RR as one OPTION in the DNS query sent by the stub 152 resolver to the recursive server. The encapsulation of the public 153 key is shown in figure 1. Just as defined in [RFC6891], the public 154 key is formatted into three parts, namely the option-code (16 bits), 155 option-length (16bits) and option-data (variable length) for the 156 public key. And the option-code needs to be assigned according to 157 [RFC6891]. 159 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 160 0: | option-code for the public key | 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 2: | option-length for the public key | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 4: | | 165 / option-data for the public key / 166 / / 167 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+-- 169 Figure 1. The encapsulation of the public key of stub resolver 171 The format of the option-data for the public key is shown in figure 172 2. The first 16 bits is named as Algorithm and is used to specify 173 the specific encryption algorithm that is supported. The next 16 174 bits is reserved as flag for future use. And then the last part is 175 the actet string of the corresponding public key. 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Algorithm | flag | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 / / 182 / Public Key / 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 2. The structure of the public key 187 2.3. Use by the stub resolver 189 The stub resolver can independently determine whether to encrypt the 190 DNS queries or not. If the query name is very common and not 191 relating to user privacy, the stub resolver can do name resolution 192 through traditional unencrypted way and thus does not need to 193 implement the approach proposed in this draft. While if the query 194 name relates to user privacy, the stub resolver can use the method 195 presented in this draft to encrypt the DNS queries. And accordingly, 196 the recursive server also encrypts the DNS response with the public 197 key extracted from the DNS query. 199 The process of the stub resolver encrypting the DNS query is as 200 follows. First, the stub resolver needs to configure the public key 201 of the corresponding recursive server through the current Certificate 202 Authority infrastructure [RFC5280]. Second, the stub resolver 203 generates the normal DNS query (namely unencrypted one) and then 204 extracts all the parts after the DNS query Header and encrypts them 205 with the public key of the recursive server. Third, add a prefix of 206 three octets before the encrypted content where the first octet is 207 the encryption flag just as shown in the previous section while the 208 other two octets are used to store the length of the encrypted 209 content. Fourth, append the above content (namely a three bytes of 210 prefix plus the encrypted content) to the DNS query Header and thus 211 the encrypted DNS query is formed, just as shown in figure 3. 213 If the stub resolver encrypts the DNS query, the recursive server 214 must encrypt the corresponding DNS response whose format is the same 215 as shown in figure 3. And the process of encrypting the DNS response 216 by the recursive server is shown in the following section. The 217 process of processing the DNS response at the stub resolver side is 218 as follows. First, check the Encryption flag. If it is less than 219 64, the DNS response is processed just as usual; otherwise, the DNS 220 response must be encrypted one and the corresponding decryption 221 process is as follows. First, extract the encrypted content with the 222 help of the Length field and decrypts the encrypted content with the 223 public key of the recursive server. Third, append the decrypted 224 content to the Header of the DNS response and thus the original DNS 225 response is formed. 227 The structure of the encrypted DNS query is as follows: the 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 229 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 230 / / 231 / Header / 232 / / 233 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 234 | Encryption flag | | 235 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 236 | Length | / 237 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 238 / encrypted content / 239 / / 240 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 242 Figure 3. The structure of the encrypted DNS message 244 2.4. Use by the recursive server 246 When receiving one DNS query where the Encryption flag is not larger 247 than 63, the recursive server process the DNS query just as usual. 248 While if the Encryption flag is larger than 63, the recursive server 249 can throw away the DNS query if it does not support the mechanism 250 proposed in this draft; otherwise, the recursive server processes the 251 DNS query like this: extract the encrypted content with the 252 indication of Length field shown in figure 3 and decrypts them with 253 the private key of the recursive server. Then the recursive server 254 combines the Header of the DNS query and the decrypted content and 255 thus the original DNS query is formed. Note that the public key of 256 the stub resolver is available in the decrypted DNS query and thus 257 the recursive server can obtain it easily. 259 After obtaining the original DNS query, the recursive server executes 260 normal DNS lookups and then forms the corresponding unencrypted DNS 261 response. If the DNS query received by the recursive server is 262 encrypted, then the corresponding DNS response also should be 263 encrypted. The way to encrypt the DNS response is as follows: first, 264 the recursive server encrypts all the parts of the DNS response 265 except the Header with the public key of the stub resolver. Second, 266 add a prefix of three octets to the encrypted content where one octet 267 is the encryption flag while the other two octets are for the length 268 of the encrypted content in terms of byte. Third, append above 269 content to the Header of the DNS response and thus the encrypted DNS 270 response is formed. 272 3. Performance Considerations 274 Additional DNS message transmission delay is not added by the method 275 proposed in this draft since the public key of the stub resolver is 276 inserted into the DNS query as one part of it. Higher CPU usage is 277 caused by the use of the encryption and decryption with asymmetric 278 keys. The recursive server can choose to discard the new DNS query 279 if the CPU limit is exceeded. More bandwidth is needed because the 280 DNS message is increased due to the insertion of the public key of 281 the stub resolver to the DNS query message. Also the encryption of 282 the DNS message enlarges both the DNS query and response. 284 4. IANA consideration 286 This draft extends the first octet after the Header of each DNS 287 message to indicate whether the DNS message is encrypted or not. 288 IANA is requested to assign one new value (255, for instance) for the 289 above octet as the flag of DNS message encryption. Also, IANA is 290 requested to assign the option code for the public key of the stub 291 resolver in the EDNS0 meta-RR. 293 5. Security considerations 295 The encrypted DNS message may be blocked by the middleware devices 296 such as the firewall which does not support the method proposed in 297 this draft. The recursive server becomes a bit more vulnerable due 298 to higher CPU usage caused by the encryption of DNS responses 299 especially when the DDOS attack occurs. 301 6. References 303 6.1. Normative References 305 [RFC1035] Mockapetris, P., "Domain names - implementation and 306 specification", STD 13, RFC 1035, November 1987. 308 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 309 Rose, "DNS Security Introduction and Requirements", RFC 310 4033, March 2005. 312 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 313 Rose, "Resource Records for the DNS Security Extensions", 314 RFC 4034, March 2005. 316 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 317 Rose, "Protocol Modifications for the DNS Security 318 Extensions", RFC 4035, March 2005. 320 [RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects 321 for Remote Ping, Traceroute, and Lookup Operations", RFC 322 4560, June 2006. 324 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 325 Housley, R., and W. Polk, "Internet X.509 Public Key 326 Infrastructure Certificate and Certificate Revocation List 327 (CRL) Profile", RFC 5280, May 2008. 329 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 330 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 332 6.2. Informative References 334 [draft-dempsky-dnscurve] 335 Dempsky, M., "DNSCurve: Link-Level Security for the Domain 336 Name System", August 2010, 337 . 339 [draft-ietf-dprive-dnsodtls] 340 Reddy, T., "DNS over DTLS", June 2015, 341 . 344 [draft-ietf-dprive-start-tls-for-dns] 345 Hu, Z., "TLS for DNS", May 2015, 346 . 349 [draft-osterweil-dane-ipsec] 350 Osterweil, E., "Opportunistic Encryption with DANE 351 Semantics and IPsec: IPSECA", February 2014, 352 . 355 [draft-wijngaards-confidentialdns] 356 Wijngaards, W., "Confidential DNS", March 2015, 357 . 360 Authors' Addresses 361 Peng Zuo 362 CNNIC 363 4 South 4th Street, Zhongguancun, Haidian District 364 Beijing, Beijing 100190 365 China 367 Phone: +86 10 5881 2629 368 Email: zuopeng@cnnic.cn 370 Hongtao Li 371 CNNIC 372 4 South 4th Street, Zhongguancun, Haidian District 373 Beijing, Beijing 100190 374 China 376 Phone: +86 10 5881 3164 377 Email: lihongtao@cnnic.cn 379 Ning Kong 380 CNNIC 381 4 South 4th Street, Zhongguancun, Haidian District 382 Beijing, Beijing 100190 383 China 385 Phone: +86 10 5881 3147 386 Email: xx@cnnic.cn 388 Xiaodong Lee 389 CNNIC 390 4 South 4th Street, Zhongguancun, Haidian District 391 Beijing, Beijing 100190 392 China 394 Phone: +86 10 5881 3020 395 Email: xl@cnnic.cn 397 Guangqing Deng (editor) 398 CNNIC 399 4 South 4th Street, Zhongguancun, Haidian District 400 Beijing, Beijing 100190 401 China 403 Phone: +86 10 5881 3680 404 Email: dengguangqing@cnnic.cn 405 Jiankang Yao (editor) 406 CNNIC 407 4 South 4th Street, Zhongguancun, Haidian District 408 Beijing, Beijing 100190 409 China 411 Phone: +86 10 5881 3007 412 Email: yaojiankang@cnnic.cn 414 Nan Wang (editor) 415 CNNIC 416 4 South 4th Street, Zhongguancun, Haidian District 417 Beijing, Beijing 100190 418 China 420 Phone: +86 10 5881 3275 421 Email: wangnan@cnnic.cn