idnits 2.17.00 (12 Aug 2021) /tmp/idnits24765/draft-ietf-dprive-dtls-and-tls-profiles-08.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 (January 18, 2017) is 1948 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-02 -- 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: July 22, 2017 ACLU 6 T. Reddy 7 Cisco 8 January 18, 2017 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-08 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 July 22, 2017. 40 Copyright Notice 42 Copyright (c) 2017 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. Summary of Authentication Mechanisms . . . . . . . . . . 10 67 6.4. Combining Authentication Mechanisms . . . . . . . . . . . 13 68 6.5. Authentication in Opportunistic Privacy . . . . . . . . . 13 69 6.6. Authentication in Strict Privacy . . . . . . . . . . . . 13 70 6.7. Implementation guidance . . . . . . . . . . . . . . . . . 14 71 7. Sources of Authentication Domain Names . . . . . . . . . . . 14 72 7.1. In Band Sources: SRV Service Label . . . . . . . . . . . 14 73 7.2. Out of Band Sources . . . . . . . . . . . . . . . . . . . 15 74 7.2.1. Full direct configuration . . . . . . . . . . . . . . 15 75 7.2.2. Direct configuration of name only . . . . . . . . . . 15 76 7.2.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8. Authentication Domain Name based Credential Verification . . 16 78 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 16 79 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 18 81 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 18 82 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 18 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 19 86 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 13.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Appendix A. Server capability probing and caching by DNS clients 23 91 Appendix B. Changes between revisions . . . . . . . . . . . . . 23 92 B.1. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23 93 B.2. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23 94 B.3. -06 version . . . . . . . . . . . . . . . . . . . . . . . 24 95 B.4. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24 96 B.5. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24 97 B.6. -03 version . . . . . . . . . . . . . . . . . . . . . . . 25 98 B.7. -02 version . . . . . . . . . . . . . . . . . . . . . . . 25 99 B.8. -01 version . . . . . . . . . . . . . . . . . . . . . . . 25 100 B.9. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 DNS Privacy issues are discussed in [RFC7626]. Two documents that 106 provide DNS privacy between DNS clients and DNS servers are: 108 o Specification for DNS over Transport Layer Security (TLS) 109 [RFC7858], referred to here as simply 'DNS-over-TLS' 111 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 112 simply as 'DNS-over-DTLS'. Note that this document has the 113 Intended status of Experimental. 115 Both documents are limited in scope to encrypting DNS messages 116 between stub clients and recursive resolvers and the same scope is 117 applied to this document (see Section 2 and Section 3). The 118 proposals here might be adapted or extended in future to be used for 119 recursive clients and authoritative servers, but this application was 120 out of scope for the Working Group charter at the time this document 121 was finished. 123 This document specifies two Usage Profiles (Strict and Opportunistic) 124 for DTLS [RFC6347] and TLS [RFC5246] which define the security 125 properties a user should expect when using that profile to connect to 126 the available DNS servers. Section 5 presents a generalised 127 discussion of Usage Profiles by separating the Usage Profile, which 128 is based purely on the security properties it offers the user, from 129 the specific mechanism(s) that are used for authentication. The 130 Profiles described are: 132 o A Strict Profile that requires an encrypted connection and 133 successful authentication of the DNS server which provides strong 134 privacy guarantees (at the expense of providing no DNS service if 135 this is not available). 137 o An Opportunistic Profile that will attempt, but does not require, 138 encryption and successful authentication; it therefore provides no 139 privacy guarantees but offers maximum chance of DNS service. 141 The above Usage Profiles attempt authentication of the server using 142 at least one authentication mechanism. Section 6.4 discusses how to 143 combine authentication mechanisms to determine the overall 144 authentication result. Depending on that overall authentication 145 result (and whether encryption is available) the Usage Profile will 146 determine if the connection should proceed, fallback or fail. 148 One authentication mechanism is already described in [RFC7858]. That 149 document specifies an SPKI based authentication mechanism for DNS- 150 over-TLS in the context of a specific case of a Strict Usage Profile 151 using that single authentication mechanism. Therefore the "Out-of- 152 band Key-pinned Privacy Profile" described in [RFC7858] would qualify 153 as a "Strict Usage Profile" that used SPKI pinning for 154 authentication. 156 This document extends the use of SPKI pinset based authentication so 157 that it is considered a general authentication mechanism that can be 158 used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI 159 pinset mechanism described in [RFC7858] MAY be used with DNS- 160 over-(D)TLS. 162 This document also describes a number of additional authentication 163 mechanisms all of which specify how a DNS client should authenticate 164 a DNS server based on an 'authentication domain name'. In 165 particular, the following is described: 167 o How a DNS client can obtain the combination of an authentication 168 domain name and IP address for a DNS server. See Section 7. 170 o What are the acceptable credentials a DNS server can present to 171 prove its identity for (D)TLS authentication based on a given 172 authentication domain name. See Section 8. 174 o How a DNS client can verify that any given credential matches the 175 authentication domain name obtained for a DNS server. See 176 Section 8. 178 In Section 9 this document defines a (D)TLS protocol profile for use 179 with DNS. This profile defines the configuration options and 180 protocol extensions required of both parties to optimize connection 181 establishment and session resumption for transporting DNS, and to 182 support all currently specified authentication mechanisms. 184 2. Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in [RFC2119]. 190 Several terms are used specifically in the context of this draft: 192 o DNS client: a DNS stub resolver or forwarder. In the case of a 193 forwarder, the term "DNS client" is used to discuss the side that 194 sends queries. 196 o DNS server: a DNS recursive resolver or forwarder. In the case of 197 a forwarder, the term "DNS server" is used to discuss the side 198 that responds to queries. 200 o Privacy-enabling DNS server: A DNS server that: 202 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 203 over-DTLS [I-D.ietf-dprive-dnsodtls]. 205 * Can offer at least one of the credentials described in 206 Section 8. 208 * Implements the (D)TLS profile described in Section 9. 210 o (D)TLS: For brevity this term is used for statements that apply to 211 both Transport Layer Security [RFC5246] and Datagram Transport 212 Layer Security [RFC6347]. Specific terms will be used for any 213 statement that applies to either protocol alone. 215 o DNS-over-(D)TLS: For brevity this term is used for statements that 216 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 217 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 218 statement that applies to either protocol alone. 220 o Authentication domain name: A domain name that can be used to 221 authenticate a DNS Privacy enabling server. Sources of 222 authentication domain names are discussed in Section 7. 224 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 225 to "pin" public key information in a manner similar to HPKP 226 [RFC7469]. An SPKI pinset is a collection of these pins that 227 constrains a DNS server. 229 o Authentication information: Information a DNS client may use as 230 the basis of an authentication mechanism. In this context that 231 can be either a: 233 * a SPKI pinset or 235 * an authentication domain name 237 o Reference Identifier: a Reference Identifier as described in 238 [RFC6125], constructed by the DNS client when performing TLS 239 authentication of a DNS server. 241 o Credential: Information available for a DNS server which proves 242 its identity for authentication purposes. Credentials discussed 243 here include: 245 * PKIX certificate 247 * DNSSEC validated chain to a TLSA record 249 but may also include SPKI pinsets. 251 3. Scope 253 This document is limited to describing 255 o Usage Profiles based on general authentication mechanisms 257 o The details of domain-name-based authentication of DNS servers by 258 DNS clients (as defined in the terminology section) 260 o The (D)TLS profiles needed to support authentication in DNS- 261 over-(D)TLS. 263 As such, the following things are out of scope: 265 o Authentication of authoritative servers by recursive resolvers. 267 o Authentication of DNS clients by DNS servers. 269 o The details of how to perform SPKI-pinset-based authentication. 270 This is defined in [RFC7858]. 272 o Any server identifier other than domain names, including IP 273 address, organizational name, country of origin, etc. 275 4. Discussion 277 To protect against passive attacks DNS privacy requires encrypting 278 the query (and response). Such encryption typically provides 279 integrity protection as a side-effect, which means on-path attackers 280 cannot simply inject bogus DNS responses. For DNS privacy to also 281 provide protection against active attackers pretending to be the 282 server, the client must authenticate the server. 284 This draft discusses Usage Profiles, which provide differing levels 285 of privacy guarantees to DNS clients, based on the requirements for 286 authentication and encryption, regardless of the context (for 287 example, which network the client is connected to). A Usage Profile 288 is a distinct concept to a usage policy or usage model, which might 289 dictate which Profile should be used in a particular context 290 (enterprise vs coffee shop), with a particular set of DNS Servers or 291 with reference to other external factors. A description of the 292 variety of usage policies is out of scope of this document, but may 293 be the subject of future work. 295 5. Usage Profiles 297 A DNS client has a choice of privacy Usage Profiles available. This 298 choice is briefly discussed in both [RFC7858] and 299 [I-D.ietf-dprive-dnsodtls]. These Usage Profiles are: 301 o Strict Privacy: the DNS client requires both an encrypted and 302 authenticated connection to a privacy-enabling DNS Server. A hard 303 failure occurs if this is not available. This requires the client 304 to securely obtain authentication information it can use to 305 authenticate the server. This profile can include some initial 306 meta queries (performed using Opportunistic Privacy) to securely 307 obtain the IP address and authentication information for the 308 privacy-enabling DNS server to which the DNS client will 309 subsequently connect. The rationale for this is that requiring 310 Strict Privacy for such meta queries would introduce significant 311 deployment obstacles. This profile provides strong privacy 312 guarantees to the client. This Profile is discussed in detail in 313 Section 6.6. 315 o Opportunistic Privacy: the DNS client uses Opportunistic Security 316 as described in [RFC7435] 318 "... the use of cleartext as the baseline communication 319 security policy, with encryption and authentication negotiated 320 and applied to the communication when available." 322 The use of Opportunistic Privacy is intended to support 323 incremental deployment of security capabilities with a view to 324 widespread adoption of Strict Privacy. It should be employed when 325 the DNS client might otherwise settle for cleartext; it provides 326 the maximum protection available. As described in [RFC7435] it 327 might result in 329 * an encrypted and authenticated connection 331 * an encrypted connection 333 * a clear text connection 335 depending on the fallback logic of the client, the available 336 authentication information and the capabilities of the DNS Server. 338 In all these cases the DNS client is willing to continue with a 339 connection to the DNS Server and perform resolution of queries. 341 To compare the two Usage profiles the table below shows successful 342 Strict Privacy along side the 3 possible outcomes of Opportunistic 343 Privacy. In the best case scenario for Opportunistic Privacy (an 344 authenticated and encrypted connection) it is equivalent to Strict 345 Privacy. In the worst case scenario it is equivalent to clear text. 346 Clients using Opportunistic Privacy SHOULD try for the best case but 347 MAY fallback to the intermediate case and eventually the worst case 348 scenario in order to obtain a response. It therefore provides no 349 privacy guarantee to the user and varying protection depending on 350 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.5. 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. Summary of Authentication Mechanisms 450 This section provides an overview of the various authentication 451 mechanisms. The table below indicates how the DNS client obtains 452 information to use for authentication for each option; either 453 statically via direct configuration or dynamically. Of course, the 454 Opportunistic Usage Profile does not require authentication and so a 455 client using that profile may choose to connect to a Privacy Enabling 456 DNS server on the basis of just an IP address. 458 +---+------------+-------------+------------------------------------+ 459 | # | Static | Dynamically | Short name: Description | 460 | | Config | Obtained | | 461 +---+------------+-------------+------------------------------------+ 462 | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | 463 | | | | address obtained out of band | 464 | | | | [RFC7858] | 465 | | | | | 466 | 2 | ADN + IP | | ADN: ADN and IP address obtained | 467 | | | | out of band (see Section 7.2.1) | 468 | | | | | 469 | 3 | ADN | IP | ADN only: DNSSEC validated | 470 | | | | Opportunistic lookups to a NP DNS | 471 | | | | server for SRV, A/AAAA (see | 472 | | | | Section 7.2.2) | 473 | | | | | 474 | 4 | | ADN + IP | DHCP: DHCP configuration only (see | 475 | | | | Section 7.2.3) | 476 | | | | | 477 | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | 478 | | | TLSA record | Opportunistic lookups to NP DNS | 479 | | | | server (see Section 8.2.1) | 480 | | | | | 481 | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | 482 | | | TLSA record | provided by PE DNS server in TLS | 483 | | | | DNSSEC chain extension (see | 484 | | | | Section 8.2.2) | 485 +---+------------+-------------+------------------------------------+ 487 SPKI == SPKI pinset(s), IP == IP Address, ADN == Authentication 488 Domain Name, NP == Network provided, PE == Privacy-enabling, [ ] == 489 Data may be obtained either statically or dynamically 491 Table 2: Overview of Authentication Mechanisms 493 The following summary attempts to present some key attributes of each 494 of the mechanisms (using the 'Short name' from Table 2), indicating 495 attractive attributes with a '+' and undesirable attributes with a 496 '-'. 498 1. SPKI 500 + Minimal leakage (Note that the ADN is always leaked in the 501 SNI field in the Client Hello in TLS when communicating with a 502 privacy enabling DNS server) 504 - Overhead of on-going key management required 506 2. ADN 508 + Minimal leakage 510 + One-off direct configuration only 512 3. ADN only 514 + Minimal one-off direct configuration, only a human 515 recognisable domain name needed 517 - SRV, A/AAAA meta queries leaked to network provided DNS 518 server 520 4. DHCP 522 + No static config 524 - Requires a non-standard or future DHCP option in order to 525 provide the ADN 527 - Requires secure and trustworthy connection to DHCP server 529 5. DANE 531 The ADN and/or IP may be obtained statically or dynamically 532 and the relevant attributes of that method apply 534 + DANE options (e.g. matching on entire certificate) 536 - Requires a DNSSEC validating stub implementation (deployment 537 of which is limited at the time of writing) 539 - DNSSEC chain meta queries leaked to network provided DNS 540 server 542 6. TLS extension 544 The ADN and/or IP may be obtained statically or dynamically 545 and the relevant attributes of that method apply 547 + Reduced latency compared with 'DANE' 549 + No network provided DNS server required if ADN and IP 550 statically configured 552 + DANE options (e.g. matching on entire certificate) 553 - Requires a DNSSEC validating stub implementation 555 6.4. Combining Authentication Mechanisms 557 This draft does not make explicit recommendations about how an SPKI 558 pinset based authentication mechanism should be combined with a 559 domain based mechanism from an operator perspective. However it can 560 be envisaged that a DNS server operator may wish to make both an SPKI 561 pinset and an authentication domain name available to allow clients 562 to choose which mechanism to use. Therefore, the following is 563 guidance on how clients ought to behave if they choose to configure 564 both, as is possible in HPKP [RFC7469]. 566 A DNS client that is configured with both an authentication domain 567 name and a SPKI pinset for a DNS server SHOULD match on both a valid 568 credential for the authentication domain name and a valid SPKI pinset 569 (if both are available) when connecting to that DNS server. The 570 overall authentication result should only be considered successful if 571 both authentication mechanisms are successful. 573 6.5. Authentication in Opportunistic Privacy 575 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 576 which MAY be used for DNS-over-(D)TLS. 578 DNS clients issuing queries under an opportunistic profile which know 579 authentication information for a given privacy-enabling DNS server 580 MAY choose to try to authenticate the server using the mechanisms 581 described here. This is useful for detecting (but not preventing) 582 active attack, since the fact that authentication information is 583 available indicates that the server in question is a privacy-enabling 584 DNS server to which it should be possible to establish an 585 authenticated, encrypted connection. In this case, whilst a client 586 cannot know the reason for an authentication failure, from a privacy 587 standpoint the client should consider an active attack in progress 588 and proceed under that assumption. Attempting authentication is also 589 useful for debugging or diagnostic purposes if there are means to 590 report the result. This information can provide a basis for a DNS 591 client to switch to (preferred) Strict Privacy where it is viable. 593 6.6. Authentication in Strict Privacy 595 To authenticate a privacy-enabling DNS server, a DNS client needs to 596 know authentication information for each server it is willing to 597 contact. This is necessary to protect against active attacks on DNS 598 privacy. 600 A DNS client requiring Strict Privacy MUST either use one of the 601 sources listed in Section 7.2 to obtain an authentication domain name 602 for the server it contacts, or use an SPKI pinset as described in 603 [RFC7858]. 605 A DNS client requiring Strict Privacy MUST only attempt to connect to 606 DNS servers for which at least one piece of authentication 607 information is known. The client MUST use the available verification 608 mechanisms described in Section 8 to authenticate the server, and 609 MUST abort connections to a server when no verification mechanism 610 succeeds. 612 With Strict Privacy, the DNS client MUST NOT commence sending DNS 613 queries until at least one of the privacy-enabling DNS servers 614 becomes available. 616 A privacy-enabling DNS server may be temporarily unavailable when 617 configuring a network. For example, for clients on networks that 618 require registration through web-based login (a.k.a. "captive 619 portals"), such registration may rely on DNS interception and 620 spoofing. Techniques such as those used by DNSSEC-trigger 621 [dnssec-trigger] MAY be used during network configuration, with the 622 intent to transition to the designated privacy-enabling DNS servers 623 after captive portal registration. The system MUST alert by some 624 means that the DNS is not private during such bootstrap. 626 6.7. Implementation guidance 628 Section 9 describes the (D)TLS profile for DNS-over(D)TLS. 629 Additional considerations relating to general implementation 630 guidelines are discussed in both Section 11 and in Appendix A. 632 7. Sources of Authentication Domain Names 634 7.1. In Band Sources: SRV Service Label 636 This specification adds a SRV service label "domain-s" for privacy- 637 enabling DNS servers. 639 Example service records (for TLS and DTLS respectively): 641 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 642 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 644 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 646 7.2. Out of Band Sources 648 7.2.1. Full direct configuration 650 DNS clients may be directly and securely provisioned with the 651 authentication domain name of each privacy-enabling DNS server. For 652 example, using a client specific configuration file or API. 654 In this case, direct configuration for a DNS client would consist of 655 both an IP address and a domain name for each DNS server. 657 7.2.2. Direct configuration of name only 659 A DNS client may be configured directly and securely with only the 660 authentication domain name of its privacy-enabling DNS server. For 661 example, using a client specific configuration file or API. 663 A DNS client might learn of a default recursive DNS resolver from an 664 untrusted source (such as DHCP's DNS server option [RFC3646]). It 665 can then use opportunistic DNS connections to untrusted recursive DNS 666 resolver to establish the IP address of the intended privacy-enabling 667 DNS server by doing a lookup of SRV records. Such records MUST be 668 validated using DNSSEC. Private DNS resolution can now be done by 669 the DNS client against the configured privacy-enabling DNS server. 671 Example: 673 o A DNSSEC validating DNS client is configured with the domain name 674 dns.example.net for a privacy-enabling DNS server 676 o Using Opportunistic Privacy to a default DNS resolver (acquired, 677 for example, using DHCP) the client performs look ups for 679 * SRV record for _domain-s._tcp.dns.example.net to obtain the 680 server host name 682 * A and/or AAAA lookups to obtain IP address for the server host 683 name 685 o Client validates all the records obtained in the previous step 686 using DNSSEC. 688 o If the records successfully validate the client proceeds to 689 connect to the privacy-enabling DNS server using Strict Privacy. 691 A DNS client so configured that successfully connects to a privacy- 692 enabling DNS server MAY choose to locally cache the looked up 693 addresses in order to not have to repeat the opportunistic lookup. 695 7.2.3. DHCP 697 Some clients may have an established trust relationship with a known 698 DHCP [RFC2131] server for discovering their network configuration. 699 In the typical case, such a DHCP server provides a list of IP 700 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 701 not provide a domain name for the DNS server itself. 703 In the future, a DHCP server might use a DHCP extension to provide a 704 list of authentication domain names for the offered DNS servers, 705 which correspond to IP addresses listed. 707 Use of such a mechanism with any DHCP server when using an 708 Opportunistic profile is reasonable, given the security expectation 709 of that profile. However when using a Strict profile the DHCP 710 servers used as sources of authentication domain names MUST be 711 considered secure and trustworthy. This document does not attempt to 712 describe secured and trusted relationships to DHCP servers. 714 It is noted (at the time of writing) that whilst some implementation 715 work is in progress to secure IPv6 connections for DHCP, IPv4 716 connections have received little to no implementation attention in 717 this area. 719 8. Authentication Domain Name based Credential Verification 721 8.1. PKIX Certificate Based Authentication 723 When a DNS client configured with an authentication domain name 724 connects to its configured DNS server over (D)TLS, the server may 725 present it with an PKIX certificate. In order to ensure proper 726 authentication, DNS clients MUST verify the entire certification path 727 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 728 techniques to compare the domain name to the certificate provided. 730 A DNS client constructs two Reference Identifiers for the server 731 based on the authentication domain name: A DNS-ID and an SRV-ID 732 [RFC4985]. The DNS-ID is simply the authentication domain name 733 itself. The SRV-ID uses a "_domain-s." prefix. So if the configured 734 authentication domain name is "dns.example.com", then the two 735 Reference Identifiers are: 737 DNS-ID: dns.example.com 739 SRV-ID: _domain-s.dns.example.com 741 If either of the Reference Identifiers are found in the PKIX 742 certificate's subjectAltName extension as described in section 6 of 744 [RFC6125], the DNS client should accept the certificate for the 745 server. 747 A compliant DNS client MUST only inspect the certificate's 748 subjectAltName extension for these Reference Identifiers. In 749 particular, it MUST NOT inspect the Subject field itself. 751 8.2. DANE 753 DANE [RFC6698] provides mechanisms to root certificate and raw public 754 key trust with DNSSEC. However this requires the DNS client to have 755 an authentication domain name for the DNS Privacy Server which must 756 be obtained via a trusted source. 758 This section assumes a solid understanding of both DANE [RFC6698] and 759 DANE Operations [RFC7671]. A few pertinent issues covered in these 760 documents are outlined here as useful pointers, but familiarity with 761 both these documents in their entirety is expected. 763 It is noted that [RFC6698] says 765 "Clients that validate the DNSSEC signatures themselves MUST use 766 standard DNSSEC validation procedures. Clients that rely on 767 another entity to perform the DNSSEC signature validation MUST use 768 a secure mechanism between themselves and the validator." 770 It is noted that [RFC7671] covers the following topics: 772 o Section 4.1: Opportunistic Security and PKIX Usages and 773 Section 14: Security Considerations, which both discuss the use of 774 PKIX-TA(0) and PKIX-EE(1) for OS. 776 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 777 Specifically Section 5.1 which outlines the combination of 778 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 779 Public Keys [RFC7250]. Section 5.1 also discusses the security 780 implications of this mode, for example, it discusses key lifetimes 781 and specifies that validity period enforcement is based solely on 782 the TLSA RRset properties for this case. 784 o Section 13: Operational Considerations, which discusses TLSA TTLs 785 and signature validity periods. 787 The specific DANE record for a DNS Privacy Server would take the 788 form: 790 _853._tcp.[server-domain-name] for TLS 791 _853._udp.[server-domain-name] for DTLS 793 8.2.1. Direct DNS Lookup 795 The DNS client MAY choose to perform the DNS lookups to retrieve the 796 required DANE records itself. The DNS queries for such DANE records 797 MAY use opportunistic encryption or be in the clear to avoid trust 798 recursion. The records MUST be validated using DNSSEC as described 799 above in [RFC6698]. 801 8.2.2. TLS DNSSEC Chain extension 803 The DNS client MAY offer the TLS extension described in 804 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 805 this extension, it can provide the full chain to the client in the 806 handshake. 808 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 809 capable of validating the full DNSSEC authentication chain down to 810 the leaf. If the supplied DNSSEC chain does not validate, the client 811 MUST ignore the DNSSEC chain and validate only via other supplied 812 credentials. 814 9. (D)TLS Protocol Profile 816 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 818 There are known attacks on (D)TLS, such as machine-in-the-middle and 819 protocol downgrade. These are general attacks on (D)TLS and not 820 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 821 discussion of these security issues. 823 Clients and servers MUST adhere to the (D)TLS implementation 824 recommendations and security considerations of [RFC7525] except with 825 respect to (D)TLS version. 827 Since encryption of DNS using (D)TLS is virtually a green-field 828 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 829 later. 831 Implementations MUST NOT offer or provide TLS compression, since 832 compression can leak significant amounts of information, especially 833 to a network observer capable of forcing the user to do an arbitrary 834 DNS lookup in the style of the CRIME attacks [CRIME]. 836 Implementations compliant with this profile MUST implement all of the 837 following items: 839 o TLS session resumption without server-side state [RFC5077] which 840 eliminates the need for the server to retain cryptographic state 841 for longer than necessary. 843 o Raw public keys [RFC7250] which reduce the size of the 844 ServerHello, and can be used by servers that cannot obtain 845 certificates (e.g., DNS servers on private networks). 847 Implementations compliant with this profile SHOULD implement all of 848 the following items: 850 o TLS False Start [RFC7918] which reduces round-trips by allowing 851 the TLS second flight of messages (ChangeCipherSpec) to also 852 contain the (encrypted) DNS query 854 o Cached Information Extension [RFC7924] which avoids transmitting 855 the server's certificate and certificate chain if the client has 856 cached that information from a previous TLS handshake 858 Guidance specific to TLS is provided in [RFC7858] and that specific 859 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 861 10. IANA Considerations 863 This memo includes no request to IANA. 865 11. Security Considerations 867 Security considerations discussed in [RFC7525], 868 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 870 11.1. Counter-measures to DNS Traffic Analysis 872 This section makes suggestions for measures that can reduce the 873 ability of attackers to infer information pertaining to encrypted 874 client queries by other means (e.g. via an analysis of encrypted 875 traffic size, or via monitoring of resolver to authoritative 876 traffic). 878 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 879 following relevant DNS extensions 881 o EDNS(0) padding [RFC7830], which allows encrypted queries and 882 responses to hide their size. 884 DNS-over-(D)TLS clients SHOULD consider implementing the following 885 relevant DNS extensions 886 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 887 a DNS client does not include an EDNS0 Client Subnet Option with a 888 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 889 potentially leak client address information to the upstream 890 authoritative DNS servers. A DNS client ought to be able to 891 inform the DNS Resolver that it does not want any address 892 information leaked, and the DNS Resolver should honor that 893 request. 895 12. Acknowledgements 897 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 898 [RFC7858] for laying the ground work that this draft builds on and 899 for reviewing the contents. The authors would also like to thank 900 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 901 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian 902 Huitema and John Levine for review and discussion of the ideas 903 presented here. 905 13. References 907 13.1. Normative References 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, 911 DOI 10.17487/RFC2119, March 1997, 912 . 914 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 915 Subject Alternative Name for Expression of Service Name", 916 RFC 4985, DOI 10.17487/RFC4985, August 2007, 917 . 919 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 920 "Transport Layer Security (TLS) Session Resumption without 921 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 922 January 2008, . 924 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 925 (TLS) Protocol Version 1.2", RFC 5246, 926 DOI 10.17487/RFC5246, August 2008, 927 . 929 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 930 Housley, R., and W. Polk, "Internet X.509 Public Key 931 Infrastructure Certificate and Certificate Revocation List 932 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 933 . 935 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 936 Verification of Domain-Based Application Service Identity 937 within Internet Public Key Infrastructure Using X.509 938 (PKIX) Certificates in the Context of Transport Layer 939 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 940 2011, . 942 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 943 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 944 January 2012, . 946 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 947 of Named Entities (DANE) Transport Layer Security (TLS) 948 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 949 2012, . 951 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 952 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 953 Transport Layer Security (TLS) and Datagram Transport 954 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 955 June 2014, . 957 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 958 "Recommendations for Secure Use of Transport Layer 959 Security (TLS) and Datagram Transport Layer Security 960 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 961 2015, . 963 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 964 Authentication of Named Entities (DANE) Protocol: Updates 965 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 966 October 2015, . 968 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 969 DOI 10.17487/RFC7830, May 2016, 970 . 972 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 973 and P. Hoffman, "Specification for DNS over Transport 974 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 975 2016, . 977 13.2. Informative References 979 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 981 [dnssec-trigger] 982 NLnetLabs, "Dnssec-Trigger", May 2014, 983 . 985 [I-D.ietf-dprive-dnsodtls] 986 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 987 over Datagram Transport Layer Security (DTLS)", draft- 988 ietf-dprive-dnsodtls-15 (work in progress), December 2016. 990 [I-D.ietf-tls-dnssec-chain-extension] 991 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 992 Record and DNSSEC Authentication Chain Extension for TLS", 993 draft-ietf-tls-dnssec-chain-extension-02 (work in 994 progress), January 2017. 996 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 997 RFC 2131, DOI 10.17487/RFC2131, March 1997, 998 . 1000 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1001 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1002 . 1004 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1005 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1006 DOI 10.17487/RFC3646, December 2003, 1007 . 1009 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1010 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1011 December 2014, . 1013 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1014 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1015 2015, . 1017 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1018 DOI 10.17487/RFC7626, August 2015, 1019 . 1021 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1022 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1023 DOI 10.17487/RFC7871, May 2016, 1024 . 1026 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1027 Layer Security (TLS) False Start", RFC 7918, 1028 DOI 10.17487/RFC7918, August 2016, 1029 . 1031 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1032 (TLS) Cached Information Extension", RFC 7924, 1033 DOI 10.17487/RFC7924, July 2016, 1034 . 1036 Appendix A. Server capability probing and caching by DNS clients 1038 This section presents a non-normative discussion of how DNS clients 1039 might probe for and cache privacy capabilities of DNS servers. 1041 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 1042 Not all servers will support one or both of these protocols and the 1043 well-known port might be blocked by some middleboxes. Clients will 1044 be expected to keep track of servers that support DNS-over-TLS and/or 1045 DNS-over-DTLS, and those that have been previously authenticated. 1047 If no server capability information is available then (unless 1048 otherwise specified by the configuration of the DNS client) DNS 1049 clients that implement both TLS and DTLS should try to authenticate 1050 using both protocols before failing or falling back to a lower 1051 security. DNS clients using opportunistic security should try all 1052 available servers (possibly in parallel) in order to obtain an 1053 authenticated encrypted connection before falling back to a lower 1054 security. (RATIONALE: This approach can increase latency while 1055 discovering server capabilities but maximizes the chance of sending 1056 the query over an authenticated encrypted connection.) 1058 Appendix B. Changes between revisions 1060 [Note to RFC Editor: please remove this section prior to 1061 publication.] 1063 B.1. -08 version 1065 Removed hard failure as an option for Opportunistic Usage profile. 1067 Added a new section comparing the Authentication Mechanisms 1069 B.2. -07 version 1071 Re-work of the Abstract and Introduction to better describe the 1072 contents in this version. 1074 Terminology: New definition of 'authentication information'. 1076 Scope: Changes to the Scope section. 1078 Moved discussion of combining authentication mechanism earlier. 1080 Changes to the section headings and groupings to make the 1081 presentation more logical. 1083 B.3. -06 version 1085 Introduction: Re-word discussion of Working group charter. 1087 Introduction: Re-word first and third bullet point about 'obtaining' 1088 a domain name and IP address. 1090 Introduction: Update reference to DNS-over-TLS draft. 1092 Terminology: Change forwarder/proxy to just forwarder 1094 Terminology: Add definition of 'Authentication domain name' and use 1095 this throughout 1097 Section 4.2: Remove parenthesis in the table. 1099 Section 4.2: Change the text after the table as agreed with Paul 1100 Hoffman. 1102 Section 4.3.1: Change title and remove brackets around last 1103 statement. 1105 Section 11: Split second paragraph. 1107 B.4. -05 version 1109 Add more details on detecting passive attacks to section 4.2 1111 Changed X.509 to PKIX throughout 1113 Change comment about future I-D on usage policies. 1115 B.5. -04 version 1117 Introduction: Add comment that DNS-over-DTLS draft is Experiments 1119 Update 2 I-D references to RFCs. 1121 B.6. -03 version 1123 Section 9: Update DANE section with better references to RFC7671 and 1124 RFC7250 1126 B.7. -02 version 1128 Introduction: Added paragraph on the background and scope of the 1129 document. 1131 Introduction and Discussion: Added more information on what a Usage 1132 profiles is (and is not) the the two presented here. 1134 Introduction: Added paragraph to make a comparison with the Strict 1135 profile in RFC7858 clearer. 1137 Section 4.2: Re-worked the description of Opportunistic and the 1138 table. 1140 Section 8.3: Clarified statement about use of DHCP in Opportunistic 1141 profile 1143 Title abbreviated. 1145 B.8. -01 version 1147 Section 4.2: Make clear that the Strict Privacy Profile can include 1148 meta queries performed using Opportunistic Privacy. 1150 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 1151 does not guarantee protection against passive attack. 1153 Section 4.2: Add sentence discussing client/provider trusted 1154 relationships. 1156 Section 5: Add more discussion of detection of active attacks when 1157 using Opportunistic Privacy. 1159 Section 8.2: Clarify description and example. 1161 B.9. draft-ietf-dprive-dtls-and-tls-profiles-00 1163 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1164 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1165 fixed. 1167 Authors' Addresses 1169 Sara Dickinson 1170 Sinodun Internet Technologies 1171 Magdalen Centre 1172 Oxford Science Park 1173 Oxford OX4 4GA 1174 UK 1176 Email: sara@sinodun.com 1177 URI: http://sinodun.com 1179 Daniel Kahn Gillmor 1180 ACLU 1181 125 Broad Street, 18th Floor 1182 New York NY 10004 1183 USA 1185 Email: dkg@fifthhorseman.net 1187 Tirumaleswar Reddy 1188 Cisco Systems, Inc. 1189 Cessna Business Park, Varthur Hobli 1190 Sarjapur Marathalli Outer Ring Road 1191 Bangalore, Karnataka 560103 1192 India 1194 Email: tireddy@cisco.com