idnits 2.17.00 (12 Aug 2021) /tmp/idnits31516/draft-ietf-dprive-dtls-and-tls-profiles-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2016) is 2039 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-dprive-dnsodtls has been published as RFC 8094 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-01 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun 4 Intended status: Standards Track D. Gillmor 5 Expires: April 23, 2017 ACLU 6 T. Reddy 7 Cisco 8 October 20, 2016 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-05 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 April 23, 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 . . . . . . . . . . . . . . . 9 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 . . . . . . . 10 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 . . . . . . . . . . . . . . . . 11 71 8.2. Direct configuration of name only . . . . . . . . . . . . 11 72 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 74 9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12 75 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14 77 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14 78 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 79 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16 83 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 15.2. Informative References . . . . . . . . . . . . . . . . . 18 87 Appendix A. Server capability probing and caching by DNS clients 19 88 Appendix B. Changes between revisions . . . . . . . . . . . . . 20 89 B.1. -05 version . . . . . . . . . . . . . . . . . . . . . . . 20 90 B.2. -04 version . . . . . . . . . . . . . . . . . . . . . . . 20 91 B.3. -03 version . . . . . . . . . . . . . . . . . . . . . . . 20 92 B.4. -02 version . . . . . . . . . . . . . . . . . . . . . . . 20 93 B.5. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21 94 B.6. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 DNS Privacy issues are discussed in [RFC7626]. Two documents that 100 provide DNS privacy between DNS clients and DNS servers are: 102 o Specification for DNS over Transport Layer Security (TLS) 103 [RFC7858], referred to here as simply 'DNS-over-TLS' 105 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 106 simply as 'DNS-over-DTLS'. Note that this document has the 107 Intended status of Experimental. 109 Both documents are limited in scope to encrypting DNS messages 110 between stub clients and recursive resolvers and the same scope is 111 applied to this document (see Section 2 and Section 3). The 112 proposals here might be adapted or extended in future to be used for 113 recursive clients and authoritative servers, but this application is 114 out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per 115 its current charter. 117 This document defines two Usage Profiles (Strict and Opportunistic) 118 for DTLS [RFC6347] and TLS [RFC5246] which define the security 119 properties a user should expect when using that profile to connect to 120 the available DNS servers. In essence: 122 o the Strict Profile requires an encrypted connection and successful 123 authentication of the DNS server which provides strong privacy 124 guarantees (at the expense of providing no DNS service if this is 125 not available). 127 o the Opportunistic Profile will attempt, but does not require, 128 encryption and successful authentication; it therefore provides no 129 privacy guarantees but offers maximum chance of DNS service. 131 Additionally, a number of authentication mechanisms are defined that 132 specify how a DNS client should authenticate a DNS server based on a 133 domain name. In particular, the following is described: 135 o How a DNS client can obtain a domain name for a DNS server to use 136 for (D)TLS authentication. 138 o What are the acceptable credentials a DNS server can present to 139 prove its identity for (D)TLS authentication based on a given 140 domain name. 142 o How a DNS client can verify that any given credential matches the 143 domain name obtained for a DNS server. 145 It should be noted that [RFC7858] includes a description of a 146 specific case of a Strict Usage Profile using a single authentication 147 mechanism (SPKI pinning). This draft generalises the picture by 148 separating the Usage Profile, which is based purely on the security 149 properties it offers the user, from the specific mechanism that is 150 used for authentication. Therefore the "Out-of-band Key-pinned 151 Privacy Profile" described in the DNS-over-TLS draft would qualify as 152 a "Strict Usage Profile" that used SPKI pinning for authentication. 154 This document also defines a (D)TLS protocol profile for use with 155 DNS. This profile defines the configuration options and protocol 156 extensions required of both parties to optimize connection 157 establishment and session resumption for transporting DNS, and to 158 support the authentication mechanisms defined here. 160 2. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 Several terms are used specifically in the context of this draft: 168 o DNS client: a DNS stub resolver or forwarder/proxy. In the case 169 of a forwarder, the term "DNS client" is used to discuss the side 170 that sends queries. 172 o DNS server: a DNS recursive resolver or forwarder/proxy. In the 173 case of a forwarder, the term "DNS server" is used to discuss the 174 side that responds to queries. 176 o Privacy-enabling DNS server: A DNS server that: 178 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 179 over-DTLS [I-D.ietf-dprive-dnsodtls]. 181 * Can offer at least one of the credentials described in 182 Section 9. 184 * Implements the (D)TLS profile described in Section 11. 186 o (D)TLS: For brevity this term is used for statements that apply to 187 both Transport Layer Security [RFC5246] and Datagram Transport 188 Layer Security [RFC6347]. Specific terms will be used for any 189 statement that applies to either protocol alone. 191 o DNS-over-(D)TLS: For brevity this term is used for statements that 192 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 194 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 195 statement that applies to either protocol alone. 197 o Credential: Information available for a DNS server which proves 198 its identity for authentication purposes. Credentials discussed 199 here include: 201 * PKIX certificate 203 * DNSSEC validated chain to a TLSA record 205 but may also include SPKI pinsets. 207 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 208 to "pin" public key information in a manner similar to HPKP 209 [RFC7469]. An SPKI pinset is a collection of these pins that 210 constrains a DNS server. 212 o Reference Identifier: a Reference Identifier as described in 213 [RFC6125], constructed by the DNS client when performing TLS 214 authentication of a DNS server. 216 3. Scope 218 This document is limited to domain-name-based authentication of DNS 219 servers by DNS clients (as defined in the terminology section), and 220 the (D)TLS profiles needed to support this. As such, the following 221 things are out of scope: 223 o Authentication of authoritative servers by recursive resolvers. 225 o Authentication of DNS clients by DNS servers. 227 o SPKI-pinset-based authentication. This is defined in [RFC7858]. 228 However, Section 10 does describe how to combine that approach 229 with the domain name based mechanism described here. 231 o Any server identifier other than domain names, including IP 232 address, organizational name, country of origin, etc. 234 4. Discussion 236 4.1. Background 238 To protect against passive attacks DNS privacy requires encrypting 239 the query (and response). Such encryption typically provides 240 integrity protection as a side-effect, which means on-path attackers 241 cannot simply inject bogus DNS responses. For DNS privacy to also 242 provide protection against active attackers pretending to be the 243 server, the client must authenticate the server. 245 This draft discusses Usage Profiles, which provide differing levels 246 of privacy guarantees to DNS clients, based on the requirements for 247 authentication and encryption, regardless of the context (for 248 example, which network the client is connected to). A Usage Profile 249 is a distinct concept to a usage policy or usage model, which might 250 dictate which Profile should be used in a particular context 251 (enterprise vs coffee shop), with a particular set of DNS Servers or 252 with reference to other external factors. A description of the 253 variety of usage policies is out of scope of this document, but may 254 be the subject of future work. 256 4.2. Usage Profiles 258 A DNS client has a choice of privacy Usage Profiles available. This 259 choice is briefly discussed in both [RFC7858] and 260 [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 262 o Strict Privacy: the DNS client requires both an encrypted and 263 authenticated connection to a privacy-enabling DNS Server. A hard 264 failure occurs if this is not available. This requires the client 265 to securely obtain information it can use to authenticate the 266 server. This profile can include some initial meta queries 267 (performed using Opportunistic Privacy) to securely obtain the IP 268 address and authentication information for the privacy-enabling 269 DNS server to which the DNS client will subsequently connect. The 270 rationale for this is that requiring Strict Privacy for such meta 271 queries would introduce significant deployment obstacles. This 272 profile provides strong privacy guarantees to the client. This 273 Profile is discussed in detail in Section 6. 275 o Opportunistic Privacy: the DNS client uses Opportunistic Security 276 as described in [RFC7435] 278 "... the use of cleartext as the baseline communication 279 security policy, with encryption and authentication negotiated 280 and applied to the communication when available." 282 The use of Opportunistic Privacy is intended to support 283 incremental deployment of security capabilities with a view to 284 widespread adoption of Strict Privacy. It should be employed when 285 the DNS client might otherwise settle for cleartext; it provides 286 the maximum protection available. As described in [RFC7435] it 287 might result in 289 * an encrypted and authenticated connection 290 * an encrypted connection 292 * a clear text connection 294 * hard failure 296 depending on the fallback logic of the client, the available 297 authentication information and the capabilities of the DNS Server. 298 In the first three cases the DNS client is willing to continue 299 with a connection to the DNS Server and perform resolution of 300 queries. 302 To compare the two Usage profiles the table below shows successful 303 Strict Privacy along side the 3 possible successful outcomes of 304 Opportunistic Privacy. In the best case scenario for Opportunistic 305 Privacy (an authenticated and encrypted connection) it is equivalent 306 to Strict Privacy. In the worst case scenario it is equivalent to 307 clear text. Clients using Opportunistic Privacy SHOULD try for the 308 best case but MAY fallback to intermediate cases and eventually the 309 worst case scenario in order to obtain a response. It therefore 310 provides no privacy guarantee to the user and varying protection 311 depending on what kind of connection is actually used. 313 Note that there is no requirement in Opportunistic Security to notify 314 the user what type of connection is actually used, the 'detection' 315 described below is only possible if such connection information is 316 available. However, if it is available and the user is informed that 317 an unencrypted connection was used to connect to a server then the 318 user should assume (detect) that the connection is subject to both 319 active and passive attack since the DNS queries are sent in clear 320 text. This might be particularly useful if a new connection to a 321 certain server is unencrypted when all previous connections were 322 encrypted. Similarly if the user is informed that an encrypted but 323 unauthenticated connection was used then user can detect that the 324 connection may be subject to active attack. This is discussed in 325 Section 5. 327 +---------------+------------+------------------+-----------------+ 328 | Usage Profile | Connection | Passive Attacker | Active Attacker | 329 +---------------+------------+------------------+-----------------+ 330 | Strict | A, E | P | P | 331 | Opportunistic | A, E | P | P | 332 | Opportunistic | E | P | N (D) | 333 | Opportunistic | | N (D) | N (D) | 334 +---------------+------------+------------------+-----------------+ 336 P == protection; N == no protection; D == detection is possible; A == 337 Authenticated Connection; E == Encrypted Connection 339 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 341 Since Strict Privacy provides the strongest privacy guarantees it is 342 preferable to Opportunistic Privacy. 344 However since the two profiles require varying levels of 345 configuration (or a trusted relationship with a provider) and DNS 346 server capabilities, DNS clients will need to carefully select which 347 profile to use based on their communication privacy needs. For the 348 case where a client has a trusted relationship with a provider it is 349 expected that the provider will provide either a domain name or SPKI 350 pinset via a secure out-of-band mechanism and therefore Strict 351 Privacy should be used. 353 4.2.1. DNS Resolution 355 A DNS client SHOULD select a particular usage profile when resolving 356 a query. A DNS client MUST NOT fallback from Strict Privacy to 357 Opportunistic Privacy during the resolution process as this could 358 invalidate the protection offered against active attackers. 360 4.3. Authentication 362 This document describes authentication mechanisms that can be used in 363 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 365 4.3.1. DNS-over-(D)TLS Bootstrapping Problems 367 Many (D)TLS clients use PKIX authentication [RFC6125] based on a 368 domain name for the server they are contacting. These clients 369 typically first look up the server's network address in the DNS 370 before making this connection. A DNS client therefore has a 371 bootstrap problem. DNS clients typically know only the IP address of 372 a DNS server. 374 As such, before connecting to a DNS server, a DNS client needs to 375 learn the domain name it should associate with the IP address of a 376 DNS server for authentication purposes. Sources of domains names are 377 discussed in Section 7 and Section 8. 379 One advantage of this domain name based approach is that it 380 encourages association of stable, human recognisable identifiers with 381 secure DNS service providers. 383 4.3.2. Credential Verification 385 The use of SPKI pinset verification is discussed in [RFC7858]. 387 In terms of domain name based verification, once a domain name is 388 known for a DNS server a choice of mechanisms can be used for 389 authentication. Section 9 discusses these mechanisms in detail, 390 namely PKIX certificate based authentication and DANE. 392 Note that the use of DANE adds requirements on the ability of the 393 client to get validated DNSSEC results. This is discussed in more 394 detail in Section 9.2. 396 4.3.3. Implementation guidance 398 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 399 Additional considerations relating to general implementation 400 guidelines are discussed in both Section 13 and in Appendix A. 402 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 404 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 405 which MAY be used for DNS-over-(D)TLS. 407 DNS clients issuing queries under an opportunistic profile which know 408 of a domain name or SPKI pinset for a given privacy-enabling DNS 409 server MAY choose to try to authenticate the server using the 410 mechanisms described here. This is useful for detecting (but not 411 preventing) active attack, since the fact that authentication 412 information is available indicates that the server in question is a 413 privacy-enabling DNS server to which it should be possible to 414 establish an authenticated, encrypted connection. In this case, 415 whilst a client cannot know the reason for an authentication failure, 416 from a privacy standpoint the client should consider an active attack 417 in progress and proceed under that assumption. Attempting 418 authentication is also useful for debugging or diagnostic purposes if 419 there are means to report the result. This information can provide a 420 basis for a DNS client to switch to (preferred) Strict Privacy where 421 it is viable. 423 6. Authentication in Strict DNS-over(D)TLS Privacy 425 To authenticate a privacy-enabling DNS server, a DNS client needs to 426 know the domain name for each server it is willing to contact. This 427 is necessary to protect against active attacks on DNS privacy. 429 A DNS client requiring Strict Privacy MUST either use one of the 430 sources listed in Section 8 to obtain a domain name for the server it 431 contacts, or use an SPKI pinset as described in [RFC7858]. 433 A DNS client requiring Strict Privacy MUST only attempt to connect to 434 DNS servers for which either a domain name or a SPKI pinset is known 435 (or both). The client MUST use the available verification mechanisms 436 described in Section 9 to authenticate the server, and MUST abort 437 connections to a server when no verification mechanism succeeds. 439 With Strict Privacy, the DNS client MUST NOT commence sending DNS 440 queries until at least one of the privacy-enabling DNS servers 441 becomes available. 443 A privacy-enabling DNS server may be temporarily unavailable when 444 configuring a network. For example, for clients on networks that 445 require registration through web-based login (a.k.a. "captive 446 portals"), such registration may rely on DNS interception and 447 spoofing. Techniques such as those used by DNSSEC-trigger 448 [dnssec-trigger] MAY be used during network configuration, with the 449 intent to transition to the designated privacy-enabling DNS servers 450 after captive portal registration. The system MUST alert by some 451 means that the DNS is not private during such bootstrap. 453 7. In Band Source of Domain Name: SRV Service Label 455 This specification adds a SRV service label "domain-s" for privacy- 456 enabling DNS servers. 458 Example service records (for TLS and DTLS respectively): 460 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 461 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 463 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 465 8. Out of Band Sources of Domain Name 466 8.1. Full direct configuration 468 DNS clients may be directly and securely provisioned with the domain 469 name of each privacy-enabling DNS server. For example, using a 470 client specific configuration file or API. 472 In this case, direct configuration for a DNS client would consist of 473 both an IP address and a domain name for each DNS server. 475 8.2. Direct configuration of name only 477 A DNS client may be configured directly and securely with only the 478 domain name of its privacy-enabling DNS server. For example, using a 479 client specific configuration file or API. 481 A DNS client might learn of a default recursive DNS resolver from an 482 untrusted source (such as DHCP's DNS server option [RFC3646]). It 483 can then use opportunistic DNS connections to untrusted recursive DNS 484 resolver to establish the IP address of the intended privacy-enabling 485 DNS server by doing a lookup of SRV records. Such records MUST be 486 validated using DNSSEC. Private DNS resolution can now be done by 487 the DNS client against the configured privacy-enabling DNS server. 489 Example: 491 o A DNSSEC validating DNS client is configured with the domain name 492 dns.example.net for a privacy-enabling DNS server 494 o Using Opportunistic Privacy to a default DNS resolver (acquired, 495 for example, using DHCP) the client performs look ups for 497 * SRV record for _domain-s._tcp.dns.example.net to obtain the 498 server host name 500 * A and/or AAAA lookups to obtain IP address for the server host 501 name 503 o Client validates all the records obtained in the previous step 504 using DNSSEC. 506 o If the records successfully validate the client proceeds to 507 connect to the privacy-enabling DNS server using Strict Privacy. 509 A DNS client so configured that successfully connects to a privacy- 510 enabling DNS server MAY choose to locally cache the looked up 511 addresses in order to not have to repeat the opportunistic lookup. 513 8.3. DHCP 515 Some clients may have an established trust relationship with a known 516 DHCP [RFC2131] server for discovering their network configuration. 517 In the typical case, such a DHCP server provides a list of IP 518 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 519 not provide a domain name for the DNS server itself. 521 In the future, a DHCP server might use a DHCP extension to provide a 522 list of domain names for the offered DNS servers, which correspond to 523 IP addresses listed. 525 Use of such a mechanism with any DHCP server when using an 526 Opportunistic profile is reasonable, given the security expectation 527 of that profile. However when using a Strict profile the DHCP 528 servers used as sources of domain names MUST be considered secure and 529 trustworthy. This document does not attempt to describe secured and 530 trusted relationships to DHCP servers. 532 [NOTE: It is noted (at the time of writing) that whilst some 533 implementation work is in progress to secure IPv6 connections for 534 DHCP, IPv4 connections have received little to no implementation 535 attention in this area.] 537 9. Credential Verification 539 9.1. PKIX Certificate Based Authentication 541 When a DNS client configured with a domain name connects to its 542 configured DNS server over (D)TLS, the server may present it with an 543 PKIX certificate. In order to ensure proper authentication, DNS 544 clients MUST verify the entire certification path per [RFC5280]. The 545 DNS client additionally uses [RFC6125] validation techniques to 546 compare the domain name to the certificate provided. 548 A DNS client constructs two Reference Identifiers for the server 549 based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- 550 ID is simply the domain name itself. The SRV-ID uses a "_domain-s." 551 prefix. So if the configured domain name is "dns.example.com", then 552 the two Reference Identifiers are: 554 DNS-ID: dns.example.com 556 SRV-ID: _domain-s.dns.example.com 558 If either of the Reference Identifiers are found in the PKIX 559 certificate's subjectAltName extension as described in section 6 of 561 [RFC6125], the DNS client should accept the certificate for the 562 server. 564 A compliant DNS client MUST only inspect the certificate's 565 subjectAltName extension for these Reference Identifiers. In 566 particular, it MUST NOT inspect the Subject field itself. 568 9.2. DANE 570 DANE [RFC6698] provides mechanisms to root certificate and raw public 571 key trust with DNSSEC. However this requires the DNS client to have 572 a domain name for the DNS Privacy Server which must be obtained via a 573 trusted source. 575 This section assumes a solid understanding of both DANE [RFC6698] and 576 DANE Operations [RFC7671]. A few pertinent issues covered in these 577 documents are outlined here as useful pointers, but familiarity with 578 both these documents in their entirety is expected. 580 It is noted that [RFC6698] says 582 "Clients that validate the DNSSEC signatures themselves MUST use 583 standard DNSSEC validation procedures. Clients that rely on 584 another entity to perform the DNSSEC signature validation MUST use 585 a secure mechanism between themselves and the validator." 587 It is noted that [RFC7671] covers the following topics: 589 o Section 4.1: Opportunistic Security and PKIX Usages and 590 Section 14: Security Considerations, which both discuss the use of 591 PKIX-TA(0) and PKIX-EE(1) for OS. 593 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 594 Specifically Section 5.1 which outlines the combination of 595 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 596 Public Keys [RFC7250]. Section 5.1 also discusses the security 597 implications of this mode, for example, it discusses key lifetimes 598 and specifies that validity period enforcement is based solely on 599 the TLSA RRset properties for this case. [QUESTION: Should an 600 appendix be added with an example of how to use DANE without PKIX 601 certificates?] 603 o Section 13: Operational Considerations, which discusses TLSA TTLs 604 and signature validity periods. 606 The specific DANE record for a DNS Privacy Server would take the 607 form: 609 _853._tcp.[server-domain-name] for TLS 611 _853._udp.[server-domain-name] for DTLS 613 9.2.1. Direct DNS Lookup 615 The DNS client MAY choose to perform the DNS lookups to retrieve the 616 required DANE records itself. The DNS queries for such DANE records 617 MAY use opportunistic encryption or be in the clear to avoid trust 618 recursion. The records MUST be validated using DNSSEC as described 619 above in [RFC6698]. 621 9.2.2. TLS DNSSEC Chain extension 623 The DNS client MAY offer the TLS extension described in 624 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 625 this extension, it can provide the full chain to the client in the 626 handshake. 628 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 629 capable of validating the full DNSSEC authentication chain down to 630 the leaf. If the supplied DNSSEC chain does not validate, the client 631 MUST ignore the DNSSEC chain and validate only via other supplied 632 credentials. 634 10. Combined Credentials with SPKI Pinsets 636 The SPKI pinset profile described in [RFC7858] MAY be used with DNS- 637 over-(D)TLS. 639 This draft does not make explicit recommendations about how a SPKI 640 pinset based authentication mechanism should be combined with a 641 domain based mechanism from an operator perspective. However it can 642 be envisaged that a DNS server operator may wish to make both an SPKI 643 pinset and a domain name available to allow clients to choose which 644 mechanism to use. Therefore, the following is guidance on how 645 clients ought to behave if they choose to configure both, as is 646 possible in HPKP [RFC7469]. 648 A DNS client that is configured with both a domain name and a SPKI 649 pinset for a DNS server SHOULD match on both a valid credential for 650 the domain name and a valid SPKI pinset if both are available when 651 connecting to that DNS server. 653 11. (D)TLS Protocol Profile 655 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 657 There are known attacks on (D)TLS, such as machine-in-the-middle and 658 protocol downgrade. These are general attacks on (D)TLS and not 659 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 660 discussion of these security issues. Clients and servers MUST adhere 661 to the (D)TLS implementation recommendations and security 662 considerations of [RFC7525] except with respect to (D)TLS version. 663 Since encryption of DNS using (D)TLS is virtually a green-field 664 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 665 later. 667 Implementations MUST NOT offer or provide TLS compression, since 668 compression can leak significant amounts of information, especially 669 to a network observer capable of forcing the user to do an arbitrary 670 DNS lookup in the style of the CRIME attacks [CRIME]. 672 Implementations compliant with this profile MUST implement all of the 673 following items: 675 o TLS session resumption without server-side state [RFC5077] which 676 eliminates the need for the server to retain cryptographic state 677 for longer than necessary. 679 o Raw public keys [RFC7250] which reduce the size of the 680 ServerHello, and can be used by servers that cannot obtain 681 certificates (e.g., DNS servers on private networks). 683 Implementations compliant with this profile SHOULD implement all of 684 the following items: 686 o TLS False Start [RFC7918] which reduces round-trips by allowing 687 the TLS second flight of messages (ChangeCipherSpec) to also 688 contain the (encrypted) DNS query 690 o Cached Information Extension [RFC7924] which avoids transmitting 691 the server's certificate and certificate chain if the client has 692 cached that information from a previous TLS handshake 694 Guidance specific to TLS is provided in [RFC7858] and that specific 695 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 697 12. IANA Considerations 699 This memo includes no request to IANA. 701 13. Security Considerations 703 Security considerations discussed in [RFC7525], 704 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 706 13.1. Counter-measures to DNS Traffic Analysis 708 This section makes suggestions for measures that can reduce the 709 ability of attackers to infer information pertaining to encrypted 710 client queries by other means (e.g. via an analysis of encrypted 711 traffic size, or via monitoring of resolver to authoritative 712 traffic). 714 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 715 following relevant DNS extensions 717 o EDNS(0) padding [RFC7830], which allows encrypted queries and 718 responses to hide their size. 720 DNS-over-(D)TLS clients SHOULD consider implementing the following 721 relevant DNS extensions 723 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 724 a DNS client does not include an EDNS0 Client Subnet Option with a 725 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 726 potentially leak client address information to the upstream 727 authoritative DNS servers. A DNS client ought to be able to 728 inform the DNS Resolver that it does not want any address 729 information leaked, and the DNS Resolver should honor that 730 request. 732 14. Acknowledgements 734 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 735 [RFC7858] for laying the ground work that this draft builds on and 736 for reviewing the contents. The authors would also like to thank 737 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 738 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and 739 Christian Huitema for review and discussion of the ideas presented 740 here. 742 15. References 744 15.1. Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, 748 DOI 10.17487/RFC2119, March 1997, 749 . 751 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 752 Subject Alternative Name for Expression of Service Name", 753 RFC 4985, DOI 10.17487/RFC4985, August 2007, 754 . 756 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 757 "Transport Layer Security (TLS) Session Resumption without 758 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 759 January 2008, . 761 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 762 (TLS) Protocol Version 1.2", RFC 5246, 763 DOI 10.17487/RFC5246, August 2008, 764 . 766 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 767 Housley, R., and W. Polk, "Internet X.509 Public Key 768 Infrastructure Certificate and Certificate Revocation List 769 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 770 . 772 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 773 Verification of Domain-Based Application Service Identity 774 within Internet Public Key Infrastructure Using X.509 775 (PKIX) Certificates in the Context of Transport Layer 776 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 777 2011, . 779 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 780 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 781 January 2012, . 783 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 784 of Named Entities (DANE) Transport Layer Security (TLS) 785 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 786 2012, . 788 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 789 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 790 Transport Layer Security (TLS) and Datagram Transport 791 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 792 June 2014, . 794 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 795 "Recommendations for Secure Use of Transport Layer 796 Security (TLS) and Datagram Transport Layer Security 797 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 798 2015, . 800 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 801 Authentication of Named Entities (DANE) Protocol: Updates 802 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 803 October 2015, . 805 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 806 DOI 10.17487/RFC7830, May 2016, 807 . 809 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 810 and P. Hoffman, "Specification for DNS over Transport 811 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 812 2016, . 814 15.2. Informative References 816 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 818 [dnssec-trigger] 819 NLnetLabs, "Dnssec-Trigger", May 2014, 820 . 822 [I-D.ietf-dprive-dnsodtls] 823 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 824 over Datagram Transport Layer Security (DTLS)", draft- 825 ietf-dprive-dnsodtls-12 (work in progress), September 826 2016. 828 [I-D.ietf-tls-dnssec-chain-extension] 829 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 830 Record and DNSSEC Authentication Chain Extension for TLS", 831 draft-ietf-tls-dnssec-chain-extension-01 (work in 832 progress), July 2016. 834 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 835 RFC 2131, DOI 10.17487/RFC2131, March 1997, 836 . 838 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 839 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 840 . 842 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 843 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 844 DOI 10.17487/RFC3646, December 2003, 845 . 847 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 848 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 849 December 2014, . 851 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 852 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 853 2015, . 855 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 856 DOI 10.17487/RFC7626, August 2015, 857 . 859 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 860 Kumari, "Client Subnet in DNS Queries", RFC 7871, 861 DOI 10.17487/RFC7871, May 2016, 862 . 864 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 865 Layer Security (TLS) False Start", RFC 7918, 866 DOI 10.17487/RFC7918, August 2016, 867 . 869 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 870 (TLS) Cached Information Extension", RFC 7924, 871 DOI 10.17487/RFC7924, July 2016, 872 . 874 Appendix A. Server capability probing and caching by DNS clients 876 This section presents a non-normative discussion of how DNS clients 877 might probe for and cache privacy capabilities of DNS servers. 879 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 880 Not all servers will support one or both of these protocols and the 881 well-known port might be blocked by some middleboxes. Clients will 882 be expected to keep track of servers that support DNS-over-TLS and/or 883 DNS-over-DTLS, and those that have been previously authenticated. 885 If no server capability information is available then (unless 886 otherwise specified by the configuration of the DNS client) DNS 887 clients that implement both TLS and DTLS should try to authenticate 888 using both protocols before failing or falling back to a lower 889 security. DNS clients using opportunistic security should try all 890 available servers (possibly in parallel) in order to obtain an 891 authenticated encrypted connection before falling back to a lower 892 security. (RATIONALE: This approach can increase latency while 893 discovering server capabilities but maximizes the chance of sending 894 the query over an authenticated encrypted connection.) 896 Appendix B. Changes between revisions 898 [Note to RFC Editor: please remove this section prior to 899 publication.] 901 B.1. -05 version 903 Add more details on detecting passive attacks to section 4.2 905 Changed X.509 to PKIX throughout 907 Change comment about future I-D on usage policies. 909 B.2. -04 version 911 Introduction: Add comment that DNS-over-DTLS draft is Experiments 913 Update 2 I-D references to RFCs. 915 B.3. -03 version 917 Section 9: Update DANE section with better references to RFC7671 and 918 RFC7250 920 B.4. -02 version 922 Introduction: Added paragraph on the background and scope of the 923 document. 925 Introduction and Discussion: Added more information on what a Usage 926 profiles is (and is not) the the two presented here. 928 Introduction: Added paragraph to make a comparison with the Strict 929 profile in RFC7858 clearer. 931 Section 4.2: Re-worked the description of Opportunistic and the 932 table. 934 Section 8.3: Clarified statement about use of DHCP in Opportunistic 935 profile 937 Title abbreviated. 939 B.5. -01 version 941 Section 4.2: Make clear that the Strict Privacy Profile can include 942 meta queries performed using Opportunistic Privacy. 944 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 945 does not guarantee protection against passive attack. 947 Section 4.2: Add sentence discussing client/provider trusted 948 relationships. 950 Section 5: Add more discussion of detection of active attacks when 951 using Opportunistic Privacy. 953 Section 8.2: Clarify description and example. 955 B.6. draft-ietf-dprive-dtls-and-tls-profiles-00 957 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 958 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 959 fixed. 961 Authors' Addresses 963 Sara Dickinson 964 Sinodun Internet Technologies 965 Magdalen Centre 966 Oxford Science Park 967 Oxford OX4 4GA 968 UK 970 Email: sara@sinodun.com 971 URI: http://sinodun.com 972 Daniel Kahn Gillmor 973 ACLU 974 125 Broad Street, 18th Floor 975 New York NY 10004 976 USA 978 Email: dkg@fifthhorseman.net 980 Tirumaleswar Reddy 981 Cisco Systems, Inc. 982 Cessna Business Park, Varthur Hobli 983 Sarjapur Marathalli Outer Ring Road 984 Bangalore, Karnataka 560103 985 India 987 Email: tireddy@cisco.com