idnits 2.17.1 draft-pusateri-dhc-dns-driu-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-12 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Pusateri 3 Internet-Draft Unaffiliated 4 Intended status: Informational W. Toorop 5 Expires: January 3, 2019 NLnet Labs 6 July 2, 2018 8 DHCPv6 Options for private DNS Discovery 9 draft-pusateri-dhc-dns-driu-00 11 Abstract 13 This draft provides a series of DHCPv6 options for a DHCPv6 client to 14 request from a DHCPv6 server to aid in configuring DNS servers that 15 support private requests/responses. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 3, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DHCPv6 Encapsulating Options . . . . . . . . . . . . . . . . 3 55 4. DHCPv6 DNS over TLS Encapsulated Options . . . . . . . . . . 5 56 4.1. IPv6 Address Option . . . . . . . . . . . . . . . . . . . 5 57 4.2. ADN Option . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.3. Port Option . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. DHCPv6 DNS over DTLS Encapsulated Options . . . . . . . . . . 7 60 6. DHCPv6 DNS over HTTPS (DoH) Encapsulated Options . . . . . . 7 61 6.1. URI Option . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 10.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Appendix A. ISC DHCPv6 Configuration Example . . . . . . . . . . 11 69 A.1. ISC DHCPv6 Server Configuration . . . . . . . . . . . . . 11 70 A.2. ISC DHCPv6 Client Configuration . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 There are three standardized forms for providing privacy to DNS 76 including DNS over TLS (as defined in [RFC7858]), DNS over DTLS (as 77 defined in [RFC8094]), and DNS over HTTPS (DoH) as defined in 78 [I-D.ietf-doh-dns-over-https]. In order to use these encrypted forms 79 of DNS securely, more information is needed by the client than the 80 DNS Server list defined in Section 3 of [RFC3646]. This document 81 defines three new DHCPv6 encapsulating options containing additional 82 DHCPv6 options for clients to configure secure DNS in one of these 83 forms. Each top level option specifies ONE server. Multiple servers 84 are specified by including multiple instances of the same top level 85 option with different encapsulated options. 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Trust 95 Encrypting the DNS transport provides privacy of the information 96 contained in the DNS requests/responses across the connection. It 97 does not provide privacy at the endpoints of the connection. The 98 private DNS configuration parameters obtained by a client via DHCPv6 99 are not automatically trusted. Trust is established in many ways or 100 not at all. The environment a client finds itself in will determine 101 how trustworthy the DHCPv6 reply may or may not be. There should be 102 no false sense of privacy derived from the presence of these options 103 in a DHCPv6 reply. 105 The following points may assist the DHCPv6 client: 107 1. clients can choose whether or not to use the DNS server 108 configuration parameters they receive via DHCPv6 and may simply 109 override these parameters with their own configuration. 111 2. DHCPv6 servers already provide unencrypted DNS server parameters 112 to clients that are regularly used because the client has decided 113 to trust the server reply in that environment. 115 3. client implementations (or operating system vendors) could 116 establish whitelists (or blacklists) of known good (bad) servers. 118 4. the community could establish a registry of trusted DNS privacy 119 servers. 121 3. DHCPv6 Encapsulating Options 123 Encrypted DNS DHCPv6 configuration parameters will be encapsulated in 124 one or more of the following top level encapsulating options. These 125 options can be repeated as many times as necessary to configure a 126 list of secure DNS servers with one secure server per encapsulation. 127 This is permitted by Section 22 of [RFC3315]. There is no order 128 implied by the order of options sent or received. It is up to the 129 receiving client to determine which order to use the DNS server 130 configurations. 132 The format for the DNS over TLS [RFC7858] encapsulating option code 133 is: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | OPTION_DNS_TLS | option-length | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | | 141 . encapsulated-options (variable length) . 142 . . 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1: DNS over TLS option 147 option-code: OPTION_DNS_TLS (TBD) 149 option-len: Length of the sum of the lengths of the encapsulated 150 options. 152 The format for the DNS over DTLS [RFC8094] encapsulating option code 153 is: 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | OPTION_DNS_DTLS | option-length | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 . encapsulated-options (variable length) . 162 . . 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 2: DNS over DTLS option 167 option-code: OPTION_DNS_DTLS (TBD) 169 option-len: Length of the sum of the lengths of the encapsulated 170 options. 172 The format for the DNS over HTTPS [I-D.ietf-doh-dns-over-https] 173 encapsulating option code is: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | OPTION_DNS_HTTPS | option-length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 . encapsulated-options (variable length) . 182 . . 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 3: DNS over HTTPS option 187 option-code: OPTION_DNS_HTTPS (TBD) 189 option-len: Length of the sum of the lengths of the encapsulated 190 options. 192 4. DHCPv6 DNS over TLS Encapsulated Options 194 There are four possible DHCPv6 encapsulated options contained in a 195 top level OPTION_DNS_TLS option. Each sub-option MUST NOT appear 196 more than once within a top level option. 198 4.1. IPv6 Address Option 200 The first is an OPTION_IPV6 which is REQUIRED. This is a fixed 201 length and contains the IPv6 address of the server. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | OPTION_IPV6 | option-length (16) | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 | IPv6 address | 210 | | 211 | | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 4: IPv6 option 216 option-code: OPTION_IPV6 (TBD) 218 option-len: 16 bytes 220 4.2. ADN Option 222 The second is OPTION_ADN. This is a variable length string 223 containing the Authentication Domain Name as specified in [RFC8310]. 224 This name MUST be verified in accordance with [RFC6125] or subsequent 225 updates to this document. The client SHOULD send the Authenticated 226 Domain Name when establishing the TLS connection to the DNS server 227 using the TLS Server Name Indication (SNI) extension as defined in 228 Section 3 of [RFC6066]. The use of OPTION_ADN by the server is 229 OPTIONAL but strongly encouraged. The string is a DNS FQDN encoded 230 according to Section 3.1 of [RFC1035]. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OPTION_ADN | option-length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 . server ADN . 238 . (variable length) . 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 5: Server Name Indication option 243 option-code: OPTION_ADN (TBD) 245 option-len: Length of the encoded string 247 4.3. Port Option 249 The third option is OPTION_PORT. This is a fixed length option 250 containing the port number of the listening server. It defaults to 251 port 853 as defined in Section 3.1 of [RFC7858]. This DHCPv6 option 252 is OPTIONAL and there is no need to specify it when the server is 253 listening on port 853. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | OPTION_PORT | option-length (2) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | port number | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 6: Port option 265 option-code: OPTION_PORT (TBD) 267 option-len: 2 bytes 269 5. DHCPv6 DNS over DTLS Encapsulated Options 271 DNS over DTLS has the exact same set of possible DHCPv6 options as 272 DNS over TLS. The OPTION_IPV6 defined in Section 4.1 is REQUIRED. 273 OPTION_ADN defined in Section 4.2 is OPTIONAL. OPTION_PORT defined 274 in Section 4.3 is OPTIONAL. Please refer the these sections for 275 their definitions and descriptions. 277 6. DHCPv6 DNS over HTTPS (DoH) Encapsulated Options 279 The DNS over HTTPS top level OPTION_DNS_HTTPS encapsulation has only 280 one option defined at this time which is OPTION_URI. This option is 281 REQUIRED. 283 [[Q1: Should we allow OPTION_IPV6? --TJP]] 285 6.1. URI Option 287 OPTION_URI includes a server URI string that provides the necessary 288 components to connect to a DNS over HTTPS server as defined in 289 [I-D.ietf-doh-dns-over-https]. Note that the DNS over HTTPS 290 specification requires a server to respond to both GET and POST 291 methods. The URI MUST NOT include the query component beginning with 292 a "?" and including the "dns" variable that is used in a GET method 293 request. It is up to the client to decide whether to issue a GET or 294 POST method in the HTTP request. Therefore, the client is 295 responsible for appending the "?" and "dns" variable along with its 296 base64 encoded value to the URI for GET method HTTP requests. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | OPTION_URI | option-length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 . server URI . 304 . (variable length) . 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 7: URI option 309 option-code: OPTION_URI (TBD) 310 option-len: Length of server URI string 312 7. Security Considerations 314 Compromising domain name resolution may provide a way to direct 315 client network traffic to non-authentic service providers. Sending a 316 DNS client to a non-authentic DNS server could return DNS responses 317 with IPv6 addresses that do not represent the actual authoritative 318 AAAA records for the names queried but pretend to do so. Then 319 applications on the client computer would attempt to connect to the 320 server carrying out man-in-the-middle or trojan attacks. Before this 321 specification existed, DHCPv6 domain name servers could have directed 322 DHCPv6 clients to compromised DNS servers. Adding encrypted DNS 323 configuration parameters does not change this fact. 325 There are ways to verify the integrity of unencrypted DNS responses 326 using DNSSEC if a client begins with the root trust anchor. This 327 ensures the entire DNS root hasn't been replaced with a forgery. 329 In the same way, the integrity of the responses must still be 330 verified when the responses are received over an encrypted DNS 331 connection. 333 There are additional verification checks that can be done given the 334 additional parameters provided with these private DNS DHCPv6 options 335 to increase the likelihood a client is connecting to an authentic DNS 336 recursive resolver that are not possible if only the IPv6 address of 337 the DNS server is known: 339 1. When the ADN option is present, the client can use DNSSEC to 340 validate the address records for the DNS server and the matching 341 authentication domain name, followed by verifying the certificate 342 of the encrypted DNS Server through verification of the 343 corresponding TLSA records as described in DANE [RFC6698] and 344 updated in [RFC7671]. 346 2. There is intentionally no option for the SPKI pin as defined in 347 [RFC7469] and usage as related to DNS as described in Section 4.2 348 of [RFC7858]. This is because there is no way for a client to 349 check the integrity of the pin when received from the network 350 operator via DHCPv6. The SPKI pin can still be used to validate 351 a private DNS server certificate but the SPKI pin must be 352 obtained out of band through a trusted method to be useful for 353 verification. 355 8. IANA Considerations 357 This document identifies several new DHCPv6 Option Codes that require 358 an assigned number. 360 +------------------+-------------+-------------+ 361 | Name | Option Code | Definition | 362 +------------------+-------------+-------------+ 363 | OPTION_DNS_TLS | TBD | Section 3 | 364 | OPTION_DNS_DTLS | TBD | Section 3 | 365 | OPTION_DNS_HTTPS | TBD | Section 3 | 366 | OPTION_IPV6 | TBD | Section 4.1 | 367 | OPTION_ADN | TBD | Section 4.2 | 368 | OPTION_PORT | TBD | Section 4.3 | 369 | OPTION_URI | TBD | Section 6.1 | 370 +------------------+-------------+-------------+ 372 Table 1 374 9. Acknowledgements 376 This document was motivated in part by Section 7.3.1 of [RFC8310]. 377 Thanks to the authors Sara Dickinson, Daniel Kahn Gillmor, and 378 Tirumaleswar Reddy for documenting the issue. Thanks also to Ted 379 Lemon for appropriate warnings about this work. 381 10. References 383 10.1. Normative References 385 [I-D.ietf-doh-dns-over-https] 386 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 387 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 388 progress), June 2018. 390 [RFC1035] Mockapetris, P., "Domain names - implementation and 391 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 392 November 1987, . 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 400 C., and M. Carney, "Dynamic Host Configuration Protocol 401 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 402 2003, . 404 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 405 Extensions: Extension Definitions", RFC 6066, 406 DOI 10.17487/RFC6066, January 2011, 407 . 409 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 410 Verification of Domain-Based Application Service Identity 411 within Internet Public Key Infrastructure Using X.509 412 (PKIX) Certificates in the Context of Transport Layer 413 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 414 2011, . 416 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 417 of Named Entities (DANE) Transport Layer Security (TLS) 418 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 419 2012, . 421 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 422 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 423 2015, . 425 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 426 Authentication of Named Entities (DANE) Protocol: Updates 427 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 428 October 2015, . 430 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 431 and P. Hoffman, "Specification for DNS over Transport 432 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 433 2016, . 435 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 436 Transport Layer Security (DTLS)", RFC 8094, 437 DOI 10.17487/RFC8094, February 2017, 438 . 440 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 441 for DNS over TLS and DNS over DTLS", RFC 8310, 442 DOI 10.17487/RFC8310, March 2018, 443 . 445 10.2. Informative References 447 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 448 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 449 DOI 10.17487/RFC3646, December 2003, 450 . 452 Appendix A. ISC DHCPv6 Configuration Example 454 The DHCPv6 options defined in this specification were tested with the 455 ISC DHCPv6 server _dhcpd_ and client _dhclient_ version 4.4.1. Using 456 this version, it was possible to send a single DNS over TLS 457 encapsulated option containing an IPv6 address, authentication domain 458 name, and port number. Multiple servers using multiple DNS over TLS 459 encapsulated options were not available via the client hooks script. 461 A.1. ISC DHCPv6 Server Configuration 463 option space tls; 464 option tls.ipv6 code 226 = ip6-address; 465 option tls.port code 227 = unsigned integer 16; 466 option tls.adn code 228 = domain-list; 467 option dhcp6.tls-encapsulation code 225 = encapsulate tls; 469 subnet6 2001:DB8:01::/64 { 470 option tls.ipv6 2a04:b900:0:100::37; 471 option tls.adn "getdnsapi.net"; 473 option tls.ipv6 2620:fe::fe; 474 option tls.adn "dns.quad9.net"; 475 } 477 A.2. ISC DHCPv6 Client Configuration 479 option space tls; 480 option tls.ipv6 code 226 = ip6-address; 481 option tls.port code 227 = unsigned integer 16; 482 option tls.adn code 228 = domain-list; 483 option dhcp6.tls-encapsulation code 225 = encapsulate tls; 485 request dhcp6.tls-encapsulation; 487 Authors' Addresses 489 Tom Pusateri 490 Unaffiliated 491 Raleigh, NC 27608 492 USA 494 Phone: +1 919 867 1330 495 Email: pusateri@bangj.com 496 Willem Toorop 497 NLnet Labs 498 Science Park 400 499 Amsterdam 1098 XH 500 Netherlands 502 Email: willem@nlnetlabs.nl