idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-09.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7858, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 10, 2017) is 2572 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 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-03 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun 4 Updates: 7858 (if approved) D. Gillmor 5 Intended status: Standards Track ACLU 6 Expires: October 12, 2017 T. Reddy 7 Cisco 8 April 10, 2017 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-09 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 October 12, 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. Full direct configuration . . . . . . . . . . . . . . . . 14 73 7.2. Direct configuration of name only . . . . . . . . . . . . 14 74 7.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Authentication Domain Name based Credential Verification . . 15 76 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 15 77 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 17 79 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 17 80 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 17 81 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 18 84 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 87 13.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Appendix A. Server capability probing and caching by DNS clients 22 89 Appendix B. Changes between revisions . . . . . . . . . . . . . 22 90 B.1. -09 version . . . . . . . . . . . . . . . . . . . . . . . 22 91 B.2. -08 version . . . . . . . . . . . . . . . . . . . . . . . 23 92 B.3. -07 version . . . . . . . . . . . . . . . . . . . . . . . 23 93 B.4. -06 version . . . . . . . . . . . . . . . . . . . . . . . 23 94 B.5. -05 version . . . . . . . . . . . . . . . . . . . . . . . 24 95 B.6. -04 version . . . . . . . . . . . . . . . . . . . . . . . 24 96 B.7. -03 version . . . . . . . . . . . . . . . . . . . . . . . 24 97 B.8. -02 version . . . . . . . . . . . . . . . . . . . . . . . 24 98 B.9. -01 version . . . . . . . . . . . . . . . . . . . . . . . 24 99 B.10. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 DNS Privacy issues are discussed in [RFC7626]. Two documents that 105 provide DNS privacy between DNS clients and DNS servers are: 107 o Specification for DNS over Transport Layer Security (TLS) 108 [RFC7858], referred to here as simply 'DNS-over-TLS' 110 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 111 simply as 'DNS-over-DTLS'. Note that this document has the 112 Intended status of Experimental. 114 Both documents are limited in scope to encrypting DNS messages 115 between stub clients and recursive resolvers and the same scope is 116 applied to this document (see Section 2 and Section 3). The 117 proposals here might be adapted or extended in future to be used for 118 recursive clients and authoritative servers, but this application was 119 out of scope for the Working Group charter at the time this document 120 was finished. 122 This document specifies two Usage Profiles (Strict and Opportunistic) 123 for DTLS [RFC6347] and TLS [RFC5246] which define the security 124 properties a user should expect when using that profile to connect to 125 the available DNS servers. Section 5 presents a generalised 126 discussion of Usage Profiles by separating the Usage Profile, which 127 is based purely on the security properties it offers the user, from 128 the specific mechanism(s) that are used for authentication. The 129 Profiles described are: 131 o A Strict Profile that requires an encrypted connection and 132 successful authentication of the DNS server which provides strong 133 privacy guarantees (at the expense of providing no DNS service if 134 this is not available). 136 o An Opportunistic Profile that will attempt, but does not require, 137 encryption and successful authentication; it therefore provides no 138 privacy guarantees but offers maximum chance of DNS service. 140 The above Usage Profiles attempt authentication of the server using 141 at least one authentication mechanism. Section 6.4 discusses how to 142 combine authentication mechanisms to determine the overall 143 authentication result. Depending on that overall authentication 144 result (and whether encryption is available) the Usage Profile will 145 determine if the connection should proceed, fallback or fail. 147 One authentication mechanism is already described in [RFC7858]. That 148 document specifies an SPKI based authentication mechanism for DNS- 149 over-TLS in the context of a specific case of a Strict Usage Profile 150 using that single authentication mechanism. Therefore the "Out-of- 151 band Key-pinned Privacy Profile" described in [RFC7858] would qualify 152 as a "Strict Usage Profile" that used SPKI pinning for 153 authentication. 155 This document extends the use of SPKI pinset based authentication so 156 that it is considered a general authentication mechanism that can be 157 used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI 158 pinset mechanism described in [RFC7858] MAY be used with DNS- 159 over-(D)TLS. 161 This document also describes a number of additional authentication 162 mechanisms all of which specify how a DNS client should authenticate 163 a DNS server based on an 'authentication domain name'. In 164 particular, the following is described: 166 o How a DNS client can obtain the combination of an authentication 167 domain name and IP address for a DNS server. See Section 7. 169 o What are the acceptable credentials a DNS server can present to 170 prove its identity for (D)TLS authentication based on a given 171 authentication domain name. See Section 8. 173 o How a DNS client can verify that any given credential matches the 174 authentication domain name obtained for a DNS server. See 175 Section 8. 177 In Section 9 this document defines a (D)TLS protocol profile for use 178 with DNS. This profile defines the configuration options and 179 protocol extensions required of both parties to optimize connection 180 establishment and session resumption for transporting DNS, and to 181 support all currently specified authentication mechanisms. 183 2. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 Several terms are used specifically in the context of this draft: 191 o DNS client: a DNS stub resolver or forwarder. In the case of a 192 forwarder, the term "DNS client" is used to discuss the side that 193 sends queries. 195 o DNS server: a DNS recursive resolver or forwarder. In the case of 196 a forwarder, the term "DNS server" is used to discuss the side 197 that responds to queries. For emphasis, in this document the term 198 does not apply to authoritative servers. 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 332 * a clear text connection 334 depending on the fallback logic of the client, the available 335 authentication information and the capabilities of the DNS Server. 336 In all these cases the DNS client is willing to continue with a 337 connection to the DNS Server and perform resolution of queries. 339 To compare the two Usage profiles the table below shows successful 340 Strict Privacy along side the 3 possible outcomes of Opportunistic 341 Privacy. In the best case scenario for Opportunistic Privacy (an 342 authenticated and encrypted connection) it is equivalent to Strict 343 Privacy. In the worst case scenario it is equivalent to clear text. 344 Clients using Opportunistic Privacy SHOULD try for the best case but 345 MAY fallback to the intermediate case and eventually the worst case 346 scenario in order to obtain a response. It therefore provides no 347 privacy guarantee to the user and varying protection depending on 348 what kind of connection is actually used. 350 Note that there is no requirement in Opportunistic Security to notify 351 the user what type of connection is actually used, the 'detection' 352 described below is only possible if such connection information is 353 available. However, if it is available and the user is informed that 354 an unencrypted connection was used to connect to a server then the 355 user should assume (detect) that the connection is subject to both 356 active and passive attack since the DNS queries are sent in clear 357 text. This might be particularly useful if a new connection to a 358 certain server is unencrypted when all previous connections were 359 encrypted. Similarly if the user is informed that an encrypted but 360 unauthenticated connection was used then the user can detect that the 361 connection may be subject to active attack. This is discussed in 362 Section 6.5. 364 +---------------+------------+------------------+-----------------+ 365 | Usage Profile | Connection | Passive Attacker | Active Attacker | 366 +---------------+------------+------------------+-----------------+ 367 | Strict | A, E | P | P | 368 | Opportunistic | A, E | P | P | 369 | Opportunistic | E | P | N, D | 370 | Opportunistic | | N, D | N, D | 371 +---------------+------------+------------------+-----------------+ 373 P == protection; N == no protection; D == detection is possible; A == 374 Authenticated Connection; E == Encrypted Connection 376 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 377 Strict Privacy provides the strongest privacy guarantees and 378 therefore SHOULD always be implemented in DNS clients along with 379 Opportunistic Privacy. 381 A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to 382 the use of clear text (no privacy). 384 The choice between the two profiles depends on a number of factors 385 including which is more important to the particular client: 387 o DNS service at the cost of no privacy guarantee (Opportunistic) or 389 o guaranteed privacy at the potential cost of no DNS service 390 (Strict). 392 Additionally the two profiles require varying levels of configuration 393 (or a trusted relationship with a provider) and DNS server 394 capabilities, therefore DNS clients will need to carefully select 395 which profile to use based on their communication privacy needs. 397 A DNS server that implements DNS-over-(D)TLS SHOULD provide at least 398 one credential so that those DNS clients that wish to do so are able 399 to use Strict Privacy (see Section 2). 401 5.1. DNS Resolution 403 A DNS client SHOULD select a particular Usage Profile when resolving 404 a query. A DNS client MUST NOT fallback from Strict Privacy to 405 Opportunistic Privacy during the resolution process as this could 406 invalidate the protection offered against active attackers. 408 6. Authentication in DNS-over(D)TLS 410 This section describes authentication mechanisms and how they can be 411 used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 413 6.1. DNS-over-(D)TLS Startup Configuration Problems 415 Many (D)TLS clients use PKIX authentication [RFC6125] based on an 416 authentication domain name for the server they are contacting. These 417 clients typically first look up the server's network address in the 418 DNS before making this connection. Such a DNS client therefore has a 419 bootstrap problem, as it will typically only know the IP address of 420 its DNS server. 422 In this case, before connecting to a DNS server, a DNS client needs 423 to learn the authentication domain name it should associate with the 424 IP address of a DNS server for authentication purposes. Sources of 425 authentication domain names are discussed in Section 7. 427 One advantage of this domain name based approach is that it 428 encourages association of stable, human recognisable identifiers with 429 secure DNS service providers. 431 6.2. Credential Verification 433 The use of SPKI pinset verification is discussed in [RFC7858]. 435 In terms of domain name based verification, once an authentication 436 domain name is known for a DNS server a choice of authentication 437 mechanisms can be used for credential verification. Section 8 438 discusses these mechanisms in detail, namely PKIX certificate based 439 authentication and DANE. 441 Note that the use of DANE adds requirements on the ability of the 442 client to get validated DNSSEC results. This is discussed in more 443 detail in Section 8.2. 445 6.3. Summary of Authentication Mechanisms 447 This section provides an overview of the various authentication 448 mechanisms. The table below indicates how the DNS client obtains 449 information to use for authentication for each option; either 450 statically via direct configuration or dynamically. Of course, the 451 Opportunistic Usage Profile does not require authentication and so a 452 client using that profile may choose to connect to a Privacy Enabling 453 DNS server on the basis of just an IP address. 455 +---+------------+-------------+------------------------------------+ 456 | # | Static | Dynamically | Short name: Description | 457 | | Config | Obtained | | 458 +---+------------+-------------+------------------------------------+ 459 | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | 460 | | | | address obtained out of band | 461 | | | | [RFC7858] | 462 | | | | | 463 | 2 | ADN + IP | | ADN: ADN and IP address obtained | 464 | | | | out of band (see Section 7.1) | 465 | | | | | 466 | 3 | ADN | IP | ADN only: Opportunistic lookups to | 467 | | | | a NP DNS server for A/AAAA (see | 468 | | | | Section 7.2) | 469 | | | | | 470 | 4 | | ADN + IP | DHCP: DHCP configuration only (see | 471 | | | | Section 7.3) | 472 | | | | | 473 | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | 474 | | | TLSA record | Opportunistic lookups to NP DNS | 475 | | | | server (see Section 8.2.1) | 476 | | | | | 477 | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | 478 | | | TLSA record | provided by PE DNS server in TLS | 479 | | | | DNSSEC chain extension (see | 480 | | | | Section 8.2.2) | 481 +---+------------+-------------+------------------------------------+ 483 SPKI == SPKI pinset(s), IP == IP Address, ADN == Authentication 484 Domain Name, NP == Network provided, PE == Privacy-enabling, [ ] == 485 Data may be obtained either statically or dynamically 487 Table 2: Overview of Authentication Mechanisms 489 The following summary attempts to present some key attributes of each 490 of the mechanisms (using the 'Short name' from Table 2), indicating 491 attractive attributes with a '+' and undesirable attributes with a 492 '-'. 494 1. SPKI 496 + Minimal leakage (Note that the ADN is always leaked in the 497 SNI field in the Client Hello in TLS when communicating with a 498 privacy enabling DNS server) 500 - Overhead of on-going key management required 502 2. ADN 503 + Minimal leakage 505 + One-off direct configuration only 507 3. ADN only 509 + Minimal one-off direct configuration, only a human 510 recognisable domain name needed 512 - A/AAAA meta queries leaked to network provided DNS server 514 4. DHCP 516 + No static config 518 - Requires a non-standard or future DHCP option in order to 519 provide the ADN 521 - Requires secure and trustworthy connection to DHCP server 523 5. DANE 525 The ADN and/or IP may be obtained statically or dynamically 526 and the relevant attributes of that method apply 528 + DANE options (e.g. matching on entire certificate) 530 - Requires a DNSSEC validating stub implementation (deployment 531 of which is limited at the time of writing) 533 - DNSSEC chain meta queries leaked to network provided DNS 534 server 536 6. TLS extension 538 The ADN and/or IP may be obtained statically or dynamically 539 and the relevant attributes of that method apply 541 + Reduced latency compared with 'DANE' 543 + No network provided DNS server required if ADN and IP 544 statically configured 546 + DANE options (e.g. matching on entire certificate) 548 - Requires a DNSSEC validating stub implementation 550 6.4. Combining Authentication Mechanisms 552 This draft does not make explicit recommendations about how an SPKI 553 pinset based authentication mechanism should be combined with a 554 domain based mechanism from an operator perspective. However it can 555 be envisaged that a DNS server operator may wish to make both an SPKI 556 pinset and an authentication domain name available to allow clients 557 to choose which mechanism to use. Therefore, the following is 558 guidance on how clients ought to behave if they choose to configure 559 both, as is possible in HPKP [RFC7469]. 561 A DNS client that is configured with both an authentication domain 562 name and a SPKI pinset for a DNS server SHOULD match on both a valid 563 credential for the authentication domain name and a valid SPKI pinset 564 (if both are available) when connecting to that DNS server. The 565 overall authentication result should only be considered successful if 566 both authentication mechanisms are successful. 568 6.5. Authentication in Opportunistic Privacy 570 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 571 which MAY be used for DNS-over-(D)TLS. 573 DNS clients issuing queries under an opportunistic profile which know 574 authentication information for a given privacy-enabling DNS server 575 MAY choose to try to authenticate the server using the mechanisms 576 described here. This is useful for detecting (but not preventing) 577 active attack, since the fact that authentication information is 578 available indicates that the server in question is a privacy-enabling 579 DNS server to which it should be possible to establish an 580 authenticated, encrypted connection. In this case, whilst a client 581 cannot know the reason for an authentication failure, from a privacy 582 standpoint the client should consider an active attack in progress 583 and proceed under that assumption. Attempting authentication is also 584 useful for debugging or diagnostic purposes if there are means to 585 report the result. This information can provide a basis for a DNS 586 client to switch to (preferred) Strict Privacy where it is viable. 588 6.6. Authentication in Strict Privacy 590 To authenticate a privacy-enabling DNS server, a DNS client needs to 591 know authentication information for each server it is willing to 592 contact. This is necessary to protect against active attacks on DNS 593 privacy. 595 A DNS client requiring Strict Privacy MUST either use one of the 596 sources listed in Section 7 to obtain an authentication domain name 597 for the server it contacts, or use an SPKI pinset as described in 598 [RFC7858]. 600 A DNS client requiring Strict Privacy MUST only attempt to connect to 601 DNS servers for which at least one piece of authentication 602 information is known. The client MUST use the available verification 603 mechanisms described in Section 8 to authenticate the server, and 604 MUST abort connections to a server when no verification mechanism 605 succeeds. 607 With Strict Privacy, the DNS client MUST NOT commence sending DNS 608 queries until at least one of the privacy-enabling DNS servers 609 becomes available. 611 A privacy-enabling DNS server may be temporarily unavailable when 612 configuring a network. For example, for clients on networks that 613 require registration through web-based login (a.k.a. "captive 614 portals"), such registration may rely on DNS interception and 615 spoofing. Techniques such as those used by DNSSEC-trigger 616 [dnssec-trigger] MAY be used during network configuration, with the 617 intent to transition to the designated privacy-enabling DNS servers 618 after captive portal registration. The system MUST alert by some 619 means that the DNS is not private during such bootstrap. 621 6.7. Implementation guidance 623 Section 9 describes the (D)TLS profile for DNS-over(D)TLS. 624 Additional considerations relating to general implementation 625 guidelines are discussed in both Section 11 and in Appendix A. 627 7. Sources of Authentication Domain Names 629 7.1. Full direct configuration 631 DNS clients may be directly and securely provisioned with the 632 authentication domain name of each privacy-enabling DNS server. For 633 example, using a client specific configuration file or API. 635 In this case, direct configuration for a DNS client would consist of 636 both an IP address and a domain name for each DNS server. 638 7.2. Direct configuration of name only 640 A DNS client may be configured directly and securely with only the 641 authentication domain name of its privacy-enabling DNS server. For 642 example, using a client specific configuration file or API. 644 A DNS client might learn of a default recursive DNS resolver from an 645 untrusted source (such as DHCP's DNS server option [RFC3646]). It 646 can then use opportunistic DNS connections to an untrusted recursive 647 DNS resolver to establish the IP address of the intended privacy- 648 enabling DNS resolver by doing a lookup of A/AAAA records. Private 649 DNS resolution can now be done by the DNS client against the pre- 650 configured privacy-enabling DNS resolver, using the IP address 651 gathered from the untrusted DNS resolver. 653 A DNS client so configured that successfully connects to a privacy- 654 enabling DNS server MAY choose to locally cache the server host IP 655 addresses in order to not have to repeat the opportunistic lookup. 657 7.3. DHCP 659 Some clients may have an established trust relationship with a known 660 DHCP [RFC2131] server for discovering their network configuration. 661 In the typical case, such a DHCP server provides a list of IP 662 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 663 not provide a domain name for the DNS server itself. 665 In the future, a DHCP server might use a DHCP extension to provide a 666 list of authentication domain names for the offered DNS servers, 667 which correspond to IP addresses listed. 669 Use of such a mechanism with any DHCP server when using an 670 Opportunistic profile is reasonable, given the security expectation 671 of that profile. However when using a Strict profile the DHCP 672 servers used as sources of authentication domain names MUST be 673 considered secure and trustworthy. This document does not attempt to 674 describe secured and trusted relationships to DHCP servers. 676 It is noted (at the time of writing) that whilst some implementation 677 work is in progress to secure IPv6 connections for DHCP, IPv4 678 connections have received little to no implementation attention in 679 this area. 681 8. Authentication Domain Name based Credential Verification 683 8.1. PKIX Certificate Based Authentication 685 When a DNS client configured with an authentication domain name 686 connects to its configured DNS server over (D)TLS, the server may 687 present it with a PKIX certificate. In order to ensure proper 688 authentication, DNS clients MUST verify the entire certification path 689 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 690 techniques to compare the domain name to the certificate provided. 692 A DNS client constructs one Reference Identifier for the server based 693 on the authentication domain name: A DNS-ID which is simply the 694 authentication domain name itself. 696 If the Reference Identifier is found in the PKIX certificate's 697 subjectAltName extension as described in section 6 of [RFC6125], the 698 DNS client should accept the certificate for the server. 700 A compliant DNS client MUST only inspect the certificate's 701 subjectAltName extension for the Reference Identifier. In 702 particular, it MUST NOT inspect the Subject field itself. 704 8.2. DANE 706 DANE [RFC6698] provides mechanisms to anchor certificate and raw 707 public key trust with DNSSEC. However this requires the DNS client 708 to have an authentication domain name for the DNS Privacy Server 709 which must be obtained via a trusted source. 711 This section assumes a solid understanding of both DANE [RFC6698] and 712 DANE Operations [RFC7671]. A few pertinent issues covered in these 713 documents are outlined here as useful pointers, but familiarity with 714 both these documents in their entirety is expected. 716 It is noted that [RFC6698] says 718 "Clients that validate the DNSSEC signatures themselves MUST use 719 standard DNSSEC validation procedures. Clients that rely on 720 another entity to perform the DNSSEC signature validation MUST use 721 a secure mechanism between themselves and the validator." 723 It is noted that [RFC7671] covers the following topics: 725 o Section 4.1: Opportunistic Security and PKIX Usages and 726 Section 14: Security Considerations, which both discuss the use of 727 PKIX-TA(0) and PKIX-EE(1) for Opportunistic Security. 729 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 730 Specifically Section 5.1 which outlines the combination of 731 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 732 Public Keys [RFC7250]. Section 5.1 also discusses the security 733 implications of this mode, for example, it discusses key lifetimes 734 and specifies that validity period enforcement is based solely on 735 the TLSA RRset properties for this case. 737 o Section 13: Operational Considerations, which discusses TLSA TTLs 738 and signature validity periods. 740 The specific DANE record for a DNS Privacy Server would take the 741 form: 743 _853._tcp.[authentication-domain-name] for TLS 745 _853._udp.[authentication-domain-name] for DTLS 747 8.2.1. Direct DNS Lookup 749 The DNS client MAY choose to perform the DNS lookups to retrieve the 750 required DANE records itself. The DNS queries for such DANE records 751 MAY use opportunistic encryption or be in the clear to avoid trust 752 recursion. The records MUST be validated using DNSSEC as described 753 above in [RFC6698]. 755 8.2.2. TLS DNSSEC Chain extension 757 The DNS client MAY offer the TLS extension described in 758 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 759 this extension, it can provide the full chain to the client in the 760 handshake. 762 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 763 capable of validating the full DNSSEC authentication chain down to 764 the leaf. If the supplied DNSSEC chain does not validate, the client 765 MUST ignore the DNSSEC chain and validate only via other supplied 766 credentials. 768 9. (D)TLS Protocol Profile 770 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 772 There are known attacks on (D)TLS, such as machine-in-the-middle and 773 protocol downgrade. These are general attacks on (D)TLS and not 774 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 775 discussion of these security issues. 777 Clients and servers MUST adhere to the (D)TLS implementation 778 recommendations and security considerations of [RFC7525] except with 779 respect to (D)TLS version. 781 Since encryption of DNS using (D)TLS is a green-field deployment DNS 782 clients and servers MUST implement only (D)TLS 1.2 or later. 784 Implementations MUST NOT offer or provide TLS compression, since 785 compression can leak significant amounts of information, especially 786 to a network observer capable of forcing the user to do an arbitrary 787 DNS lookup in the style of the CRIME attacks [CRIME]. 789 Implementations compliant with this profile MUST implement all of the 790 following items: 792 o TLS session resumption without server-side state [RFC5077] which 793 eliminates the need for the server to retain cryptographic state 794 for longer than necessary (This statement updates [RFC7858]). 796 o Raw public keys [RFC7250] which reduce the size of the 797 ServerHello, and can be used by servers that cannot obtain 798 certificates (e.g., DNS servers on private networks). 800 Implementations compliant with this profile SHOULD implement all of 801 the following items: 803 o TLS False Start [RFC7918] which reduces round-trips by allowing 804 the TLS second flight of messages (ChangeCipherSpec) to also 805 contain the (encrypted) DNS query 807 o Cached Information Extension [RFC7924] which avoids transmitting 808 the server's certificate and certificate chain if the client has 809 cached that information from a previous TLS handshake 811 Guidance specific to TLS is provided in [RFC7858] and that specific 812 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 814 10. IANA Considerations 816 This memo includes no request to IANA. 818 11. Security Considerations 820 Security considerations discussed in [RFC7525], 821 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 823 DNS Clients SHOULD consider implementing support for the mechanisms 824 described in Section 8.2 and offering a configuration option which 825 limits authentication to using only those mechanisms (i.e. with no 826 fallback to pure PKIX based authentication) such that authenticating 827 solely via the PKIX infrastructure can be avoided. 829 11.1. Counter-measures to DNS Traffic Analysis 831 This section makes suggestions for measures that can reduce the 832 ability of attackers to infer information pertaining to encrypted 833 client queries by other means (e.g. via an analysis of encrypted 834 traffic size, or via monitoring of resolver to authoritative 835 traffic). 837 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 838 following relevant DNS extensions 840 o EDNS(0) padding [RFC7830], which allows encrypted queries and 841 responses to hide their size. 843 DNS-over-(D)TLS clients SHOULD consider implementing the following 844 relevant DNS extensions 846 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 847 a DNS client does not include an EDNS0 Client Subnet Option with a 848 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 849 potentially leak client address information to the upstream 850 authoritative DNS servers. A DNS client ought to be able to 851 inform the DNS Resolver that it does not want any address 852 information leaked, and the DNS Resolver should honor that 853 request. 855 12. Acknowledgements 857 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 858 [RFC7858] for laying the ground work that this draft builds on and 859 for reviewing the contents. The authors would also like to thank 860 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 861 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman, Christian 862 Huitema and John Levine for review and discussion of the ideas 863 presented here. 865 13. References 867 13.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, 871 DOI 10.17487/RFC2119, March 1997, 872 . 874 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 875 "Transport Layer Security (TLS) Session Resumption without 876 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 877 January 2008, . 879 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 880 (TLS) Protocol Version 1.2", RFC 5246, 881 DOI 10.17487/RFC5246, August 2008, 882 . 884 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 885 Housley, R., and W. Polk, "Internet X.509 Public Key 886 Infrastructure Certificate and Certificate Revocation List 887 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 888 . 890 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 891 Verification of Domain-Based Application Service Identity 892 within Internet Public Key Infrastructure Using X.509 893 (PKIX) Certificates in the Context of Transport Layer 894 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 895 2011, . 897 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 898 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 899 January 2012, . 901 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 902 of Named Entities (DANE) Transport Layer Security (TLS) 903 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 904 2012, . 906 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 907 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 908 Transport Layer Security (TLS) and Datagram Transport 909 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 910 June 2014, . 912 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 913 "Recommendations for Secure Use of Transport Layer 914 Security (TLS) and Datagram Transport Layer Security 915 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 916 2015, . 918 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 919 Authentication of Named Entities (DANE) Protocol: Updates 920 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 921 October 2015, . 923 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 924 DOI 10.17487/RFC7830, May 2016, 925 . 927 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 928 and P. Hoffman, "Specification for DNS over Transport 929 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 930 2016, . 932 13.2. Informative References 934 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 936 [dnssec-trigger] 937 NLnetLabs, "Dnssec-Trigger", May 2014, 938 . 940 [I-D.ietf-dprive-dnsodtls] 941 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 942 over Datagram Transport Layer Security (DTLS)", draft- 943 ietf-dprive-dnsodtls-15 (work in progress), December 2016. 945 [I-D.ietf-tls-dnssec-chain-extension] 946 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 947 Record and DNSSEC Authentication Chain Extension for TLS", 948 draft-ietf-tls-dnssec-chain-extension-03 (work in 949 progress), March 2017. 951 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 952 RFC 2131, DOI 10.17487/RFC2131, March 1997, 953 . 955 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 956 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 957 . 959 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 960 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 961 DOI 10.17487/RFC3646, December 2003, 962 . 964 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 965 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 966 December 2014, . 968 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 969 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 970 2015, . 972 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 973 DOI 10.17487/RFC7626, August 2015, 974 . 976 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 977 Kumari, "Client Subnet in DNS Queries", RFC 7871, 978 DOI 10.17487/RFC7871, May 2016, 979 . 981 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 982 Layer Security (TLS) False Start", RFC 7918, 983 DOI 10.17487/RFC7918, August 2016, 984 . 986 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 987 (TLS) Cached Information Extension", RFC 7924, 988 DOI 10.17487/RFC7924, July 2016, 989 . 991 Appendix A. Server capability probing and caching by DNS clients 993 This section presents a non-normative discussion of how DNS clients 994 might probe for and cache privacy capabilities of DNS servers. 996 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 997 Not all servers will support one or both of these protocols and the 998 well-known port might be blocked by some middleboxes. Clients will 999 be expected to keep track of servers that support DNS-over-TLS and/or 1000 DNS-over-DTLS, and those that have been previously authenticated. 1002 If no server capability information is available then (unless 1003 otherwise specified by the configuration of the DNS client) DNS 1004 clients that implement both TLS and DTLS should try to authenticate 1005 using both protocols before failing or falling back to a lower 1006 security. DNS clients using opportunistic security should try all 1007 available servers (possibly in parallel) in order to obtain an 1008 authenticated encrypted connection before falling back to a lower 1009 security. (RATIONALE: This approach can increase latency while 1010 discovering server capabilities but maximizes the chance of sending 1011 the query over an authenticated encrypted connection.) 1013 Appendix B. Changes between revisions 1015 [Note to RFC Editor: please remove this section prior to 1016 publication.] 1018 B.1. -09 version 1020 Remove the SRV record to simplify the draft. 1022 Add suggestion that clients offer option to avoid using only PKIX 1023 authentication. 1025 Clarify that the MUST on implementing TLS session resumption updates 1026 RFC7858. 1028 Update page header to be '(D)TLS Authentication for TLS'. 1030 B.2. -08 version 1032 Removed hard failure as an option for Opportunistic Usage profile. 1034 Added a new section comparing the Authentication Mechanisms 1036 B.3. -07 version 1038 Re-work of the Abstract and Introduction to better describe the 1039 contents in this version. 1041 Terminology: New definition of 'authentication information'. 1043 Scope: Changes to the Scope section. 1045 Moved discussion of combining authentication mechanism earlier. 1047 Changes to the section headings and groupings to make the 1048 presentation more logical. 1050 B.4. -06 version 1052 Introduction: Re-word discussion of Working group charter. 1054 Introduction: Re-word first and third bullet point about 'obtaining' 1055 a domain name and IP address. 1057 Introduction: Update reference to DNS-over-TLS draft. 1059 Terminology: Change forwarder/proxy to just forwarder 1061 Terminology: Add definition of 'Authentication domain name' and use 1062 this throughout 1064 Section 4.2: Remove parenthesis in the table. 1066 Section 4.2: Change the text after the table as agreed with Paul 1067 Hoffman. 1069 Section 4.3.1: Change title and remove brackets around last 1070 statement. 1072 Section 11: Split second paragraph. 1074 B.5. -05 version 1076 Add more details on detecting passive attacks to section 4.2 1078 Changed X.509 to PKIX throughout 1080 Change comment about future I-D on usage policies. 1082 B.6. -04 version 1084 Introduction: Add comment that DNS-over-DTLS draft is Experiments 1086 Update 2 I-D references to RFCs. 1088 B.7. -03 version 1090 Section 9: Update DANE section with better references to RFC7671 and 1091 RFC7250 1093 B.8. -02 version 1095 Introduction: Added paragraph on the background and scope of the 1096 document. 1098 Introduction and Discussion: Added more information on what a Usage 1099 profiles is (and is not) the the two presented here. 1101 Introduction: Added paragraph to make a comparison with the Strict 1102 profile in RFC7858 clearer. 1104 Section 4.2: Re-worked the description of Opportunistic and the 1105 table. 1107 Section 8.3: Clarified statement about use of DHCP in Opportunistic 1108 profile 1110 Title abbreviated. 1112 B.9. -01 version 1114 Section 4.2: Make clear that the Strict Privacy Profile can include 1115 meta queries performed using Opportunistic Privacy. 1117 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 1118 does not guarantee protection against passive attack. 1120 Section 4.2: Add sentence discussing client/provider trusted 1121 relationships. 1123 Section 5: Add more discussion of detection of active attacks when 1124 using Opportunistic Privacy. 1126 Section 8.2: Clarify description and example. 1128 B.10. draft-ietf-dprive-dtls-and-tls-profiles-00 1130 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1131 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1132 fixed. 1134 Authors' Addresses 1136 Sara Dickinson 1137 Sinodun Internet Technologies 1138 Magdalen Centre 1139 Oxford Science Park 1140 Oxford OX4 4GA 1141 UK 1143 Email: sara@sinodun.com 1144 URI: http://sinodun.com 1146 Daniel Kahn Gillmor 1147 ACLU 1148 125 Broad Street, 18th Floor 1149 New York NY 10004 1150 USA 1152 Email: dkg@fifthhorseman.net 1154 Tirumaleswar Reddy 1155 Cisco Systems, Inc. 1156 Cessna Business Park, Varthur Hobli 1157 Sarjapur Marathalli Outer Ring Road 1158 Bangalore, Karnataka 560103 1159 India 1161 Email: tireddy@cisco.com