idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-03.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 (July 8, 2016) is 2850 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 (-15) exists of draft-ietf-dprive-dnsodtls-06 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-00 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 5 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: January 9, 2017 ACLU 6 T. Reddy 7 Cisco 8 July 8, 2016 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-03 13 Abstract 15 This document describes how a DNS client can use a domain name to 16 authenticate a DNS server that uses Transport Layer Security (TLS) 17 and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles 18 for DNS clients and servers implementing DNS-over-TLS and DNS-over- 19 DTLS. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 9, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6 61 4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8 62 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 8 63 4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 8 64 4.3.2. Credential Verification . . . . . . . . . . . . . . . 8 65 4.3.3. Implementation guidance . . . . . . . . . . . . . . . 9 66 5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 9 67 6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 9 68 7. In Band Source of Domain Name: SRV Service Label . . . . . . 10 69 8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 10 70 8.1. Full direct configuration . . . . . . . . . . . . . . . . 10 71 8.2. Direct configuration of name only . . . . . . . . . . . . 10 72 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 74 9.1. X.509 Certificate Based Authentication . . . . . . . . . 12 75 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 13 77 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 13 78 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 79 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 14 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 15 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 15.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Appendix A. Server capability probing and caching by DNS clients 19 88 Appendix B. Changes between revisions . . . . . . . . . . . . . 19 89 B.1. -03 version . . . . . . . . . . . . . . . . . . . . . . . 19 90 B.2. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19 91 B.3. -01 version . . . . . . . . . . . . . . . . . . . . . . . 20 92 B.4. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 DNS Privacy issues are discussed in [RFC7626]. Two documents that 98 provide DNS privacy between DNS clients and DNS servers are: 100 o Specification for DNS over Transport Layer Security (TLS) 101 [RFC7858], referred to here as simply 'DNS-over-TLS' 103 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 104 simply as 'DNS-over-DTLS' 106 Both documents are limited in scope to encrypting DNS messages 107 between stub clients and recursive resolvers and the same scope is 108 applied to this document (see Section 2 and Section 3). The 109 proposals here might be adapted or extended in future to be used for 110 recursive clients and authoritative servers, but this application is 111 out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per 112 its current charter. 114 This document defines two Usage Profiles (Strict and Opportunistic) 115 for DTLS [RFC6347] and TLS [RFC5246] which define the security 116 properties a user should expect when using that profile to connect to 117 the available DNS servers. In essence: 119 o the Strict Profile requires an encrypted connection and successful 120 authentication of the DNS server which provides strong privacy 121 guarantees (at the expense of providing no DNS service if this is 122 not available). 124 o the Opportunistic Profile will attempt, but does not require, 125 encryption and successful authentication; it therefore provides no 126 privacy guarantees but offers maximum chance of DNS service. 128 Additionally, a number of authentication mechanisms are defined that 129 specify how a DNS client should authenticate a DNS server based on a 130 domain name. In particular, the following is described: 132 o How a DNS client can obtain a domain name for a DNS server to use 133 for (D)TLS authentication. 135 o What are the acceptable credentials a DNS server can present to 136 prove its identity for (D)TLS authentication based on a given 137 domain name. 139 o How a DNS client can verify that any given credential matches the 140 domain name obtained for a DNS server. 142 It should be noted that [RFC7858] includes a description of a 143 specific case of a Strict Usage Profile using a single authentication 144 mechanism (SPKI pinning). This draft generalises the picture by 145 separating the Usage Profile, which is based purely on the security 146 properties it offers the user, from the specific mechanism that is 147 used for authentication. Therefore the "Out-of-band Key-pinned 148 Privacy Profile" described in the DNS-over-TLS draft would qualify as 149 a "Strict Usage Profile" that used SPKI pinning for authentication. 151 This document also defines a (D)TLS protocol profile for use with 152 DNS. This profile defines the configuration options and protocol 153 extensions required of both parties to optimize connection 154 establishment and session resumption for transporting DNS, and to 155 support the authentication mechanisms defined here. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 Several terms are used specifically in the context of this draft: 165 o DNS client: a DNS stub resolver or forwarder/proxy. In the case 166 of a forwarder, the term "DNS client" is used to discuss the side 167 that sends queries. 169 o DNS server: a DNS recursive resolver or forwarder/proxy. In the 170 case of a forwarder, the term "DNS server" is used to discuss the 171 side that responds to queries. 173 o Privacy-enabling DNS server: A DNS server that: 175 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 176 over-DTLS [I-D.ietf-dprive-dnsodtls]. 178 * Can offer at least one of the credentials described in 179 Section 9. 181 * Implements the (D)TLS profile described in Section 11. 183 o (D)TLS: For brevity this term is used for statements that apply to 184 both Transport Layer Security [RFC5246] and Datagram Transport 185 Layer Security [RFC6347]. Specific terms will be used for any 186 statement that applies to either protocol alone. 188 o DNS-over-(D)TLS: For brevity this term is used for statements that 189 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 191 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 192 statement that applies to either protocol alone. 194 o Credential: Information available for a DNS server which proves 195 its identity for authentication purposes. Credentials discussed 196 here include: 198 * X.509 certificate 200 * DNSSEC validated chain to a TLSA record 202 but may also include SPKI pinsets. 204 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 205 to "pin" public key information in a manner similar to HPKP 206 [RFC7469]. An SPKI pinset is a collection of these pins that 207 constrains a DNS server. 209 o Reference Identifier: a Reference Identifier as described in 210 [RFC6125], constructed by the DNS client when performing TLS 211 authentication of a DNS server. 213 3. Scope 215 This document is limited to domain-name-based authentication of DNS 216 servers by DNS clients (as defined in the terminology section), and 217 the (D)TLS profiles needed to support this. As such, the following 218 things are out of scope: 220 o Authentication of authoritative servers by recursive resolvers. 222 o Authentication of DNS clients by DNS servers. 224 o SPKI-pinset-based authentication. This is defined in [RFC7858]. 225 However, Section 10 does describe how to combine that approach 226 with the domain name based mechanism described here. 228 o Any server identifier other than domain names, including IP 229 address, organizational name, country of origin, etc. 231 4. Discussion 233 4.1. Background 235 To protect against passive attacks DNS privacy requires encrypting 236 the query (and response). Such encryption typically provides 237 integrity protection as a side-effect, which means on-path attackers 238 cannot simply inject bogus DNS responses. For DNS privacy to also 239 provide protection against active attackers pretending to be the 240 server, the client must authenticate the server. 242 This draft discusses Usage Profiles, which provide differing levels 243 of privacy guarantees to DNS clients, based on the requirements for 244 authentication and encryption, regardless of the context (for 245 example, which network the client is connected to). A Usage Profile 246 is a distinct concept to a usage policy or usage model, which might 247 dictate which Profile should be used in a particular context 248 (enterprise vs coffee shop), with a particular set of DNS Servers or 249 with reference to other external factors. A description of the 250 variety of usage policies is out of scope of this document, but may 251 be the subject of a future I-D. 253 4.2. Usage Profiles 255 A DNS client has a choice of privacy usage profiles available. This 256 choice is briefly discussed in both [RFC7858] and 257 [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 259 o Strict Privacy: the DNS client requires both an encrypted and 260 authenticated connection to a privacy-enabling DNS Server. A hard 261 failure occurs if this is not available. This requires the client 262 to securely obtain information it can use to authenticate the 263 server. This profile can include some initial meta queries 264 (performed using Opportunistic Privacy) to securely obtain the IP 265 address and authentication information for the privacy-enabling 266 DNS server to which the DNS client will subsequently connect. The 267 rationale for this is that requiring Strict Privacy for such meta 268 queries would introduce significant deployment obstacles. This 269 profile provides strong privacy guarantees to the client. This is 270 discussed in detail in Section 6. 272 o Opportunistic Privacy: the DNS client uses Opportunistic Security 273 as described in [RFC7435] 275 "... the use of cleartext as the baseline communication 276 security policy, with encryption and authentication negotiated 277 and applied to the communication when available." 279 The use of Opportunistic Privacy is intended to support 280 incremental deployment of security capabilities with a view to 281 widespread adoption of Strict Privacy. It should be employed when 282 the DNS client might otherwise settle for cleartext; it provides 283 the maximum protection available. As described in [RFC7435] it 284 might result in 286 * an encrypted and authenticated connection 287 * an encrypted connection 289 * a clear text connection 291 * hard failure 293 depending on the fallback logic of the client, the available 294 authentication information and the capabilities of the DNS Server. 295 In the first three cases the DNS client is willing to continue 296 with a connection to the DNS Server and perform resolution of 297 queries. 299 To compare the two Usage profiles the table below shows successful 300 Strict Privacy along side the 3 possible successful outcomes of 301 Opportunistic Privacy. In the best case scenario for Opportunistic 302 (authenticated and encrypted connection) it is equivalent to Strict 303 Privacy. In the worst case scenario it is equivalent to clear text. 304 Clients using Opportunistic Privacy SHOULD try for the best case but 305 MAY fallback to intermediate cases and eventually the worst case 306 scenario in order to obtain a response. It therefore provides no 307 privacy guarantee to the user and varying protection depending on 308 what kind of connection is actually used. Note that there is no 309 requirement in Opportunistic to notify the user what type of 310 connection is actually used, the detection described below is only 311 possible if such connection information is available. This is 312 discussed in Section 5. 314 +---------------+------------+------------------+-----------------+ 315 | Usage Profile | Connection | Passive Attacker | Active Attacker | 316 +---------------+------------+------------------+-----------------+ 317 | Strict | A, E | P | P | 318 | Opportunistic | A, E | P | P | 319 | Opportunistic | E | P | N (D) | 320 | Opportunistic | | N (D) | N (D) | 321 +---------------+------------+------------------+-----------------+ 323 P == protection; N == no protection; D == detection is possible; A == 324 Authenticated Connection; E == Encrypted Connection 326 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 328 Since Strict Privacy provides the strongest privacy guarantees it is 329 preferable to Opportunistic Privacy. 331 However since the two profiles require varying levels of 332 configuration (or a trusted relationship with a provider) and DNS 333 server capabilities, DNS clients will need to carefully select which 334 profile to use based on their communication privacy needs. For the 335 case where a client has a trusted relationship with a provider it is 336 expected that the provider will provide either a domain name or SPKI 337 pinset via a secure out-of-band mechanism and therefore Strict 338 Privacy should be used. 340 4.2.1. DNS Resolution 342 A DNS client SHOULD select a particular usage profile when resolving 343 a query. A DNS client MUST NOT fallback from Strict Privacy to 344 Opportunistic Privacy during the resolution process as this could 345 invalidate the protection offered against active attackers. 347 4.3. Authentication 349 This document describes authentication mechanisms that can be used in 350 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 352 4.3.1. DNS-over-(D)TLS Bootstrapping Problems 354 Many (D)TLS clients use PKIX authentication [RFC6125] based on a 355 domain name for the server they are contacting. These clients 356 typically first look up the server's network address in the DNS 357 before making this connection. A DNS client therefore has a 358 bootstrap problem. DNS clients typically know only the IP address of 359 a DNS server. 361 As such, before connecting to a DNS server, a DNS client needs to 362 learn the domain name it should associate with the IP address of a 363 DNS server for authentication purposes. Sources of domains names are 364 discussed in Section 7 and Section 8. 366 One advantage of this domain name based approach is that it 367 encourages association of stable, human recognisable identifiers with 368 secure DNS service providers. 370 4.3.2. Credential Verification 372 The use of SPKI pinset verification is discussed in [RFC7858]. 374 In terms of domain name based verification, once a domain name is 375 known for a DNS server a choice of mechanisms can be used for 376 authentication. Section 9 discusses these mechanisms in detail, 377 namely X.509 certificate based authentication and DANE. 379 Note that the use of DANE adds requirements on the ability of the 380 client to get validated DNSSEC results. This is discussed in more 381 detail in Section 9.2. 383 4.3.3. Implementation guidance 385 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 386 Additional considerations relating to general implementation 387 guidelines are discussed in both Section 13 and in Appendix A. 389 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 391 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 392 which MAY be used for DNS-over-(D)TLS. 394 DNS clients issuing queries under an opportunistic profile which know 395 of a domain name or SPKI pinset for a given privacy-enabling DNS 396 server MAY choose to try to authenticate the server using the 397 mechanisms described here. This is useful for detecting (but not 398 preventing) active attack, since the fact that authentication 399 information is available indicates that the server in question is a 400 privacy-enabling DNS server to which it should be possible to 401 establish an authenticated, encrypted connection. In this case, 402 whilst a client cannot know the reason for an authentication failure, 403 from a privacy standpoint the client should consider an active attack 404 in progress and proceed under that assumption. Attempting 405 authentication is also useful for debugging or diagnostic purposes if 406 there are means to report the result. This information can provide a 407 basis for a DNS client to switch to (preferred) Strict Privacy where 408 it is viable. 410 6. Authentication in Strict DNS-over(D)TLS Privacy 412 To authenticate a privacy-enabling DNS server, a DNS client needs to 413 know the domain name for each server it is willing to contact. This 414 is necessary to protect against active attacks on DNS privacy. 416 A DNS client requiring Strict Privacy MUST either use one of the 417 sources listed in Section 8 to obtain a domain name for the server it 418 contacts, or use an SPKI pinset as described in [RFC7858]. 420 A DNS client requiring Strict Privacy MUST only attempt to connect to 421 DNS servers for which either a domain name or a SPKI pinset is known 422 (or both). The client MUST use the available verification mechanisms 423 described in Section 9 to authenticate the server, and MUST abort 424 connections to a server when no verification mechanism succeeds. 426 With Strict Privacy, the DNS client MUST NOT commence sending DNS 427 queries until at least one of the privacy-enabling DNS servers 428 becomes available. 430 A privacy-enabling DNS server may be temporarily unavailable when 431 configuring a network. For example, for clients on networks that 432 require registration through web-based login (a.k.a. "captive 433 portals"), such registration may rely on DNS interception and 434 spoofing. Techniques such as those used by DNSSEC-trigger 435 [dnssec-trigger] MAY be used during network configuration, with the 436 intent to transition to the designated privacy-enabling DNS servers 437 after captive portal registration. The system MUST alert by some 438 means that the DNS is not private during such bootstrap. 440 7. In Band Source of Domain Name: SRV Service Label 442 This specification adds a SRV service label "domain-s" for privacy- 443 enabling DNS servers. 445 Example service records (for TLS and DTLS respectively): 447 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 448 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 450 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 452 8. Out of Band Sources of Domain Name 454 8.1. Full direct configuration 456 DNS clients may be directly and securely provisioned with the domain 457 name of each privacy-enabling DNS server. For example, using a 458 client specific configuration file or API. 460 In this case, direct configuration for a DNS client would consist of 461 both an IP address and a domain name for each DNS server. 463 8.2. Direct configuration of name only 465 A DNS client may be configured directly and securely with only the 466 domain name of its privacy-enabling DNS server. For example, using a 467 client specific configuration file or API. 469 A DNS client might learn of a default recursive DNS resolver from an 470 untrusted source (such as DHCP's DNS server option [RFC3646]). It 471 can then use opportunistic DNS connections to untrusted recursive DNS 472 resolver to establish the IP address of the intended privacy-enabling 473 DNS server by doing a lookup of SRV records. Such records MUST be 474 validated using DNSSEC. Private DNS resolution can now be done by 475 the DNS client against the configured privacy-enabling DNS server. 477 Example: 479 o A DNSSEC validating DNS client is configured with the domain name 480 dns.example.net for a privacy-enabling DNS server 482 o Using Opportunistic Privacy to a default DNS resolver (acquired, 483 for example, using DHCP) the client performs look ups for 485 * SRV record for _domain-s._tcp.dns.example.net to obtain the 486 server host name 488 * A and/or AAAA lookups to obtain IP address for the server host 489 name 491 o Client validates all the records obtained in the previous step 492 using DNSSEC. 494 o If the records successfully validate the client proceeds to 495 connect to the privacy-enabling DNS server using Strict Privacy. 497 A DNS client so configured that successfully connects to a privacy- 498 enabling DNS server MAY choose to locally cache the looked up 499 addresses in order to not have to repeat the opportunistic lookup. 501 8.3. DHCP 503 Some clients may have an established trust relationship with a known 504 DHCP [RFC2131] server for discovering their network configuration. 505 In the typical case, such a DHCP server provides a list of IP 506 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 507 not provide a domain name for the DNS server itself. 509 In the future, a DHCP server might use a DHCP extension to provide a 510 list of domain names for the offered DNS servers, which correspond to 511 IP addresses listed. 513 Use of such a mechanism with any DHCP server when using an 514 Opportunistic profile is reasonable, given the security expectation 515 of that profile. However when using a Strict profile the DHCP 516 servers used as sources of domain names MUST be considered secure and 517 trustworthy. This document does not attempt to describe secured and 518 trusted relationships to DHCP servers. 520 [NOTE: It is noted (at the time of writing) that whilst some 521 implementation work is in progress to secure IPv6 connections for 522 DHCP, IPv4 connections have received little to no implementation 523 attention in this area.] 525 9. Credential Verification 527 9.1. X.509 Certificate Based Authentication 529 When a DNS client configured with a domain name connects to its 530 configured DNS server over (D)TLS, the server may present it with an 531 X.509 certificate. In order to ensure proper authentication, DNS 532 clients MUST verify the entire certification path per [RFC5280]. The 533 DNS client additionally uses [RFC6125] validation techniques to 534 compare the domain name to the certificate provided. 536 A DNS client constructs two Reference Identifiers for the server 537 based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- 538 ID is simply the domain name itself. The SRV-ID uses a "_domain-s." 539 prefix. So if the configured domain name is "dns.example.com", then 540 the two Reference Identifiers are: 542 DNS-ID: dns.example.com 544 SRV-ID: _domain-s.dns.example.com 546 If either of the Reference Identifiers are found in the X.509 547 certificate's subjectAltName extension as described in section 6 of 548 [RFC6125], the DNS client should accept the certificate for the 549 server. 551 A compliant DNS client MUST only inspect the certificate's 552 subjectAltName extension for these Reference Identifiers. In 553 particular, it MUST NOT inspect the Subject field itself. 555 9.2. DANE 557 DANE [RFC6698] provides mechanisms to root certificate and raw public 558 key trust with DNSSEC. However this requires the DNS client to have 559 a domain name for the DNS Privacy Server which must be obtained via a 560 trusted source. 562 This section assumes a solid understanding of both DANE [RFC6698] and 563 DANE Operations [RFC7671]. A few pertinent issues covered in these 564 documents are outlined here as useful pointers, but familiarity with 565 both these documents in their entirety is expected. 567 It is noted that [RFC6698] says 569 "Clients that validate the DNSSEC signatures themselves MUST use 570 standard DNSSEC validation procedures. Clients that rely on 571 another entity to perform the DNSSEC signature validation MUST use 572 a secure mechanism between themselves and the validator." 574 It is noted that [RFC7671] covers the following topics: 576 o Section 4.1: Opportunistic Security and PKIX Usages and 577 Section 14: Security Considerations, which both discuss the use of 578 PKIX-TA(0) and PKIX-EE(1) for OS. 580 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 581 Specifically Section 5.1 which outlines the combination of 582 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 583 Public Keys [RFC7250]. Section 5.1 also discusses the security 584 implications of this mode, for example, it discusses key lifetimes 585 and specifies that validity period enforcement is based solely on 586 the TLSA RRset properties for this case. [QUESTION: Should an 587 appendix be added with an example of how to use DANE without X.509 588 certificates?] 590 o Section 13: Operational Considerations, which discusses TLSA TTLs 591 and signature validity periods. 593 The specific DANE record for a DNS Privacy Server would take the 594 form: 596 _853._tcp.[server-domain-name] for TLS 598 _853._udp.[server-domain-name] for DTLS 600 9.2.1. Direct DNS Lookup 602 The DNS client MAY choose to perform the DNS lookups to retrieve the 603 required DANE records itself. The DNS queries for such DANE records 604 MAY use opportunistic encryption or be in the clear to avoid trust 605 recursion. The records MUST be validated using DNSSEC as described 606 above in [RFC6698]. 608 9.2.2. TLS DNSSEC Chain extension 610 The DNS client MAY offer the TLS extension described in 611 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 612 this extension, it can provide the full chain to the client in the 613 handshake. 615 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 616 capable of validating the full DNSSEC authentication chain down to 617 the leaf. If the supplied DNSSEC chain does not validate, the client 618 MUST ignore the DNSSEC chain and validate only via other supplied 619 credentials. 621 10. Combined Credentials with SPKI Pinsets 623 The SPKI pinset profile described in [RFC7858] MAY be used with DNS- 624 over-(D)TLS. 626 This draft does not make explicit recommendations about how a SPKI 627 pinset based authentication mechanism should be combined with a 628 domain based mechanism from an operator perspective. However it can 629 be envisaged that a DNS server operator may wish to make both an SPKI 630 pinset and a domain name available to allow clients to choose which 631 mechanism to use. Therefore, the following is guidance on how 632 clients ought to behave if they choose to configure both, as is 633 possible in HPKP [RFC7469]. 635 A DNS client that is configured with both a domain name and a SPKI 636 pinset for a DNS sever SHOULD match on both a valid credential for 637 the domain name and a valid SPKI pinset when connecting to that DNS 638 server. 640 11. (D)TLS Protocol Profile 642 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 644 There are known attacks on (D)TLS, such as machine-in-the-middle and 645 protocol downgrade. These are general attacks on (D)TLS and not 646 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 647 discussion of these security issues. Clients and servers MUST adhere 648 to the (D)TLS implementation recommendations and security 649 considerations of [RFC7525] except with respect to (D)TLS version. 650 Since encryption of DNS using (D)TLS is virtually a green-field 651 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 652 later. 654 Implementations MUST NOT offer or provide TLS compression, since 655 compression can leak significant amounts of information, especially 656 to a network observer capable of forcing the user to do an arbitrary 657 DNS lookup in the style of the CRIME attacks [CRIME]. 659 Implementations compliant with this profile MUST implement all of the 660 following items: 662 o TLS session resumption without server-side state [RFC5077] which 663 eliminates the need for the server to retain cryptographic state 664 for longer than necessary. 666 o Raw public keys [RFC7250] which reduce the size of the 667 ServerHello, and can be used by servers that cannot obtain 668 certificates (e.g., DNS servers on private networks). 670 Implementations compliant with this profile SHOULD implement all of 671 the following items: 673 o TLS False Start [I-D.ietf-tls-falsestart] which reduces round- 674 trips by allowing the TLS second flight of messages 675 (ChangeCipherSpec) to also contain the (encrypted) DNS query 677 o Cached Information Extension [I-D.ietf-tls-cached-info] which 678 avoids transmitting the server's certificate and certificate chain 679 if the client has cached that information from a previous TLS 680 handshake 682 [NOTE: The references to (works in progress) should be upgraded to 683 MUST's if those references become RFC's prior to publication of this 684 document.] 686 Guidance specific to TLS is provided in [RFC7858] and that specific 687 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 689 12. IANA Considerations 691 This memo includes no request to IANA. 693 13. Security Considerations 695 Security considerations discussed in [RFC7525], 696 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 698 13.1. Counter-measures to DNS Traffic Analysis 700 This section makes suggestions for measures that can reduce the 701 ability of attackers to infer information pertaining to encrypted 702 client queries by other means (e.g. via an analysis of encrypted 703 traffic size, or via monitoring of resolver to authoritative 704 traffic). 706 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 707 following relevant DNS extensions 709 o EDNS(0) padding [RFC7830], which allows encrypted queries and 710 responses to hide their size. 712 DNS-over-(D)TLS clients SHOULD consider implementing the following 713 relevant DNS extensions 715 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 716 a DNS client does not include an EDNS0 Client Subnet Option with a 717 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 718 potentially leak client address information to the upstream 719 authoritative DNS servers. A DNS client ought to be able to 720 inform the DNS Resolver that it does not want any address 721 information leaked, and the DNS Resolver should honor that 722 request. 724 14. Acknowledgements 726 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 727 [RFC7858] for laying the ground work that this draft builds on and 728 for reviewing the contents. The authors would also like to thank 729 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 730 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and 731 Christian Huitema for review and discussion of the ideas presented 732 here. 734 15. References 736 15.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 740 DOI 10.17487/RFC2119, March 1997, 741 . 743 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 744 Subject Alternative Name for Expression of Service Name", 745 RFC 4985, DOI 10.17487/RFC4985, August 2007, 746 . 748 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 749 "Transport Layer Security (TLS) Session Resumption without 750 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 751 January 2008, . 753 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 754 (TLS) Protocol Version 1.2", RFC 5246, 755 DOI 10.17487/RFC5246, August 2008, 756 . 758 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 759 Housley, R., and W. Polk, "Internet X.509 Public Key 760 Infrastructure Certificate and Certificate Revocation List 761 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 762 . 764 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 765 Verification of Domain-Based Application Service Identity 766 within Internet Public Key Infrastructure Using X.509 767 (PKIX) Certificates in the Context of Transport Layer 768 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 769 2011, . 771 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 772 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 773 January 2012, . 775 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 776 of Named Entities (DANE) Transport Layer Security (TLS) 777 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 778 2012, . 780 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 781 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 782 Transport Layer Security (TLS) and Datagram Transport 783 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 784 June 2014, . 786 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 787 "Recommendations for Secure Use of Transport Layer 788 Security (TLS) and Datagram Transport Layer Security 789 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 790 2015, . 792 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 793 Authentication of Named Entities (DANE) Protocol: Updates 794 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 795 October 2015, . 797 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 798 DOI 10.17487/RFC7830, May 2016, 799 . 801 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 802 and P. Hoffman, "Specification for DNS over Transport 803 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 804 2016, . 806 15.2. Informative References 808 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 810 [dnssec-trigger] 811 NLnetLabs, "Dnssec-Trigger", May 2014, 812 . 814 [I-D.ietf-dprive-dnsodtls] 815 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 816 (DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in 817 progress), April 2016. 819 [I-D.ietf-tls-cached-info] 820 Santesson, S. and H. Tschofenig, "Transport Layer Security 821 (TLS) Cached Information Extension", draft-ietf-tls- 822 cached-info-23 (work in progress), May 2016. 824 [I-D.ietf-tls-dnssec-chain-extension] 825 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 826 Record and DNSSEC Authentication Chain Extension for TLS", 827 draft-ietf-tls-dnssec-chain-extension-00 (work in 828 progress), June 2016. 830 [I-D.ietf-tls-falsestart] 831 Langley, A., Modadugu, N., and B. Moeller, "Transport 832 Layer Security (TLS) False Start", draft-ietf-tls- 833 falsestart-02 (work in progress), May 2016. 835 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 836 RFC 2131, DOI 10.17487/RFC2131, March 1997, 837 . 839 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 840 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 841 . 843 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 844 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 845 DOI 10.17487/RFC3646, December 2003, 846 . 848 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 849 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 850 December 2014, . 852 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 853 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 854 2015, . 856 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 857 DOI 10.17487/RFC7626, August 2015, 858 . 860 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 861 Kumari, "Client Subnet in DNS Queries", RFC 7871, 862 DOI 10.17487/RFC7871, May 2016, 863 . 865 Appendix A. Server capability probing and caching by DNS clients 867 This section presents a non-normative discussion of how DNS clients 868 might probe for and cache privacy capabilities of DNS servers. 870 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 871 Not all servers will support one or both of these protocols and the 872 well-known port might be blocked by some middleboxes. Clients will 873 be expected to keep track of servers that support DNS-over-TLS and/or 874 DNS-over-DTLS, and those that have been previously authenticated. 876 If no server capability information is available then (unless 877 otherwise specified by the configuration of the DNS client) DNS 878 clients that implement both TLS and DTLS should try to authenticate 879 using both protocols before failing or falling back to a lower 880 security. DNS clients using opportunistic security should try all 881 available servers (possibly in parallel) in order to obtain an 882 authenticated encrypted connection before falling back to a lower 883 security. (RATIONALE: This approach can increase latency while 884 discovering server capabilities but maximizes the chance of sending 885 the query over an authenticated encrypted connection.) 887 Appendix B. Changes between revisions 889 [Note to RFC Editor: please remove this section prior to 890 publication.] 892 B.1. -03 version 894 Section 9: Update DANE section with better references to RFC7671 and 895 RFC7250 897 B.2. -02 version 899 Introduction: Added paragraph on the background and scope of the 900 document. 902 Introduction and Discussion: Added more information on what a Usage 903 profiles is (and is not) the the two presented here. 905 Introduction: Added paragraph to make a comparison with the Strict 906 profile in RFC7858 clearer. 908 Section 4.2: Re-worked the description of Opportunistic and the 909 table. 911 Section 8.3: Clarified statement about use of DHCP in Opportunistic 912 profile 914 Title abbreviated. 916 B.3. -01 version 918 Section 4.2: Make clear that the Strict Privacy Profile can include 919 meta queries performed using Opportunistic Privacy. 921 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 922 does not guarantee protection against passive attack. 924 Section 4.2: Add sentence discussing client/provider trusted 925 relationships. 927 Section 5: Add more discussion of detection of active attacks when 928 using Opportunistic Privacy. 930 Section 8.2: Clarify description and example. 932 B.4. draft-ietf-dprive-dtls-and-tls-profiles-00 934 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 935 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 936 fixed. 938 Authors' Addresses 940 Sara Dickinson 941 Sinodun Internet Technologies 942 Magdalen Centre 943 Oxford Science Park 944 Oxford OX4 4GA 945 UK 947 Email: sara@sinodun.com 948 URI: http://sinodun.com 949 Daniel Kahn Gillmor 950 ACLU 951 125 Broad Street, 18th Floor 952 New York NY 10004 953 USA 955 Email: dkg@fifthhorseman.net 957 Tirumaleswar Reddy 958 Cisco Systems, Inc. 959 Cessna Business Park, Varthur Hobli 960 Sarjapur Marathalli Outer Ring Road 961 Bangalore, Karnataka 560103 962 India 964 Email: tireddy@cisco.com