idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2016) is 2738 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-12 == 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: 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: May 1, 2017 ACLU 6 T. Reddy 7 Cisco 8 October 28, 2016 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-06 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 May 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 6 61 4.2.1. DNS Resolution . . . . . . . . . . . . . . . . . . . 8 62 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 9 63 4.3.1. DNS-over-(D)TLS Startup Configuration Problems . . . 9 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 Authentication Domain Name: SRV Service 69 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Out of Band Sources of Authentication Domain Name . . . . . . 11 71 8.1. Full direct configuration . . . . . . . . . . . . . . . . 11 72 8.2. Direct configuration of name only . . . . . . . . . . . . 11 73 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 9. Credential Verification . . . . . . . . . . . . . . . . . . . 12 75 9.1. PKIX Certificate Based Authentication . . . . . . . . . . 12 76 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 14 78 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 14 79 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 14 80 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 15 81 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 13. Security Considerations . . . . . . . . . . . . . . . . . . . 16 83 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 16 84 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 15.2. Informative References . . . . . . . . . . . . . . . . . 18 88 Appendix A. Server capability probing and caching by DNS clients 20 89 Appendix B. Changes between revisions . . . . . . . . . . . . . 20 90 B.1. -06 version . . . . . . . . . . . . . . . . . . . . . . . 20 91 B.2. -05 version . . . . . . . . . . . . . . . . . . . . . . . 21 92 B.3. -04 version . . . . . . . . . . . . . . . . . . . . . . . 21 93 B.4. -03 version . . . . . . . . . . . . . . . . . . . . . . . 21 94 B.5. -02 version . . . . . . . . . . . . . . . . . . . . . . . 21 95 B.6. -01 version . . . . . . . . . . . . . . . . . . . . . . . 21 96 B.7. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 DNS Privacy issues are discussed in [RFC7626]. Two documents that 103 provide DNS privacy between DNS clients and DNS servers are: 105 o Specification for DNS over Transport Layer Security (TLS) 106 [RFC7858], referred to here as simply 'DNS-over-TLS' 108 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 109 simply as 'DNS-over-DTLS'. Note that this document has the 110 Intended status of Experimental. 112 Both documents are limited in scope to encrypting DNS messages 113 between stub clients and recursive resolvers and the same scope is 114 applied to this document (see Section 2 and Section 3). The 115 proposals here might be adapted or extended in future to be used for 116 recursive clients and authoritative servers, but this application was 117 out of scope for the Working Group charter at the time this document 118 was finished. 120 This document defines two Usage Profiles (Strict and Opportunistic) 121 for DTLS [RFC6347] and TLS [RFC5246] which define the security 122 properties a user should expect when using that profile to connect to 123 the available DNS servers. In essence: 125 o the Strict Profile requires an encrypted connection and successful 126 authentication of the DNS server which provides strong privacy 127 guarantees (at the expense of providing no DNS service if this is 128 not available). 130 o the Opportunistic Profile will attempt, but does not require, 131 encryption and successful authentication; it therefore provides no 132 privacy guarantees but offers maximum chance of DNS service. 134 Additionally, a number of authentication mechanisms are defined that 135 specify how a DNS client should authenticate a DNS server based on a 136 domain name. In particular, the following is described: 138 o How a DNS client can obtain the combination of an authentication 139 domain name and IP address for a DNS server. 141 o What are the acceptable credentials a DNS server can present to 142 prove its identity for (D)TLS authentication based on a given 143 domain name. 145 o How a DNS client can verify that any given credential matches the 146 authentication domain name obtained for a DNS server. 148 It should be noted that [RFC7858] includes a description of a 149 specific case of a Strict Usage Profile using a single authentication 150 mechanism (SPKI pinning). This document generalises the picture by 151 separating the Usage Profile, which is based purely on the security 152 properties it offers the user, from the specific mechanism that is 153 used for authentication. Therefore the "Out-of-band Key-pinned 154 Privacy Profile" described in [RFC7858] would qualify as a "Strict 155 Usage Profile" that used SPKI pinning for authentication. 157 This document also defines a (D)TLS protocol profile for use with 158 DNS. This profile defines the configuration options and protocol 159 extensions required of both parties to optimize connection 160 establishment and session resumption for transporting DNS, and to 161 support the authentication mechanisms defined here. 163 2. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 Several terms are used specifically in the context of this draft: 171 o DNS client: a DNS stub resolver or forwarder. In the case of a 172 forwarder, the term "DNS client" is used to discuss the side that 173 sends queries. 175 o DNS server: a DNS recursive resolver or forwarder. In the case of 176 a forwarder, the term "DNS server" is used to discuss the side 177 that responds to queries. 179 o Privacy-enabling DNS server: A DNS server that: 181 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 182 over-DTLS [I-D.ietf-dprive-dnsodtls]. 184 * Can offer at least one of the credentials described in 185 Section 9. 187 * Implements the (D)TLS profile described in Section 11. 189 o (D)TLS: For brevity this term is used for statements that apply to 190 both Transport Layer Security [RFC5246] and Datagram Transport 191 Layer Security [RFC6347]. Specific terms will be used for any 192 statement that applies to either protocol alone. 194 o DNS-over-(D)TLS: For brevity this term is used for statements that 195 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 196 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 197 statement that applies to either protocol alone. 199 o Authentication domain name: A domain name that can be used to 200 authenticate a DNS Privacy enabling server. Sources of 201 authentication domain names are discussed in Section 7 and 202 Section 8. 204 o Credential: Information available for a DNS server which proves 205 its identity for authentication purposes. Credentials discussed 206 here include: 208 * PKIX certificate 210 * DNSSEC validated chain to a TLSA record 212 but may also include SPKI pinsets. 214 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 215 to "pin" public key information in a manner similar to HPKP 216 [RFC7469]. An SPKI pinset is a collection of these pins that 217 constrains a DNS server. 219 o Reference Identifier: a Reference Identifier as described in 220 [RFC6125], constructed by the DNS client when performing TLS 221 authentication of a DNS server. 223 3. Scope 225 This document is limited to domain-name-based authentication of DNS 226 servers by DNS clients (as defined in the terminology section), and 227 the (D)TLS profiles needed to support this. As such, the following 228 things are out of scope: 230 o Authentication of authoritative servers by recursive resolvers. 232 o Authentication of DNS clients by DNS servers. 234 o SPKI-pinset-based authentication. This is defined in [RFC7858]. 235 However, Section 10 does describe how to combine that approach 236 with the authentication domain name based mechanism described 237 here. 239 o Any server identifier other than domain names, including IP 240 address, organizational name, country of origin, etc. 242 4. Discussion 244 4.1. Background 246 To protect against passive attacks DNS privacy requires encrypting 247 the query (and response). Such encryption typically provides 248 integrity protection as a side-effect, which means on-path attackers 249 cannot simply inject bogus DNS responses. For DNS privacy to also 250 provide protection against active attackers pretending to be the 251 server, the client must authenticate the server. 253 This draft discusses Usage Profiles, which provide differing levels 254 of privacy guarantees to DNS clients, based on the requirements for 255 authentication and encryption, regardless of the context (for 256 example, which network the client is connected to). A Usage Profile 257 is a distinct concept to a usage policy or usage model, which might 258 dictate which Profile should be used in a particular context 259 (enterprise vs coffee shop), with a particular set of DNS Servers or 260 with reference to other external factors. A description of the 261 variety of usage policies is out of scope of this document, but may 262 be the subject of future work. 264 4.2. Usage Profiles 266 A DNS client has a choice of privacy Usage Profiles available. This 267 choice is briefly discussed in both [RFC7858] and 268 [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 270 o Strict Privacy: the DNS client requires both an encrypted and 271 authenticated connection to a privacy-enabling DNS Server. A hard 272 failure occurs if this is not available. This requires the client 273 to securely obtain information it can use to authenticate the 274 server. This profile can include some initial meta queries 275 (performed using Opportunistic Privacy) to securely obtain the IP 276 address and authentication information for the privacy-enabling 277 DNS server to which the DNS client will subsequently connect. The 278 rationale for this is that requiring Strict Privacy for such meta 279 queries would introduce significant deployment obstacles. This 280 profile provides strong privacy guarantees to the client. This 281 Profile is discussed in detail in Section 6. 283 o Opportunistic Privacy: the DNS client uses Opportunistic Security 284 as described in [RFC7435] 286 "... the use of cleartext as the baseline communication 287 security policy, with encryption and authentication negotiated 288 and applied to the communication when available." 290 The use of Opportunistic Privacy is intended to support 291 incremental deployment of security capabilities with a view to 292 widespread adoption of Strict Privacy. It should be employed when 293 the DNS client might otherwise settle for cleartext; it provides 294 the maximum protection available. As described in [RFC7435] it 295 might result in 297 * an encrypted and authenticated connection 299 * an encrypted connection 301 * a clear text connection 303 * hard failure 305 depending on the fallback logic of the client, the available 306 authentication information and the capabilities of the DNS Server. 307 In the first three cases the DNS client is willing to continue 308 with a connection to the DNS Server and perform resolution of 309 queries. 311 To compare the two Usage profiles the table below shows successful 312 Strict Privacy along side the 3 possible successful outcomes of 313 Opportunistic Privacy. In the best case scenario for Opportunistic 314 Privacy (an authenticated and encrypted connection) it is equivalent 315 to Strict Privacy. In the worst case scenario it is equivalent to 316 clear text. Clients using Opportunistic Privacy SHOULD try for the 317 best case but MAY fallback to intermediate cases and eventually the 318 worst case scenario in order to obtain a response. It therefore 319 provides no privacy guarantee to the user and varying protection 320 depending on what kind of connection is actually used. 322 Note that there is no requirement in Opportunistic Security to notify 323 the user what type of connection is actually used, the 'detection' 324 described below is only possible if such connection information is 325 available. However, if it is available and the user is informed that 326 an unencrypted connection was used to connect to a server then the 327 user should assume (detect) that the connection is subject to both 328 active and passive attack since the DNS queries are sent in clear 329 text. This might be particularly useful if a new connection to a 330 certain server is unencrypted when all previous connections were 331 encrypted. Similarly if the user is informed that an encrypted but 332 unauthenticated connection was used then user can detect that the 333 connection may be subject to active attack. This is discussed in 334 Section 5. 336 +---------------+------------+------------------+-----------------+ 337 | Usage Profile | Connection | Passive Attacker | Active Attacker | 338 +---------------+------------+------------------+-----------------+ 339 | Strict | A, E | P | P | 340 | Opportunistic | A, E | P | P | 341 | Opportunistic | E | P | N, D | 342 | Opportunistic | | N, D | N, D | 343 +---------------+------------+------------------+-----------------+ 345 P == protection; N == no protection; D == detection is possible; A == 346 Authenticated Connection; E == Encrypted Connection 348 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 350 Strict Privacy provides the strongest privacy guarantees and 351 therefore SHOULD always be implemented in DNS clients along with 352 Opportunistic Privacy. 354 A DNS client that implements DNS-over-(D)TLS SHOULD NOT default to 355 the use of clear text (no privacy). 357 The choice between the two profiles depends on a number of factors 358 including which is more important to the particular client: 360 o DNS service at the cost of no privacy guarantee (Opportunistic) or 362 o guaranteed privacy at the potential cost of no DNS service 363 (Strict). 365 Additionally the two profiles require varying levels of configuration 366 (or a trusted relationship with a provider) and DNS server 367 capabilities therefore DNS clients will need to carefully select 368 which profile to use based on their communication privacy needs. 370 A DNS server that implements DNS-over-TLS SHOULD provide at least one 371 credential in order that those DNS clients that wish to do so are 372 able to use Strict Privacy (see Section 2). 374 4.2.1. DNS Resolution 376 A DNS client SHOULD select a particular usage profile when resolving 377 a query. A DNS client MUST NOT fallback from Strict Privacy to 378 Opportunistic Privacy during the resolution process as this could 379 invalidate the protection offered against active attackers. 381 4.3. Authentication 383 This document describes authentication mechanisms that can be used in 384 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 386 4.3.1. DNS-over-(D)TLS Startup Configuration Problems 388 Many (D)TLS clients use PKIX authentication [RFC6125] based on an 389 authentication domain name for the server they are contacting. These 390 clients typically first look up the server's network address in the 391 DNS before making this connection. A DNS client therefore has a 392 bootstrap problem. DNS clients typically know only the IP address of 393 a DNS server. 395 As such, before connecting to a DNS server, a DNS client needs to 396 learn the authentication domain name it should associate with the IP 397 address of a DNS server for authentication purposes. Sources of 398 domains names are discussed in Section 7 and Section 8. 400 One advantage of this domain name based approach is that it 401 encourages association of stable, human recognisable identifiers with 402 secure DNS service providers. 404 4.3.2. Credential Verification 406 The use of SPKI pinset verification is discussed in [RFC7858]. 408 In terms of domain name based verification, once an authentication 409 domain name is known for a DNS server a choice of mechanisms can be 410 used for authentication. Section 9 discusses these mechanisms in 411 detail, namely PKIX certificate based authentication and DANE. 413 Note that the use of DANE adds requirements on the ability of the 414 client to get validated DNSSEC results. This is discussed in more 415 detail in Section 9.2. 417 4.3.3. Implementation guidance 419 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 420 Additional considerations relating to general implementation 421 guidelines are discussed in both Section 13 and in Appendix A. 423 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 425 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 426 which MAY be used for DNS-over-(D)TLS. 428 DNS clients issuing queries under an opportunistic profile which know 429 of an authentication domain name or SPKI pinset for a given privacy- 430 enabling DNS server MAY choose to try to authenticate the server 431 using the mechanisms described here. This is useful for detecting 432 (but not preventing) active attack, since the fact that 433 authentication information is available indicates that the server in 434 question is a privacy-enabling DNS server to which it should be 435 possible to establish an authenticated, encrypted connection. In 436 this case, whilst a client cannot know the reason for an 437 authentication failure, from a privacy standpoint the client should 438 consider an active attack in progress and proceed under that 439 assumption. Attempting authentication is also useful for debugging 440 or diagnostic purposes if there are means to report the result. This 441 information can provide a basis for a DNS client to switch to 442 (preferred) Strict Privacy where it is viable. 444 6. Authentication in Strict DNS-over(D)TLS Privacy 446 To authenticate a privacy-enabling DNS server, a DNS client needs to 447 know the domain name for each server it is willing to contact. This 448 is necessary to protect against active attacks on DNS privacy. 450 A DNS client requiring Strict Privacy MUST either use one of the 451 sources listed in Section 8 to obtain an authentication domain name 452 for the server it contacts, or use an SPKI pinset as described in 453 [RFC7858]. 455 A DNS client requiring Strict Privacy MUST only attempt to connect to 456 DNS servers for which either an authentication domain name or a SPKI 457 pinset is known (or both). The client MUST use the available 458 verification mechanisms described in Section 9 to authenticate the 459 server, and MUST abort connections to a server when no verification 460 mechanism succeeds. 462 With Strict Privacy, the DNS client MUST NOT commence sending DNS 463 queries until at least one of the privacy-enabling DNS servers 464 becomes available. 466 A privacy-enabling DNS server may be temporarily unavailable when 467 configuring a network. For example, for clients on networks that 468 require registration through web-based login (a.k.a. "captive 469 portals"), such registration may rely on DNS interception and 470 spoofing. Techniques such as those used by DNSSEC-trigger 471 [dnssec-trigger] MAY be used during network configuration, with the 472 intent to transition to the designated privacy-enabling DNS servers 473 after captive portal registration. The system MUST alert by some 474 means that the DNS is not private during such bootstrap. 476 7. In Band Source of Authentication Domain Name: SRV Service Label 478 This specification adds a SRV service label "domain-s" for privacy- 479 enabling DNS servers. 481 Example service records (for TLS and DTLS respectively): 483 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 484 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 486 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 488 8. Out of Band Sources of Authentication Domain Name 490 8.1. Full direct configuration 492 DNS clients may be directly and securely provisioned with the 493 authentication domain name of each privacy-enabling DNS server. For 494 example, using a client specific configuration file or API. 496 In this case, direct configuration for a DNS client would consist of 497 both an IP address and a domain name for each DNS server. 499 8.2. Direct configuration of name only 501 A DNS client may be configured directly and securely with only the 502 authentication domain name of its privacy-enabling DNS server. For 503 example, using a client specific configuration file or API. 505 A DNS client might learn of a default recursive DNS resolver from an 506 untrusted source (such as DHCP's DNS server option [RFC3646]). It 507 can then use opportunistic DNS connections to untrusted recursive DNS 508 resolver to establish the IP address of the intended privacy-enabling 509 DNS server by doing a lookup of SRV records. Such records MUST be 510 validated using DNSSEC. Private DNS resolution can now be done by 511 the DNS client against the configured privacy-enabling DNS server. 513 Example: 515 o A DNSSEC validating DNS client is configured with the domain name 516 dns.example.net for a privacy-enabling DNS server 518 o Using Opportunistic Privacy to a default DNS resolver (acquired, 519 for example, using DHCP) the client performs look ups for 521 * SRV record for _domain-s._tcp.dns.example.net to obtain the 522 server host name 524 * A and/or AAAA lookups to obtain IP address for the server host 525 name 527 o Client validates all the records obtained in the previous step 528 using DNSSEC. 530 o If the records successfully validate the client proceeds to 531 connect to the privacy-enabling DNS server using Strict Privacy. 533 A DNS client so configured that successfully connects to a privacy- 534 enabling DNS server MAY choose to locally cache the looked up 535 addresses in order to not have to repeat the opportunistic lookup. 537 8.3. DHCP 539 Some clients may have an established trust relationship with a known 540 DHCP [RFC2131] server for discovering their network configuration. 541 In the typical case, such a DHCP server provides a list of IP 542 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 543 not provide a domain name for the DNS server itself. 545 In the future, a DHCP server might use a DHCP extension to provide a 546 list of authentication domain names for the offered DNS servers, 547 which correspond to IP addresses listed. 549 Use of such a mechanism with any DHCP server when using an 550 Opportunistic profile is reasonable, given the security expectation 551 of that profile. However when using a Strict profile the DHCP 552 servers used as sources of authentication domain names MUST be 553 considered secure and trustworthy. This document does not attempt to 554 describe secured and trusted relationships to DHCP servers. 556 It is noted (at the time of writing) that whilst some implementation 557 work is in progress to secure IPv6 connections for DHCP, IPv4 558 connections have received little to no implementation attention in 559 this area. 561 9. Credential Verification 563 9.1. PKIX Certificate Based Authentication 565 When a DNS client configured with an authentication domain name 566 connects to its configured DNS server over (D)TLS, the server may 567 present it with an PKIX certificate. In order to ensure proper 568 authentication, DNS clients MUST verify the entire certification path 569 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 570 techniques to compare the domain name to the certificate provided. 572 A DNS client constructs two Reference Identifiers for the server 573 based on the authentication domain name: A DNS-ID and an SRV-ID 574 [RFC4985]. The DNS-ID is simply the authentication domain name 575 itself. The SRV-ID uses a "_domain-s." prefix. So if the configured 576 authentication domain name is "dns.example.com", then the two 577 Reference Identifiers are: 579 DNS-ID: dns.example.com 581 SRV-ID: _domain-s.dns.example.com 583 If either of the Reference Identifiers are found in the PKIX 584 certificate's subjectAltName extension as described in section 6 of 585 [RFC6125], the DNS client should accept the certificate for the 586 server. 588 A compliant DNS client MUST only inspect the certificate's 589 subjectAltName extension for these Reference Identifiers. In 590 particular, it MUST NOT inspect the Subject field itself. 592 9.2. DANE 594 DANE [RFC6698] provides mechanisms to root certificate and raw public 595 key trust with DNSSEC. However this requires the DNS client to have 596 an authentication domain name for the DNS Privacy Server which must 597 be obtained via a trusted source. 599 This section assumes a solid understanding of both DANE [RFC6698] and 600 DANE Operations [RFC7671]. A few pertinent issues covered in these 601 documents are outlined here as useful pointers, but familiarity with 602 both these documents in their entirety is expected. 604 It is noted that [RFC6698] says 606 "Clients that validate the DNSSEC signatures themselves MUST use 607 standard DNSSEC validation procedures. Clients that rely on 608 another entity to perform the DNSSEC signature validation MUST use 609 a secure mechanism between themselves and the validator." 611 It is noted that [RFC7671] covers the following topics: 613 o Section 4.1: Opportunistic Security and PKIX Usages and 614 Section 14: Security Considerations, which both discuss the use of 615 PKIX-TA(0) and PKIX-EE(1) for OS. 617 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 618 Specifically Section 5.1 which outlines the combination of 619 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 620 Public Keys [RFC7250]. Section 5.1 also discusses the security 621 implications of this mode, for example, it discusses key lifetimes 622 and specifies that validity period enforcement is based solely on 623 the TLSA RRset properties for this case. [QUESTION: Should an 624 appendix be added with an example of how to use DANE without PKIX 625 certificates?] 627 o Section 13: Operational Considerations, which discusses TLSA TTLs 628 and signature validity periods. 630 The specific DANE record for a DNS Privacy Server would take the 631 form: 633 _853._tcp.[server-domain-name] for TLS 635 _853._udp.[server-domain-name] for DTLS 637 9.2.1. Direct DNS Lookup 639 The DNS client MAY choose to perform the DNS lookups to retrieve the 640 required DANE records itself. The DNS queries for such DANE records 641 MAY use opportunistic encryption or be in the clear to avoid trust 642 recursion. The records MUST be validated using DNSSEC as described 643 above in [RFC6698]. 645 9.2.2. TLS DNSSEC Chain extension 647 The DNS client MAY offer the TLS extension described in 648 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 649 this extension, it can provide the full chain to the client in the 650 handshake. 652 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 653 capable of validating the full DNSSEC authentication chain down to 654 the leaf. If the supplied DNSSEC chain does not validate, the client 655 MUST ignore the DNSSEC chain and validate only via other supplied 656 credentials. 658 10. Combined Credentials with SPKI Pinsets 660 The SPKI pinset profile described in [RFC7858] MAY be used with DNS- 661 over-(D)TLS. 663 This draft does not make explicit recommendations about how a SPKI 664 pinset based authentication mechanism should be combined with a 665 domain based mechanism from an operator perspective. However it can 666 be envisaged that a DNS server operator may wish to make both an SPKI 667 pinset and an authentication domain name available to allow clients 668 to choose which mechanism to use. Therefore, the following is 669 guidance on how clients ought to behave if they choose to configure 670 both, as is possible in HPKP [RFC7469]. 672 A DNS client that is configured with both an authentication domain 673 name and a SPKI pinset for a DNS server SHOULD match on both a valid 674 credential for the authentication domain name and a valid SPKI pinset 675 if both are available when connecting to that DNS server. 677 11. (D)TLS Protocol Profile 679 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 681 There are known attacks on (D)TLS, such as machine-in-the-middle and 682 protocol downgrade. These are general attacks on (D)TLS and not 683 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 684 discussion of these security issues. 686 Clients and servers MUST adhere to the (D)TLS implementation 687 recommendations and security considerations of [RFC7525] except with 688 respect to (D)TLS version. 690 Since encryption of DNS using (D)TLS is virtually a green-field 691 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 692 later. 694 Implementations MUST NOT offer or provide TLS compression, since 695 compression can leak significant amounts of information, especially 696 to a network observer capable of forcing the user to do an arbitrary 697 DNS lookup in the style of the CRIME attacks [CRIME]. 699 Implementations compliant with this profile MUST implement all of the 700 following items: 702 o TLS session resumption without server-side state [RFC5077] which 703 eliminates the need for the server to retain cryptographic state 704 for longer than necessary. 706 o Raw public keys [RFC7250] which reduce the size of the 707 ServerHello, and can be used by servers that cannot obtain 708 certificates (e.g., DNS servers on private networks). 710 Implementations compliant with this profile SHOULD implement all of 711 the following items: 713 o TLS False Start [RFC7918] which reduces round-trips by allowing 714 the TLS second flight of messages (ChangeCipherSpec) to also 715 contain the (encrypted) DNS query 717 o Cached Information Extension [RFC7924] which avoids transmitting 718 the server's certificate and certificate chain if the client has 719 cached that information from a previous TLS handshake 721 Guidance specific to TLS is provided in [RFC7858] and that specific 722 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 724 12. IANA Considerations 726 This memo includes no request to IANA. 728 13. Security Considerations 730 Security considerations discussed in [RFC7525], 731 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 733 13.1. Counter-measures to DNS Traffic Analysis 735 This section makes suggestions for measures that can reduce the 736 ability of attackers to infer information pertaining to encrypted 737 client queries by other means (e.g. via an analysis of encrypted 738 traffic size, or via monitoring of resolver to authoritative 739 traffic). 741 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 742 following relevant DNS extensions 744 o EDNS(0) padding [RFC7830], which allows encrypted queries and 745 responses to hide their size. 747 DNS-over-(D)TLS clients SHOULD consider implementing the following 748 relevant DNS extensions 750 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 751 a DNS client does not include an EDNS0 Client Subnet Option with a 752 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 753 potentially leak client address information to the upstream 754 authoritative DNS servers. A DNS client ought to be able to 755 inform the DNS Resolver that it does not want any address 756 information leaked, and the DNS Resolver should honor that 757 request. 759 14. Acknowledgements 761 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 762 [RFC7858] for laying the ground work that this draft builds on and 763 for reviewing the contents. The authors would also like to thank 764 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 765 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and 766 Christian Huitema for review and discussion of the ideas presented 767 here. 769 15. References 771 15.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 779 Subject Alternative Name for Expression of Service Name", 780 RFC 4985, DOI 10.17487/RFC4985, August 2007, 781 . 783 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 784 "Transport Layer Security (TLS) Session Resumption without 785 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 786 January 2008, . 788 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 789 (TLS) Protocol Version 1.2", RFC 5246, 790 DOI 10.17487/RFC5246, August 2008, 791 . 793 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 794 Housley, R., and W. Polk, "Internet X.509 Public Key 795 Infrastructure Certificate and Certificate Revocation List 796 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 797 . 799 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 800 Verification of Domain-Based Application Service Identity 801 within Internet Public Key Infrastructure Using X.509 802 (PKIX) Certificates in the Context of Transport Layer 803 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 804 2011, . 806 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 807 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 808 January 2012, . 810 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 811 of Named Entities (DANE) Transport Layer Security (TLS) 812 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 813 2012, . 815 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 816 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 817 Transport Layer Security (TLS) and Datagram Transport 818 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 819 June 2014, . 821 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 822 "Recommendations for Secure Use of Transport Layer 823 Security (TLS) and Datagram Transport Layer Security 824 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 825 2015, . 827 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 828 Authentication of Named Entities (DANE) Protocol: Updates 829 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 830 October 2015, . 832 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 833 DOI 10.17487/RFC7830, May 2016, 834 . 836 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 837 and P. Hoffman, "Specification for DNS over Transport 838 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 839 2016, . 841 15.2. Informative References 843 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 845 [dnssec-trigger] 846 NLnetLabs, "Dnssec-Trigger", May 2014, 847 . 849 [I-D.ietf-dprive-dnsodtls] 850 Reddy, T., Wing, D., and P. Patil, "Specification for DNS 851 over Datagram Transport Layer Security (DTLS)", draft- 852 ietf-dprive-dnsodtls-12 (work in progress), September 853 2016. 855 [I-D.ietf-tls-dnssec-chain-extension] 856 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 857 Record and DNSSEC Authentication Chain Extension for TLS", 858 draft-ietf-tls-dnssec-chain-extension-01 (work in 859 progress), July 2016. 861 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 862 RFC 2131, DOI 10.17487/RFC2131, March 1997, 863 . 865 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 866 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 867 . 869 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 870 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 871 DOI 10.17487/RFC3646, December 2003, 872 . 874 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 875 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 876 December 2014, . 878 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 879 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 880 2015, . 882 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 883 DOI 10.17487/RFC7626, August 2015, 884 . 886 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 887 Kumari, "Client Subnet in DNS Queries", RFC 7871, 888 DOI 10.17487/RFC7871, May 2016, 889 . 891 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 892 Layer Security (TLS) False Start", RFC 7918, 893 DOI 10.17487/RFC7918, August 2016, 894 . 896 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 897 (TLS) Cached Information Extension", RFC 7924, 898 DOI 10.17487/RFC7924, July 2016, 899 . 901 Appendix A. Server capability probing and caching by DNS clients 903 This section presents a non-normative discussion of how DNS clients 904 might probe for and cache privacy capabilities of DNS servers. 906 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 907 Not all servers will support one or both of these protocols and the 908 well-known port might be blocked by some middleboxes. Clients will 909 be expected to keep track of servers that support DNS-over-TLS and/or 910 DNS-over-DTLS, and those that have been previously authenticated. 912 If no server capability information is available then (unless 913 otherwise specified by the configuration of the DNS client) DNS 914 clients that implement both TLS and DTLS should try to authenticate 915 using both protocols before failing or falling back to a lower 916 security. DNS clients using opportunistic security should try all 917 available servers (possibly in parallel) in order to obtain an 918 authenticated encrypted connection before falling back to a lower 919 security. (RATIONALE: This approach can increase latency while 920 discovering server capabilities but maximizes the chance of sending 921 the query over an authenticated encrypted connection.) 923 Appendix B. Changes between revisions 925 [Note to RFC Editor: please remove this section prior to 926 publication.] 928 B.1. -06 version 930 Introduction: Re-word discussion of Working group charter. 932 Introduction: Re-word first and third bullet point about 'obtaining' 933 a domain name and IP address. 935 Introduction: Update reference to DNS-over-TLS draft. 937 Terminology: Change forwarder/proxy to just forwarder 939 Terminology: Add definition of 'Authentication domain name' and use 940 this throughout 942 Section 4.2: Remove parenthesis in the table. 944 Section 4.2: Change the text after the table as agreed with Paul 945 Hoffman. 947 Section 4.3.1: Change title and remove brackets around last 948 statement. 950 Section 11: Split second paragraph. 952 B.2. -05 version 954 Add more details on detecting passive attacks to section 4.2 956 Changed X.509 to PKIX throughout 958 Change comment about future I-D on usage policies. 960 B.3. -04 version 962 Introduction: Add comment that DNS-over-DTLS draft is Experiments 964 Update 2 I-D references to RFCs. 966 B.4. -03 version 968 Section 9: Update DANE section with better references to RFC7671 and 969 RFC7250 971 B.5. -02 version 973 Introduction: Added paragraph on the background and scope of the 974 document. 976 Introduction and Discussion: Added more information on what a Usage 977 profiles is (and is not) the the two presented here. 979 Introduction: Added paragraph to make a comparison with the Strict 980 profile in RFC7858 clearer. 982 Section 4.2: Re-worked the description of Opportunistic and the 983 table. 985 Section 8.3: Clarified statement about use of DHCP in Opportunistic 986 profile 988 Title abbreviated. 990 B.6. -01 version 992 Section 4.2: Make clear that the Strict Privacy Profile can include 993 meta queries performed using Opportunistic Privacy. 995 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 996 does not guarantee protection against passive attack. 998 Section 4.2: Add sentence discussing client/provider trusted 999 relationships. 1001 Section 5: Add more discussion of detection of active attacks when 1002 using Opportunistic Privacy. 1004 Section 8.2: Clarify description and example. 1006 B.7. draft-ietf-dprive-dtls-and-tls-profiles-00 1008 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1009 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1010 fixed. 1012 Authors' Addresses 1014 Sara Dickinson 1015 Sinodun Internet Technologies 1016 Magdalen Centre 1017 Oxford Science Park 1018 Oxford OX4 4GA 1019 UK 1021 Email: sara@sinodun.com 1022 URI: http://sinodun.com 1024 Daniel Kahn Gillmor 1025 ACLU 1026 125 Broad Street, 18th Floor 1027 New York NY 10004 1028 USA 1030 Email: dkg@fifthhorseman.net 1032 Tirumaleswar Reddy 1033 Cisco Systems, Inc. 1034 Cessna Business Park, Varthur Hobli 1035 Sarjapur Marathalli Outer Ring Road 1036 Bangalore, Karnataka 560103 1037 India 1039 Email: tireddy@cisco.com