idnits 2.17.00 (12 Aug 2021) /tmp/idnits34302/draft-ietf-dprive-dtls-and-tls-profiles-07.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 -- The document date (October 28, 2016) is 2031 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-dprive-dnsodtls has been published as RFC 8094 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun 4 Intended status: Standards Track D. Gillmor 5 Expires: May 1, 2017 ACLU 6 T. Reddy 7 Cisco 8 October 28, 2016 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-07 13 Abstract 15 This document discusses Usage Profiles, based on one or more 16 authentication mechanisms, which can be used for DNS over Transport 17 Layer Security (TLS) or Datagram TLS (DTLS). This document also 18 specifies new authentication mechanisms - it describes several ways a 19 DNS client can use an authentication domain name to authenticate a 20 DNS server. Additionally, it defines (D)TLS profiles for DNS clients 21 and servers implementing DNS-over-(D)TLS. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 1, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 9 63 6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 9 64 6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 9 65 6.2. Credential Verification . . . . . . . . . . . . . . . . . 10 66 6.3. Combining Authentication Mechanisms . . . . . . . . . . . 10 67 6.4. Authentication in Opportunistic Privacy . . . . . . . . . 10 68 6.5. Authentication in Strict Privacy . . . . . . . . . . . . 11 69 6.6. Implementation guidance . . . . . . . . . . . . . . . . . 11 70 7. Sources of Authentication Domain Names . . . . . . . . . . . 11 71 7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 12 72 7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 12 73 7.2.1. Full direct configuration . . . . . . . . . . . . . . 12 74 7.2.2. Direct configuration of name only . . . . . . . . . . 12 75 7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 13 76 8. Authentication Domain Name based Credential Verification . . 13 77 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 13 78 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 15 80 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 15 81 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 17 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 13.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Appendix A. Server capability probing and caching by DNS clients 20 90 Appendix B. Changes between revisions . . . . . . . . . . . . . 21 91 B.1. -07 version . . . . . . . . . . . . . . . . . . . . . . . 21 92 B.2. -06 version . . . . . . . . . . . . . . . . . . . . . . . 21 93 B.3. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21 94 B.4. -04 version . . . . . . . . . . . . . . . . . . . . . . . 22 95 B.5. -03 version . . . . . . . . . . . . . . . . . . . . . . . 22 96 B.6. -02 version . . . . . . . . . . . . . . . . . . . . . . . 22 97 B.7. -01 version . . . . . . . . . . . . . . . . . . . . . . . 22 98 B.8. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 23 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 101 1. Introduction 103 DNS Privacy issues are discussed in [RFC7626]. Two documents that 104 provide DNS privacy between DNS clients and DNS servers are: 106 o Specification for DNS over Transport Layer Security (TLS) 107 [RFC7858], referred to here as simply 'DNS-over-TLS' 109 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 110 simply as 'DNS-over-DTLS'. Note that this document has the 111 Intended status of Experimental. 113 Both documents are limited in scope to encrypting DNS messages 114 between stub clients and recursive resolvers and the same scope is 115 applied to this document (see Section 2 and Section 3). The 116 proposals here might be adapted or extended in future to be used for 117 recursive clients and authoritative servers, but this application was 118 out of scope for the Working Group charter at the time this document 119 was finished. 121 This document specifies two Usage Profiles (Strict and Opportunistic) 122 for DTLS [RFC6347] and TLS [RFC5246] which define the security 123 properties a user should expect when using that profile to connect to 124 the available DNS servers. Section 5 presents a generalised 125 discussion of Usage Profiles by separating the Usage Profile, which 126 is based purely on the security properties it offers the user, from 127 the specific mechanism(s) that are used for authentication. The 128 Profiles described are: 130 o A Strict Profile that requires an encrypted connection and 131 successful authentication of the DNS server which provides strong 132 privacy guarantees (at the expense of providing no DNS service if 133 this is not available). 135 o An Opportunistic Profile that will attempt, but does not require, 136 encryption and successful authentication; it therefore provides no 137 privacy guarantees but offers maximum chance of DNS service. 139 The above Usage Profiles attempt authentication of the server using 140 at least one authentication mechanism. Section 6.3 discusses how to 141 combine authentication mechanisms to determine the overall 142 authentication result. Depending on that overall authentication 143 result (and whether encryption is available) the Usage Profile will 144 determine if the connection should proceed, fallback or fail. 146 One authentication mechanism is already described in [RFC7858]. That 147 document specifies an SPKI based authentication mechanism for DNS- 148 over-TLS in the context of a specific case of a Strict Usage Profile 149 using that single authentication mechanism. Therefore the "Out-of- 150 band Key-pinned Privacy Profile" described in [RFC7858] would qualify 151 as a "Strict Usage Profile" that used SPKI pinning for 152 authentication. 154 This document extends the use of SPKI pinset based authentication so 155 that it is considered a general authentication mechanism that can be 156 used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI 157 pinset mechanism described in [RFC7858] MAY be used with DNS- 158 over-(D)TLS. 160 This document also describes a number of additional authentication 161 mechanisms all of which specify how a DNS client should authenticate 162 a DNS server based on an 'authentication domain name'. In 163 particular, the following is described: 165 o How a DNS client can obtain the combination of an authentication 166 domain name and IP address for a DNS server. See Section 7. 168 o What are the acceptable credentials a DNS server can present to 169 prove its identity for (D)TLS authentication based on a given 170 authentication domain name. See Section 8. 172 o How a DNS client can verify that any given credential matches the 173 authentication domain name obtained for a DNS server. See 174 Section 8. 176 In Section 9 this document defines a (D)TLS protocol profile for use 177 with DNS. This profile defines the configuration options and 178 protocol extensions required of both parties to optimize connection 179 establishment and session resumption for transporting DNS, and to 180 support all currently specified authentication mechanisms. 182 2. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. 188 Several terms are used specifically in the context of this draft: 190 o DNS client: a DNS stub resolver or forwarder. In the case of a 191 forwarder, the term "DNS client" is used to discuss the side that 192 sends queries. 194 o DNS server: a DNS recursive resolver or forwarder. In the case of 195 a forwarder, the term "DNS server" is used to discuss the side 196 that responds to queries. 198 o Privacy-enabling DNS server: A DNS server that: 200 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 201 over-DTLS [I-D.ietf-dprive-dnsodtls]. 203 * Can offer at least one of the credentials described in 204 Section 8. 206 * Implements the (D)TLS profile described in Section 9. 208 o (D)TLS: For brevity this term is used for statements that apply to 209 both Transport Layer Security [RFC5246] and Datagram Transport 210 Layer Security [RFC6347]. Specific terms will be used for any 211 statement that applies to either protocol alone. 213 o DNS-over-(D)TLS: For brevity this term is used for statements that 214 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 215 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 216 statement that applies to either protocol alone. 218 o Authentication domain name: A domain name that can be used to 219 authenticate a DNS Privacy enabling server. Sources of 220 authentication domain names are discussed in Section 7. 222 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 223 to "pin" public key information in a manner similar to HPKP 224 [RFC7469]. An SPKI pinset is a collection of these pins that 225 constrains a DNS server. 227 o Authentication information: Information a DNS client may use as 228 the basis of an authentication mechanism. In this context that 229 can be either a: 231 * a SPKI pinset or 233 * an authentication domain name 235 o Reference Identifier: a Reference Identifier as described in 236 [RFC6125], constructed by the DNS client when performing TLS 237 authentication of a DNS server. 239 o Credential: Information available for a DNS server which proves 240 its identity for authentication purposes. Credentials discussed 241 here include: 243 * PKIX certificate 245 * DNSSEC validated chain to a TLSA record 247 but may also include SPKI pinsets. 249 3. Scope 251 This document is limited to describing 253 o Usage Profiles based on general authentication mechanisms 255 o The details of domain-name-based authentication of DNS servers by 256 DNS clients (as defined in the terminology section) 258 o The (D)TLS profiles needed to support authentication in DNS- 259 over-(D)TLS. 261 As such, the following things are out of scope: 263 o Authentication of authoritative servers by recursive resolvers. 265 o Authentication of DNS clients by DNS servers. 267 o The details of how to perform SPKI-pinset-based authentication. 268 This is defined in [RFC7858]. 270 o Any server identifier other than domain names, including IP 271 address, organizational name, country of origin, etc. 273 4. Discussion 275 To protect against passive attacks DNS privacy requires encrypting 276 the query (and response). Such encryption typically provides 277 integrity protection as a side-effect, which means on-path attackers 278 cannot simply inject bogus DNS responses. For DNS privacy to also 279 provide protection against active attackers pretending to be the 280 server, the client must authenticate the server. 282 This draft discusses Usage Profiles, which provide differing levels 283 of privacy guarantees to DNS clients, based on the requirements for 284 authentication and encryption, regardless of the context (for 285 example, which network the client is connected to). A Usage Profile 286 is a distinct concept to a usage policy or usage model, which might 287 dictate which Profile should be used in a particular context 288 (enterprise vs coffee shop), with a particular set of DNS Servers or 289 with reference to other external factors. A description of the 290 variety of usage policies is out of scope of this document, but may 291 be the subject of future work. 293 5. Usage Profiles 295 A DNS client has a choice of privacy Usage Profiles available. This 296 choice is briefly discussed in both [RFC7858] and 297 [I-D.ietf-dprive-dnsodtls]. These Usage Profiles are: 299 o Strict Privacy: the DNS client requires both an encrypted and 300 authenticated connection to a privacy-enabling DNS Server. A hard 301 failure occurs if this is not available. This requires the client 302 to securely obtain authentication information it can use to 303 authenticate the server. This profile can include some initial 304 meta queries (performed using Opportunistic Privacy) to securely 305 obtain the IP address and authentication information for the 306 privacy-enabling DNS server to which the DNS client will 307 subsequently connect. The rationale for this is that requiring 308 Strict Privacy for such meta queries would introduce significant 309 deployment obstacles. This profile provides strong privacy 310 guarantees to the client. This Profile is discussed in detail in 311 Section 6.5. 313 o Opportunistic Privacy: the DNS client uses Opportunistic Security 314 as described in [RFC7435] 316 "... the use of cleartext as the baseline communication 317 security policy, with encryption and authentication negotiated 318 and applied to the communication when available." 320 The use of Opportunistic Privacy is intended to support 321 incremental deployment of security capabilities with a view to 322 widespread adoption of Strict Privacy. It should be employed when 323 the DNS client might otherwise settle for cleartext; it provides 324 the maximum protection available. As described in [RFC7435] it 325 might result in 327 * an encrypted and authenticated connection 329 * an encrypted connection 331 * a clear text connection 333 * hard failure 335 depending on the fallback logic of the client, the available 336 authentication information and the capabilities of the DNS Server. 337 In the first three cases the DNS client is willing to continue 338 with a connection to the DNS Server and perform resolution of 339 queries. 341 To compare the two Usage profiles the table below shows successful 342 Strict Privacy along side the 3 possible successful outcomes of 343 Opportunistic Privacy. In the best case scenario for Opportunistic 344 Privacy (an authenticated and encrypted connection) it is equivalent 345 to Strict Privacy. In the worst case scenario it is equivalent to 346 clear text. Clients using Opportunistic Privacy SHOULD try for the 347 best case but MAY fallback to intermediate cases and eventually the 348 worst case scenario in order to obtain a response. It therefore 349 provides no privacy guarantee to the user and varying protection 350 depending on what kind of connection is actually used. 352 Note that there is no requirement in Opportunistic Security to notify 353 the user what type of connection is actually used, the 'detection' 354 described below is only possible if such connection information is 355 available. However, if it is available and the user is informed that 356 an unencrypted connection was used to connect to a server then the 357 user should assume (detect) that the connection is subject to both 358 active and passive attack since the DNS queries are sent in clear 359 text. This might be particularly useful if a new connection to a 360 certain server is unencrypted when all previous connections were 361 encrypted. Similarly if the user is informed that an encrypted but 362 unauthenticated connection was used then user can detect that the 363 connection may be subject to active attack. This is discussed in 364 Section 6.4. 366 +---------------+------------+------------------+-----------------+ 367 | Usage Profile | Connection | Passive Attacker | Active Attacker | 368 +---------------+------------+------------------+-----------------+ 369 | Strict | A, E | P | P | 370 | Opportunistic | A, E | P | P | 371 | Opportunistic | E | P | N, D | 372 | Opportunistic | | N, D | N, D | 373 +---------------+------------+------------------+-----------------+ 375 P == protection; N == no protection; D == detection is possible; A == 376 Authenticated Connection; E == Encrypted Connection 378 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 380 Strict Privacy provides the strongest privacy guarantees and 381 therefore SHOULD always be implemented in DNS clients along with 382 Opportunistic Privacy. 384 A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to 385 the use of clear text (no privacy). 387 The choice between the two profiles depends on a number of factors 388 including which is more important to the particular client: 390 o DNS service at the cost of no privacy guarantee (Opportunistic) or 392 o guaranteed privacy at the potential cost of no DNS service 393 (Strict). 395 Additionally the two profiles require varying levels of configuration 396 (or a trusted relationship with a provider) and DNS server 397 capabilities therefore DNS clients will need to carefully select 398 which profile to use based on their communication privacy needs. 400 A DNS server that implements DNS-over-TLS SHOULD provide at least one 401 credential in order that those DNS clients that wish to do so are 402 able to use Strict Privacy (see Section 2). 404 5.1. DNS Resolution 406 A DNS client SHOULD select a particular Usage Profile when resolving 407 a query. A DNS client MUST NOT fallback from Strict Privacy to 408 Opportunistic Privacy during the resolution process as this could 409 invalidate the protection offered against active attackers. 411 6. Authentication in DNS-over(D)TLS 413 This section describes authentication mechanisms and how they can be 414 used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 416 6.1. DNS-over-(D)TLS Startup Configuration Problems 418 Many (D)TLS clients use PKIX authentication [RFC6125] based on an 419 authentication domain name for the server they are contacting. These 420 clients typically first look up the server's network address in the 421 DNS before making this connection. Such a DNS client therefore has a 422 bootstrap problem. DNS clients typically know only the IP address of 423 a DNS server. 425 In this case, before connecting to a DNS server, a DNS client needs 426 to learn the authentication domain name it should associate with the 427 IP address of a DNS server for authentication purposes. Sources of 428 authentication domains names are discussed in Section 7. 430 One advantage of this domain name based approach is that it 431 encourages association of stable, human recognisable identifiers with 432 secure DNS service providers. 434 6.2. Credential Verification 436 The use of SPKI pinset verification is discussed in [RFC7858]. 438 In terms of domain name based verification, once an authentication 439 domain name is known for a DNS server a choice of authentication 440 mechanisms can be used for credential verification. Section 8 441 discusses these mechanisms in detail, namely PKIX certificate based 442 authentication and DANE. 444 Note that the use of DANE adds requirements on the ability of the 445 client to get validated DNSSEC results. This is discussed in more 446 detail in Section 8.2. 448 6.3. Combining Authentication Mechanisms 450 This draft does not make explicit recommendations about how an SPKI 451 pinset based authentication mechanism should be combined with a 452 domain based mechanism from an operator perspective. However it can 453 be envisaged that a DNS server operator may wish to make both an SPKI 454 pinset and an authentication domain name available to allow clients 455 to choose which mechanism to use. Therefore, the following is 456 guidance on how clients ought to behave if they choose to configure 457 both, as is possible in HPKP [RFC7469]. 459 A DNS client that is configured with both an authentication domain 460 name and a SPKI pinset for a DNS server SHOULD match on both a valid 461 credential for the authentication domain name and a valid SPKI pinset 462 (if both are available) when connecting to that DNS server. The 463 overall authentication result should only be considered successful if 464 both authentication mechanisms are successful. 466 6.4. Authentication in Opportunistic Privacy 468 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 469 which MAY be used for DNS-over-(D)TLS. 471 DNS clients issuing queries under an opportunistic profile which know 472 authentication information for a given privacy-enabling DNS server 473 MAY choose to try to authenticate the server using the mechanisms 474 described here. This is useful for detecting (but not preventing) 475 active attack, since the fact that authentication information is 476 available indicates that the server in question is a privacy-enabling 477 DNS server to which it should be possible to establish an 478 authenticated, encrypted connection. In this case, whilst a client 479 cannot know the reason for an authentication failure, from a privacy 480 standpoint the client should consider an active attack in progress 481 and proceed under that assumption. Attempting authentication is also 482 useful for debugging or diagnostic purposes if there are means to 483 report the result. This information can provide a basis for a DNS 484 client to switch to (preferred) Strict Privacy where it is viable. 486 6.5. Authentication in Strict Privacy 488 To authenticate a privacy-enabling DNS server, a DNS client needs to 489 know authentication information for each server it is willing to 490 contact. This is necessary to protect against active attacks on DNS 491 privacy. 493 A DNS client requiring Strict Privacy MUST either use one of the 494 sources listed in Section 7.2 to obtain an authentication domain name 495 for the server it contacts, or use an SPKI pinset as described in 496 [RFC7858]. 498 A DNS client requiring Strict Privacy MUST only attempt to connect to 499 DNS servers for which at least on piece of authentication information 500 is known. The client MUST use the available verification mechanisms 501 described in Section 8 to authenticate the server, and MUST abort 502 connections to a server when no verification mechanism succeeds. 504 With Strict Privacy, the DNS client MUST NOT commence sending DNS 505 queries until at least one of the privacy-enabling DNS servers 506 becomes available. 508 A privacy-enabling DNS server may be temporarily unavailable when 509 configuring a network. For example, for clients on networks that 510 require registration through web-based login (a.k.a. "captive 511 portals"), such registration may rely on DNS interception and 512 spoofing. Techniques such as those used by DNSSEC-trigger 513 [dnssec-trigger] MAY be used during network configuration, with the 514 intent to transition to the designated privacy-enabling DNS servers 515 after captive portal registration. The system MUST alert by some 516 means that the DNS is not private during such bootstrap. 518 6.6. Implementation guidance 520 Section 9 describes the (D)TLS profile for DNS-over(D)TLS. 521 Additional considerations relating to general implementation 522 guidelines are discussed in both Section 11 and in Appendix A. 524 7. Sources of Authentication Domain Names 525 7.1. In Band Sources: SRV Service Label 527 This specification adds a SRV service label "domain-s" for privacy- 528 enabling DNS servers. 530 Example service records (for TLS and DTLS respectively): 532 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 533 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 535 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 537 7.2. Out of Band Sources 539 7.2.1. Full direct configuration 541 DNS clients may be directly and securely provisioned with the 542 authentication domain name of each privacy-enabling DNS server. For 543 example, using a client specific configuration file or API. 545 In this case, direct configuration for a DNS client would consist of 546 both an IP address and a domain name for each DNS server. 548 7.2.2. Direct configuration of name only 550 A DNS client may be configured directly and securely with only the 551 authentication domain name of its privacy-enabling DNS server. For 552 example, using a client specific configuration file or API. 554 A DNS client might learn of a default recursive DNS resolver from an 555 untrusted source (such as DHCP's DNS server option [RFC3646]). It 556 can then use opportunistic DNS connections to untrusted recursive DNS 557 resolver to establish the IP address of the intended privacy-enabling 558 DNS server by doing a lookup of SRV records. Such records MUST be 559 validated using DNSSEC. Private DNS resolution can now be done by 560 the DNS client against the configured privacy-enabling DNS server. 562 Example: 564 o A DNSSEC validating DNS client is configured with the domain name 565 dns.example.net for a privacy-enabling DNS server 567 o Using Opportunistic Privacy to a default DNS resolver (acquired, 568 for example, using DHCP) the client performs look ups for 570 * SRV record for _domain-s._tcp.dns.example.net to obtain the 571 server host name 573 * A and/or AAAA lookups to obtain IP address for the server host 574 name 576 o Client validates all the records obtained in the previous step 577 using DNSSEC. 579 o If the records successfully validate the client proceeds to 580 connect to the privacy-enabling DNS server using Strict Privacy. 582 A DNS client so configured that successfully connects to a privacy- 583 enabling DNS server MAY choose to locally cache the looked up 584 addresses in order to not have to repeat the opportunistic lookup. 586 7.2.3. DHCP 588 Some clients may have an established trust relationship with a known 589 DHCP [RFC2131] server for discovering their network configuration. 590 In the typical case, such a DHCP server provides a list of IP 591 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 592 not provide a domain name for the DNS server itself. 594 In the future, a DHCP server might use a DHCP extension to provide a 595 list of authentication domain names for the offered DNS servers, 596 which correspond to IP addresses listed. 598 Use of such a mechanism with any DHCP server when using an 599 Opportunistic profile is reasonable, given the security expectation 600 of that profile. However when using a Strict profile the DHCP 601 servers used as sources of authentication domain names MUST be 602 considered secure and trustworthy. This document does not attempt to 603 describe secured and trusted relationships to DHCP servers. 605 It is noted (at the time of writing) that whilst some implementation 606 work is in progress to secure IPv6 connections for DHCP, IPv4 607 connections have received little to no implementation attention in 608 this area. 610 8. Authentication Domain Name based Credential Verification 612 8.1. PKIX Certificate Based Authentication 614 When a DNS client configured with an authentication domain name 615 connects to its configured DNS server over (D)TLS, the server may 616 present it with an PKIX certificate. In order to ensure proper 617 authentication, DNS clients MUST verify the entire certification path 618 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 619 techniques to compare the domain name to the certificate provided. 621 A DNS client constructs two Reference Identifiers for the server 622 based on the authentication domain name: A DNS-ID and an SRV-ID 623 [RFC4985]. The DNS-ID is simply the authentication domain name 624 itself. The SRV-ID uses a "_domain-s." prefix. So if the configured 625 authentication domain name is "dns.example.com", then the two 626 Reference Identifiers are: 628 DNS-ID: dns.example.com 630 SRV-ID: _domain-s.dns.example.com 632 If either of the Reference Identifiers are found in the PKIX 633 certificate's subjectAltName extension as described in section 6 of 634 [RFC6125], the DNS client should accept the certificate for the 635 server. 637 A compliant DNS client MUST only inspect the certificate's 638 subjectAltName extension for these Reference Identifiers. In 639 particular, it MUST NOT inspect the Subject field itself. 641 8.2. DANE 643 DANE [RFC6698] provides mechanisms to root certificate and raw public 644 key trust with DNSSEC. However this requires the DNS client to have 645 an authentication domain name for the DNS Privacy Server which must 646 be obtained via a trusted source. 648 This section assumes a solid understanding of both DANE [RFC6698] and 649 DANE Operations [RFC7671]. A few pertinent issues covered in these 650 documents are outlined here as useful pointers, but familiarity with 651 both these documents in their entirety is expected. 653 It is noted that [RFC6698] says 655 "Clients that validate the DNSSEC signatures themselves MUST use 656 standard DNSSEC validation procedures. Clients that rely on 657 another entity to perform the DNSSEC signature validation MUST use 658 a secure mechanism between themselves and the validator." 660 It is noted that [RFC7671] covers the following topics: 662 o Section 4.1: Opportunistic Security and PKIX Usages and 663 Section 14: Security Considerations, which both discuss the use of 664 PKIX-TA(0) and PKIX-EE(1) for OS. 666 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 667 Specifically Section 5.1 which outlines the combination of 668 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 669 Public Keys [RFC7250]. Section 5.1 also discusses the security 670 implications of this mode, for example, it discusses key lifetimes 671 and specifies that validity period enforcement is based solely on 672 the TLSA RRset properties for this case. [QUESTION: Should an 673 appendix be added with an example of how to use DANE without PKIX 674 certificates?] 676 o Section 13: Operational Considerations, which discusses TLSA TTLs 677 and signature validity periods. 679 The specific DANE record for a DNS Privacy Server would take the 680 form: 682 _853._tcp.[server-domain-name] for TLS 684 _853._udp.[server-domain-name] for DTLS 686 8.2.1. Direct DNS Lookup 688 The DNS client MAY choose to perform the DNS lookups to retrieve the 689 required DANE records itself. The DNS queries for such DANE records 690 MAY use opportunistic encryption or be in the clear to avoid trust 691 recursion. The records MUST be validated using DNSSEC as described 692 above in [RFC6698]. 694 8.2.2. TLS DNSSEC Chain extension 696 The DNS client MAY offer the TLS extension described in 697 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 698 this extension, it can provide the full chain to the client in the 699 handshake. 701 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 702 capable of validating the full DNSSEC authentication chain down to 703 the leaf. If the supplied DNSSEC chain does not validate, the client 704 MUST ignore the DNSSEC chain and validate only via other supplied 705 credentials. 707 9. (D)TLS Protocol Profile 709 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 711 There are known attacks on (D)TLS, such as machine-in-the-middle and 712 protocol downgrade. These are general attacks on (D)TLS and not 713 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 714 discussion of these security issues. 716 Clients and servers MUST adhere to the (D)TLS implementation 717 recommendations and security considerations of [RFC7525] except with 718 respect to (D)TLS version. 720 Since encryption of DNS using (D)TLS is virtually a green-field 721 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 722 later. 724 Implementations MUST NOT offer or provide TLS compression, since 725 compression can leak significant amounts of information, especially 726 to a network observer capable of forcing the user to do an arbitrary 727 DNS lookup in the style of the CRIME attacks [CRIME]. 729 Implementations compliant with this profile MUST implement all of the 730 following items: 732 o TLS session resumption without server-side state [RFC5077] which 733 eliminates the need for the server to retain cryptographic state 734 for longer than necessary. 736 o Raw public keys [RFC7250] which reduce the size of the 737 ServerHello, and can be used by servers that cannot obtain 738 certificates (e.g., DNS servers on private networks). 740 Implementations compliant with this profile SHOULD implement all of 741 the following items: 743 o TLS False Start [RFC7918] which reduces round-trips by allowing 744 the TLS second flight of messages (ChangeCipherSpec) to also 745 contain the (encrypted) DNS query 747 o Cached Information Extension [RFC7924] which avoids transmitting 748 the server's certificate and certificate chain if the client has 749 cached that information from a previous TLS handshake 751 Guidance specific to TLS is provided in [RFC7858] and that specific 752 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 754 10. IANA Considerations 756 This memo includes no request to IANA. 758 11. Security Considerations 760 Security considerations discussed in [RFC7525], 761 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 763 11.1. Counter-measures to DNS Traffic Analysis 765 This section makes suggestions for measures that can reduce the 766 ability of attackers to infer information pertaining to encrypted 767 client queries by other means (e.g. via an analysis of encrypted 768 traffic size, or via monitoring of resolver to authoritative 769 traffic). 771 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 772 following relevant DNS extensions 774 o EDNS(0) padding [RFC7830], which allows encrypted queries and 775 responses to hide their size. 777 DNS-over-(D)TLS clients SHOULD consider implementing the following 778 relevant DNS extensions 780 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 781 a DNS client does not include an EDNS0 Client Subnet Option with a 782 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 783 potentially leak client address information to the upstream 784 authoritative DNS servers. A DNS client ought to be able to 785 inform the DNS Resolver that it does not want any address 786 information leaked, and the DNS Resolver should honor that 787 request. 789 12. Acknowledgements 791 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 792 [RFC7858] for laying the ground work that this draft builds on and 793 for reviewing the contents. The authors would also like to thank 794 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 795 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and 796 Christian Huitema for review and discussion of the ideas presented 797 here. 799 13. References 801 13.1. Normative References 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, 805 DOI 10.17487/RFC2119, March 1997, 806 . 808 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 809 Subject Alternative Name for Expression of Service Name", 810 RFC 4985, DOI 10.17487/RFC4985, August 2007, 811 . 813 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 814 "Transport Layer Security (TLS) Session Resumption without 815 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 816 January 2008, . 818 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 819 (TLS) Protocol Version 1.2", RFC 5246, 820 DOI 10.17487/RFC5246, August 2008, 821 . 823 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 824 Housley, R., and W. Polk, "Internet X.509 Public Key 825 Infrastructure Certificate and Certificate Revocation List 826 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 827 . 829 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 830 Verification of Domain-Based Application Service Identity 831 within Internet Public Key Infrastructure Using X.509 832 (PKIX) Certificates in the Context of Transport Layer 833 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 834 2011, . 836 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 837 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 838 January 2012, . 840 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 841 of Named Entities (DANE) Transport Layer Security (TLS) 842 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 843 2012, . 845 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 846 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 847 Transport Layer Security (TLS) and Datagram Transport 848 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 849 June 2014, . 851 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 852 "Recommendations for Secure Use of Transport Layer 853 Security (TLS) and Datagram Transport Layer Security 854 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 855 2015, . 857 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 858 Authentication of Named Entities (DANE) Protocol: Updates 859 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 860 October 2015, . 862 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 863 DOI 10.17487/RFC7830, May 2016, 864 . 866 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 867 and P. Hoffman, "Specification for DNS over Transport 868 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 869 2016, . 871 13.2. Informative References 873 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 875 [dnssec-trigger] 876 NLnetLabs, "Dnssec-Trigger", May 2014, 877 . 879 [I-D.ietf-dprive-dnsodtls] 880 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 881 over Datagram Transport Layer Security (DTLS)", draft- 882 ietf-dprive-dnsodtls-12 (work in progress), September 883 2016. 885 [I-D.ietf-tls-dnssec-chain-extension] 886 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 887 Record and DNSSEC Authentication Chain Extension for TLS", 888 draft-ietf-tls-dnssec-chain-extension-01 (work in 889 progress), July 2016. 891 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 892 RFC 2131, DOI 10.17487/RFC2131, March 1997, 893 . 895 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 896 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 897 . 899 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 900 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 901 DOI 10.17487/RFC3646, December 2003, 902 . 904 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 905 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 906 December 2014, . 908 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 909 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 910 2015, . 912 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 913 DOI 10.17487/RFC7626, August 2015, 914 . 916 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 917 Kumari, "Client Subnet in DNS Queries", RFC 7871, 918 DOI 10.17487/RFC7871, May 2016, 919 . 921 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 922 Layer Security (TLS) False Start", RFC 7918, 923 DOI 10.17487/RFC7918, August 2016, 924 . 926 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 927 (TLS) Cached Information Extension", RFC 7924, 928 DOI 10.17487/RFC7924, July 2016, 929 . 931 Appendix A. Server capability probing and caching by DNS clients 933 This section presents a non-normative discussion of how DNS clients 934 might probe for and cache privacy capabilities of DNS servers. 936 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 937 Not all servers will support one or both of these protocols and the 938 well-known port might be blocked by some middleboxes. Clients will 939 be expected to keep track of servers that support DNS-over-TLS and/or 940 DNS-over-DTLS, and those that have been previously authenticated. 942 If no server capability information is available then (unless 943 otherwise specified by the configuration of the DNS client) DNS 944 clients that implement both TLS and DTLS should try to authenticate 945 using both protocols before failing or falling back to a lower 946 security. DNS clients using opportunistic security should try all 947 available servers (possibly in parallel) in order to obtain an 948 authenticated encrypted connection before falling back to a lower 949 security. (RATIONALE: This approach can increase latency while 950 discovering server capabilities but maximizes the chance of sending 951 the query over an authenticated encrypted connection.) 953 Appendix B. Changes between revisions 955 [Note to RFC Editor: please remove this section prior to 956 publication.] 958 B.1. -07 version 960 Re-work of the Abstract and Introduction to better describe the 961 contents in this version. 963 Terminology: New definition of 'authentication information'. 965 Scope: Changes to the Scope section. 967 Moved discussion of combining authentication mechanism earlier. 969 Changes to the section headings and groupings to make the 970 presentation more logical. 972 B.2. -06 version 974 Introduction: Re-word discussion of Working group charter. 976 Introduction: Re-word first and third bullet point about 'obtaining' 977 a domain name and IP address. 979 Introduction: Update reference to DNS-over-TLS draft. 981 Terminology: Change forwarder/proxy to just forwarder 983 Terminology: Add definition of 'Authentication domain name' and use 984 this throughout 986 Section 4.2: Remove parenthesis in the table. 988 Section 4.2: Change the text after the table as agreed with Paul 989 Hoffman. 991 Section 4.3.1: Change title and remove brackets around last 992 statement. 994 Section 11: Split second paragraph. 996 B.3. -05 version 998 Add more details on detecting passive attacks to section 4.2 1000 Changed X.509 to PKIX throughout 1001 Change comment about future I-D on usage policies. 1003 B.4. -04 version 1005 Introduction: Add comment that DNS-over-DTLS draft is Experiments 1007 Update 2 I-D references to RFCs. 1009 B.5. -03 version 1011 Section 9: Update DANE section with better references to RFC7671 and 1012 RFC7250 1014 B.6. -02 version 1016 Introduction: Added paragraph on the background and scope of the 1017 document. 1019 Introduction and Discussion: Added more information on what a Usage 1020 profiles is (and is not) the the two presented here. 1022 Introduction: Added paragraph to make a comparison with the Strict 1023 profile in RFC7858 clearer. 1025 Section 4.2: Re-worked the description of Opportunistic and the 1026 table. 1028 Section 8.3: Clarified statement about use of DHCP in Opportunistic 1029 profile 1031 Title abbreviated. 1033 B.7. -01 version 1035 Section 4.2: Make clear that the Strict Privacy Profile can include 1036 meta queries performed using Opportunistic Privacy. 1038 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 1039 does not guarantee protection against passive attack. 1041 Section 4.2: Add sentence discussing client/provider trusted 1042 relationships. 1044 Section 5: Add more discussion of detection of active attacks when 1045 using Opportunistic Privacy. 1047 Section 8.2: Clarify description and example. 1049 B.8. draft-ietf-dprive-dtls-and-tls-profiles-00 1051 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1052 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1053 fixed. 1055 Authors' Addresses 1057 Sara Dickinson 1058 Sinodun Internet Technologies 1059 Magdalen Centre 1060 Oxford Science Park 1061 Oxford OX4 4GA 1062 UK 1064 Email: sara@sinodun.com 1065 URI: http://sinodun.com 1067 Daniel Kahn Gillmor 1068 ACLU 1069 125 Broad Street, 18th Floor 1070 New York NY 10004 1071 USA 1073 Email: dkg@fifthhorseman.net 1075 Tirumaleswar Reddy 1076 Cisco Systems, Inc. 1077 Cessna Business Park, Varthur Hobli 1078 Sarjapur Marathalli Outer Ring Road 1079 Bangalore, Karnataka 560103 1080 India 1082 Email: tireddy@cisco.com