idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-02.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 (June 10, 2016) is 2870 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: December 12, 2016 ACLU 6 T. Reddy 7 Cisco 8 June 10, 2016 10 Authentication and (D)TLS Profile for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-02 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 December 12, 2016. 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 . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . 15 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 18 88 Appendix B. Changes between revisions . . . . . . . . . . . . . 19 89 B.1. -02 version . . . . . . . . . . . . . . . . . . . . . . . 19 90 B.2. -01 version . . . . . . . . . . . . . . . . . . . . . . . 19 91 B.3. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 DNS Privacy issues are discussed in [RFC7626]. Two documents that 97 provide DNS privacy between DNS clients and DNS servers are: 99 o Specification for DNS over Transport Layer Security (TLS) 100 [RFC7858], referred to here as simply 'DNS-over-TLS' 102 o DNS-over-DTLS (DNSoD) [I-D.ietf-dprive-dnsodtls], referred to here 103 simply as 'DNS-over-DTLS' 105 Both documents are limited in scope to encrypting DNS messages 106 between stub clients and recursive resolvers and the same scope is 107 applied to this document (see Section 2 and Section 3). The 108 proposals here might be adapted or extended in future to be used for 109 recursive clients and authoritative servers, but this application is 110 out of scope for the DNS PRIVate Exchange (DPRIVE) Working Group per 111 its current charter. 113 This document defines two Usage Profiles (Strict and Opportunistic) 114 for DTLS [RFC6347] and TLS [RFC5246] which define the security 115 properties a user should expect when using that profile to connect to 116 the available DNS servers. In essence: 118 o the Strict Profile requires an encrypted connection and successful 119 authentication of the DNS server which provides strong privacy 120 guarantees (at the expense of providing no DNS service if this is 121 not available). 123 o the Opportunistic Profile will attempt, but does not require, 124 encryption and successful authentication; it therefore provides no 125 privacy guarantees but offers maximum chance of DNS service. 127 Additionally, a number of authentication mechanisms are defined that 128 specify how a DNS client should authenticate a DNS server based on a 129 domain name. In particular, the following is described: 131 o How a DNS client can obtain a domain name for a DNS server to use 132 for (D)TLS authentication. 134 o What are the acceptable credentials a DNS server can present to 135 prove its identity for (D)TLS authentication based on a given 136 domain name. 138 o How a DNS client can verify that any given credential matches the 139 domain name obtained for a DNS server. 141 It should be noted that [RFC7858] includes a description of a 142 specific case of a Strict Usage Profile using a single authentication 143 mechanism (SPKI pinning). This draft generalises the picture by 144 separating the Usage Profile, which is based purely on the security 145 properties it offers the user, from the specific mechanism that is 146 used for authentication. Therefore the "Out-of-band Key-pinned 147 Privacy Profile" described in the DNS-over-TLS draft would qualify as 148 a "Strict Usage Profile" that used SPKI pinning for authentication. 150 This document also defines a (D)TLS protocol profile for use with 151 DNS. This profile defines the configuration options and protocol 152 extensions required of both parties to optimize connection 153 establishment and session resumption for transporting DNS, and to 154 support the authentication mechanisms defined here. 156 2. Terminology 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 Several terms are used specifically in the context of this draft: 164 o DNS client: a DNS stub resolver or forwarder/proxy. In the case 165 of a forwarder, the term "DNS client" is used to discuss the side 166 that sends queries. 168 o DNS server: a DNS recursive resolver or forwarder/proxy. In the 169 case of a forwarder, the term "DNS server" is used to discuss the 170 side that responds to queries. 172 o Privacy-enabling DNS server: A DNS server that: 174 * MUST implement DNS-over-TLS [RFC7858] and MAY implement DNS- 175 over-DTLS [I-D.ietf-dprive-dnsodtls]. 177 * Can offer at least one of the credentials described in 178 Section 9. 180 * Implements the (D)TLS profile described in Section 11. 182 o (D)TLS: For brevity this term is used for statements that apply to 183 both Transport Layer Security [RFC5246] and Datagram Transport 184 Layer Security [RFC6347]. Specific terms will be used for any 185 statement that applies to either protocol alone. 187 o DNS-over-(D)TLS: For brevity this term is used for statements that 188 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS 190 [I-D.ietf-dprive-dnsodtls]. Specific terms will be used for any 191 statement that applies to either protocol alone. 193 o Credential: Information available for a DNS server which proves 194 its identity for authentication purposes. Credentials discussed 195 here include: 197 * X.509 certificate 199 * DNSSEC validated chain to a TLSA record 201 but may also include SPKI pinsets. 203 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 204 to "pin" public key information in a manner similar to HPKP 205 [RFC7469]. An SPKI pinset is a collection of these pins that 206 constrains a DNS server. 208 o Reference Identifier: a Reference Identifier as described in 209 [RFC6125], constructed by the DNS client when performing TLS 210 authentication of a DNS server. 212 3. Scope 214 This document is limited to domain-name-based authentication of DNS 215 servers by DNS clients (as defined in the terminology section), and 216 the (D)TLS profiles needed to support this. As such, the following 217 things are out of scope: 219 o Authentication of authoritative servers by recursive resolvers. 221 o Authentication of DNS clients by DNS servers. 223 o SPKI-pinset-based authentication. This is defined in [RFC7858]. 224 However, Section 10 does describe how to combine that approach 225 with the domain name based mechanism described here. 227 o Any server identifier other than domain names, including IP 228 address, organizational name, country of origin, etc. 230 4. Discussion 232 4.1. Background 234 To protect against passive attacks DNS privacy requires encrypting 235 the query (and response). Such encryption typically provides 236 integrity protection as a side-effect, which means on-path attackers 237 cannot simply inject bogus DNS responses. For DNS privacy to also 238 provide protection against active attackers pretending to be the 239 server, the client must authenticate the server. 241 This draft discusses Usage Profiles, which provide differing levels 242 of privacy guarantees to DNS clients, based on the requirements for 243 authentication and encryption, regardless of the context (for 244 example, which network the client is connected to). A Usage Profile 245 is a distinct concept to a usage policy or usage model, which might 246 dictate which Profile should be used in a particular context 247 (enterprise vs coffee shop), with a particular set of DNS Servers or 248 with reference to other external factors. A description of the 249 variety of usage policies is out of scope of this document, but may 250 be the subject of a future I-D. 252 4.2. Usage Profiles 254 A DNS client has a choice of privacy usage profiles available. This 255 choice is briefly discussed in both [RFC7858] and 256 [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 258 o Strict Privacy: the DNS client requires both an encrypted and 259 authenticated connection to a privacy-enabling DNS Server. A hard 260 failure occurs if this is not available. This requires the client 261 to securely obtain information it can use to authenticate the 262 server. This profile can include some initial meta queries 263 (performed using Opportunistic Privacy) to securely obtain the IP 264 address and authentication information for the privacy-enabling 265 DNS server to which the DNS client will subsequently connect. The 266 rationale for this is that requiring Strict Privacy for such meta 267 queries would introduce significant deployment obstacles. This 268 profile provides strong privacy guarantees to the client. This is 269 discussed in detail in Section 6. 271 o Opportunistic Privacy: the DNS client uses Opportunistic Security 272 as described in [RFC7435] 274 "... the use of cleartext as the baseline communication 275 security policy, with encryption and authentication negotiated 276 and applied to the communication when available." 278 The use of Opportunistic Privacy is intended to support 279 incremental deployment of security capabilities with a view to 280 widespread adoption of Strict Privacy. It should be employed when 281 the DNS client might otherwise settle for cleartext; it provides 282 the maximum protection available. As described in [RFC7435] it 283 might result in 285 * an encrypted and authenticated connection 286 * an encrypted connection 288 * a clear text connection 290 * hard failure 292 depending on the fallback logic of the client, the available 293 authentication information and the capabilities of the DNS Server. 294 In the first three cases the DNS client is willing to continue 295 with a connection to the DNS Server and perform resolution of 296 queries. 298 To compare the two Usage profiles the table below shows successful 299 Strict Privacy along side the 3 possible successful outcomes of 300 Opportunistic Privacy. In the best case scenario for Opportunistic 301 (authenticated and encrypted connection) it is equivalent to Strict 302 Privacy. In the worst case scenario it is equivalent to clear text. 303 Clients using Opportunistic Privacy SHOULD try for the best case but 304 MAY fallback to intermediate cases and eventually the worst case 305 scenario in order to obtain a response. It therefore provides no 306 privacy guarantee to the user and varying protection depending on 307 what kind of connection is actually used. Note that there is no 308 requirement in Opportunistic to notify the user what type of 309 connection is actually used, the detection described below is only 310 possible if such connection information is available. This is 311 discussed in Section 5. 313 +---------------+------------+------------------+-----------------+ 314 | Usage Profile | Connection | Passive Attacker | Active Attacker | 315 +---------------+------------+------------------+-----------------+ 316 | Strict | A, E | P | P | 317 | Opportunistic | A, E | P | P | 318 | Opportunistic | E | P | N (D) | 319 | Opportunistic | | N (D) | N (D) | 320 +---------------+------------+------------------+-----------------+ 322 P == protection; N == no protection; D == detection is possible; A == 323 Authenticated Connection; E == Encrypted Connection 325 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 327 Since Strict Privacy provides the strongest privacy guarantees it is 328 preferable to Opportunistic Privacy. 330 However since the two profiles require varying levels of 331 configuration (or a trusted relationship with a provider) and DNS 332 server capabilities, DNS clients will need to carefully select which 333 profile to use based on their communication privacy needs. For the 334 case where a client has a trusted relationship with a provider it is 335 expected that the provider will provide either a domain name or SPKI 336 pinset via a secure out-of-band mechanism and therefore Strict 337 Privacy should be used. 339 4.2.1. DNS Resolution 341 A DNS client SHOULD select a particular usage profile when resolving 342 a query. A DNS client MUST NOT fallback from Strict Privacy to 343 Opportunistic Privacy during the resolution process as this could 344 invalidate the protection offered against active attackers. 346 4.3. Authentication 348 This document describes authentication mechanisms that can be used in 349 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 351 4.3.1. DNS-over-(D)TLS Bootstrapping Problems 353 Many (D)TLS clients use PKIX authentication [RFC6125] based on a 354 domain name for the server they are contacting. These clients 355 typically first look up the server's network address in the DNS 356 before making this connection. A DNS client therefore has a 357 bootstrap problem. DNS clients typically know only the IP address of 358 a DNS server. 360 As such, before connecting to a DNS server, a DNS client needs to 361 learn the domain name it should associate with the IP address of a 362 DNS server for authentication purposes. Sources of domains names are 363 discussed in Section 7 and Section 8. 365 One advantage of this domain name based approach is that it 366 encourages association of stable, human recognisable identifiers with 367 secure DNS service providers. 369 4.3.2. Credential Verification 371 The use of SPKI pinset verification is discussed in [RFC7858]. 373 In terms of domain name based verification, once a domain name is 374 known for a DNS server a choice of mechanisms can be used for 375 authentication. Section 9 discusses these mechanisms in detail, 376 namely X.509 certificate based authentication and DANE. 378 Note that the use of DANE adds requirements on the ability of the 379 client to get validated DNSSEC results. This is discussed in more 380 detail in Section 9.2. 382 4.3.3. Implementation guidance 384 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 385 Additional considerations relating to general implementation 386 guidelines are discussed in both Section 13 and in Appendix A. 388 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 390 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 391 which MAY be used for DNS-over-(D)TLS. 393 DNS clients issuing queries under an opportunistic profile which know 394 of a domain name or SPKI pinset for a given privacy-enabling DNS 395 server MAY choose to try to authenticate the server using the 396 mechanisms described here. This is useful for detecting (but not 397 preventing) active attack, since the fact that authentication 398 information is available indicates that the server in question is a 399 privacy-enabling DNS server to which it should be possible to 400 establish an authenticated, encrypted connection. In this case, 401 whilst a client cannot know the reason for an authentication failure, 402 from a privacy standpoint the client should consider an active attack 403 in progress and proceed under that assumption. Attempting 404 authentication is also useful for debugging or diagnostic purposes if 405 there are means to report the result. This information can provide a 406 basis for a DNS client to switch to (preferred) Strict Privacy where 407 it is viable. 409 6. Authentication in Strict DNS-over(D)TLS Privacy 411 To authenticate a privacy-enabling DNS server, a DNS client needs to 412 know the domain name for each server it is willing to contact. This 413 is necessary to protect against active attacks on DNS privacy. 415 A DNS client requiring Strict Privacy MUST either use one of the 416 sources listed in Section 8 to obtain a domain name for the server it 417 contacts, or use an SPKI pinset as described in [RFC7858]. 419 A DNS client requiring Strict Privacy MUST only attempt to connect to 420 DNS servers for which either a domain name or a SPKI pinset is known 421 (or both). The client MUST use the available verification mechanisms 422 described in Section 9 to authenticate the server, and MUST abort 423 connections to a server when no verification mechanism succeeds. 425 With Strict Privacy, the DNS client MUST NOT commence sending DNS 426 queries until at least one of the privacy-enabling DNS servers 427 becomes available. 429 A privacy-enabling DNS server may be temporarily unavailable when 430 configuring a network. For example, for clients on networks that 431 require registration through web-based login (a.k.a. "captive 432 portals"), such registration may rely on DNS interception and 433 spoofing. Techniques such as those used by DNSSEC-trigger 434 [dnssec-trigger] MAY be used during network configuration, with the 435 intent to transition to the designated privacy-enabling DNS servers 436 after captive portal registration. The system MUST alert by some 437 means that the DNS is not private during such bootstrap. 439 7. In Band Source of Domain Name: SRV Service Label 441 This specification adds a SRV service label "domain-s" for privacy- 442 enabling DNS servers. 444 Example service records (for TLS and DTLS respectively): 446 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 447 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 449 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 451 8. Out of Band Sources of Domain Name 453 8.1. Full direct configuration 455 DNS clients may be directly and securely provisioned with the domain 456 name of each privacy-enabling DNS server. For example, using a 457 client specific configuration file or API. 459 In this case, direct configuration for a DNS client would consist of 460 both an IP address and a domain name for each DNS server. 462 8.2. Direct configuration of name only 464 A DNS client may be configured directly and securely with only the 465 domain name of its privacy-enabling DNS server. For example, using a 466 client specific configuration file or API. 468 A DNS client might learn of a default recursive DNS resolver from an 469 untrusted source (such as DHCP's DNS server option [RFC3646]). It 470 can then use opportunistic DNS connections to untrusted recursive DNS 471 resolver to establish the IP address of the intended privacy-enabling 472 DNS server by doing a lookup of SRV records. Such records MUST be 473 validated using DNSSEC. Private DNS resolution can now be done by 474 the DNS client against the configured privacy-enabling DNS server. 476 Example: 478 o A DNSSEC validating DNS client is configured with the domain name 479 dns.example.net for a privacy-enabling DNS server 481 o Using Opportunistic Privacy to a default DNS resolver (acquired, 482 for example, using DHCP) the client performs look ups for 484 * SRV record for _domain-s._tcp.dns.example.net to obtain the 485 server host name 487 * A and/or AAAA lookups to obtain IP address for the server host 488 name 490 o Client validates all the records obtained in the previous step 491 using DNSSEC. 493 o If the records successfully validate the client proceeds to 494 connect to the privacy-enabling DNS server using Strict Privacy. 496 A DNS client so configured that successfully connects to a privacy- 497 enabling DNS server MAY choose to locally cache the looked up 498 addresses in order to not have to repeat the opportunistic lookup. 500 8.3. DHCP 502 Some clients may have an established trust relationship with a known 503 DHCP [RFC2131] server for discovering their network configuration. 504 In the typical case, such a DHCP server provides a list of IP 505 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 506 not provide a domain name for the DNS server itself. 508 In the future, a DHCP server might use a DHCP extension to provide a 509 list of domain names for the offered DNS servers, which correspond to 510 IP addresses listed. 512 Use of such a mechanism with any DHCP server when using an 513 Opportunistic profile is reasonable, given the security expectation 514 of that profile. However when using a Strict profile the DHCP 515 servers used as sources of domain names MUST be considered secure and 516 trustworthy. This document does not attempt to describe secured and 517 trusted relationships to DHCP servers. 519 [NOTE: It is noted (at the time of writing) that whilst some 520 implementation work is in progress to secure IPv6 connections for 521 DHCP, IPv4 connections have received little to no implementation 522 attention in this area.] 524 9. Credential Verification 526 9.1. X.509 Certificate Based Authentication 528 When a DNS client configured with a domain name connects to its 529 configured DNS server over (D)TLS, the server may present it with an 530 X.509 certificate. In order to ensure proper authentication, DNS 531 clients MUST verify the entire certification path per [RFC5280]. The 532 DNS client additionally uses [RFC6125] validation techniques to 533 compare the domain name to the certificate provided. 535 A DNS client constructs two Reference Identifiers for the server 536 based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- 537 ID is simply the domain name itself. The SRV-ID uses a "_domain-s." 538 prefix. So if the configured domain name is "dns.example.com", then 539 the two Reference Identifiers are: 541 DNS-ID: dns.example.com 543 SRV-ID: _domain-s.dns.example.com 545 If either of the Reference Identifiers are found in the X.509 546 certificate's subjectAltName extension as described in section 6 of 547 [RFC6125], the DNS client should accept the certificate for the 548 server. 550 A compliant DNS client MUST only inspect the certificate's 551 subjectAltName extension for these Reference Identifiers. In 552 particular, it MUST NOT inspect the Subject field itself. 554 9.2. DANE 556 DANE [RFC6698] provides mechanisms to root certificate and raw public 557 keys trust with DNSSEC. However this requires a domain name which 558 must be obtained via a trusted source. 560 It is noted that [RFC6698] says 562 "Clients that validate the DNSSEC signatures themselves MUST use 563 standard DNSSEC validation procedures. Clients that rely on 564 another entity to perform the DNSSEC signature validation MUST use 565 a secure mechanism between themselves and the validator." 567 The specific DANE record would take the form: 569 _853._tcp.[server-domain-name] for TLS 571 _853._udp.[server-domain-name] for DTLS 573 9.2.1. Direct DNS Lookup 575 The DNS client MAY choose to perform the DNS lookups to retrieve the 576 required DANE records itself. The DNS queries for such DANE records 577 MAY use opportunistic encryption or be in the clear to avoid trust 578 recursion. The records MUST be validated using DNSSEC as described 579 above in [RFC6698]. 581 9.2.2. TLS DNSSEC Chain extension 583 The DNS client MAY offer the TLS extension described in 584 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 585 this extension, it can provide the full chain to the client in the 586 handshake. 588 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 589 capable of validating the full DNSSEC authentication chain down to 590 the leaf. If the supplied DNSSEC chain does not validate, the client 591 MUST ignore the DNSSEC chain and validate only via other supplied 592 credentials. 594 [ TODO: specify guidance for DANE parameters to be used here. For 595 example, a suggestion to use Certificate Usage of 3 (EE-DANE) 596 (section 2.1.1 of [RFC6698]) and a Selector of 1 (SPKI) (section 597 2.1.2) would completely remove all X.509 and certificate authorities 598 from the verification path and allows for private certification ] 600 [ TODO: discuss combination of DNSSEC Chain Extension with cert 601 validation. Note that the combination depends on the Certificate 602 Usage value of the TLSA response. ] 604 10. Combined Credentials with SPKI Pinsets 606 The SPKI pinset profile described in [RFC7858] MAY be used with DNS- 607 over-(D)TLS. 609 This draft does not make explicit recommendations about how a SPKI 610 pinset based authentication mechanism should be combined with a 611 domain based mechanism from an operator perspective. However it can 612 be envisaged that a DNS server operator may wish to make both an SPKI 613 pinset and a domain name available to allow clients to choose which 614 mechanism to use. Therefore, the following is guidance on how 615 clients ought to behave if they choose to configure both, as is 616 possible in HPKP [RFC7469]. 618 A DNS client that is configured with both a domain name and a SPKI 619 pinset for a DNS sever SHOULD match on both a valid credential for 620 the domain name and a valid SPKI pinset when connecting to that DNS 621 server. 623 11. (D)TLS Protocol Profile 625 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 627 There are known attacks on (D)TLS, such as machine-in-the-middle and 628 protocol downgrade. These are general attacks on (D)TLS and not 629 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 630 discussion of these security issues. Clients and servers MUST adhere 631 to the (D)TLS implementation recommendations and security 632 considerations of [RFC7525] except with respect to (D)TLS version. 633 Since encryption of DNS using (D)TLS is virtually a green-field 634 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 635 later. 637 Implementations MUST NOT offer or provide TLS compression, since 638 compression can leak significant amounts of information, especially 639 to a network observer capable of forcing the user to do an arbitrary 640 DNS lookup in the style of the CRIME attacks [CRIME]. 642 Implementations compliant with this profile MUST implement all of the 643 following items: 645 o TLS session resumption without server-side state [RFC5077] which 646 eliminates the need for the server to retain cryptographic state 647 for longer than necessary. 649 o Raw public keys [RFC7250] which reduce the size of the 650 ServerHello, and can be used by servers that cannot obtain 651 certificates (e.g., DNS servers on private networks). 653 Implementations compliant with this profile SHOULD implement all of 654 the following items: 656 o TLS False Start [I-D.ietf-tls-falsestart] which reduces round- 657 trips by allowing the TLS second flight of messages 658 (ChangeCipherSpec) to also contain the (encrypted) DNS query 660 o Cached Information Extension [I-D.ietf-tls-cached-info] which 661 avoids transmitting the server's certificate and certificate chain 662 if the client has cached that information from a previous TLS 663 handshake 665 [NOTE: The references to (works in progress) should be upgraded to 666 MUST's if those references become RFC's prior to publication of this 667 document.] 668 Guidance specific to TLS is provided in [RFC7858] and that specific 669 to DTLS it is provided in[I-D.ietf-dprive-dnsodtls]. 671 12. IANA Considerations 673 This memo includes no request to IANA. 675 13. Security Considerations 677 Security considerations discussed in [RFC7525], 678 [I-D.ietf-dprive-dnsodtls] and [RFC7858] apply to this document. 680 13.1. Counter-measures to DNS Traffic Analysis 682 This section makes suggestions for measures that can reduce the 683 ability of attackers to infer information pertaining to encrypted 684 client queries by other means (e.g. via an analysis of encrypted 685 traffic size, or via monitoring of resolver to authoritative 686 traffic). 688 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 689 following relevant DNS extensions 691 o EDNS(0) padding [RFC7830], which allows encrypted queries and 692 responses to hide their size. 694 DNS-over-(D)TLS clients SHOULD consider implementing the following 695 relevant DNS extensions 697 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 698 a DNS client does not include an EDNS0 Client Subnet Option with a 699 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 700 potentially leak client address information to the upstream 701 authoritative DNS servers. A DNS client ought to be able to 702 inform the DNS Resolver that it does not want any address 703 information leaked, and the DNS Resolver should honor that 704 request. 706 14. Acknowledgements 708 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 709 [RFC7858] for laying the ground work that this draft builds on and 710 for reviewing the contents. The authors would also like to thank 711 John Dickinson, Shumon Huque, Melinda Shore, Gowri Visweswaran, Ray 712 Bellis, Stephane Bortzmeyer, Jinmei Tatuya, Paul Hoffman and 713 Christian Huitema for review and discussion of the ideas presented 714 here. 716 15. References 718 15.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 726 Subject Alternative Name for Expression of Service Name", 727 RFC 4985, DOI 10.17487/RFC4985, August 2007, 728 . 730 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 731 "Transport Layer Security (TLS) Session Resumption without 732 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 733 January 2008, . 735 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 736 (TLS) Protocol Version 1.2", RFC 5246, 737 DOI 10.17487/RFC5246, August 2008, 738 . 740 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 741 Housley, R., and W. Polk, "Internet X.509 Public Key 742 Infrastructure Certificate and Certificate Revocation List 743 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 744 . 746 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 747 Verification of Domain-Based Application Service Identity 748 within Internet Public Key Infrastructure Using X.509 749 (PKIX) Certificates in the Context of Transport Layer 750 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 751 2011, . 753 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 754 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 755 January 2012, . 757 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 758 of Named Entities (DANE) Transport Layer Security (TLS) 759 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 760 2012, . 762 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 763 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 764 Transport Layer Security (TLS) and Datagram Transport 765 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 766 June 2014, . 768 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 769 "Recommendations for Secure Use of Transport Layer 770 Security (TLS) and Datagram Transport Layer Security 771 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 772 2015, . 774 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 775 DOI 10.17487/RFC7830, May 2016, 776 . 778 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 779 and P. Hoffman, "Specification for DNS over Transport 780 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 781 2016, . 783 15.2. Informative References 785 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 787 [dnssec-trigger] 788 NLnetLabs, "Dnssec-Trigger", May 2014, 789 . 791 [I-D.ietf-dprive-dnsodtls] 792 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 793 (DNSoD)", draft-ietf-dprive-dnsodtls-06 (work in 794 progress), April 2016. 796 [I-D.ietf-tls-cached-info] 797 Santesson, S. and H. Tschofenig, "Transport Layer Security 798 (TLS) Cached Information Extension", draft-ietf-tls- 799 cached-info-23 (work in progress), May 2016. 801 [I-D.ietf-tls-dnssec-chain-extension] 802 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 803 Record and DNSSEC Authentication Chain Extension for TLS", 804 draft-ietf-tls-dnssec-chain-extension-00 (work in 805 progress), June 2016. 807 [I-D.ietf-tls-falsestart] 808 Langley, A., Modadugu, N., and B. Moeller, "Transport 809 Layer Security (TLS) False Start", draft-ietf-tls- 810 falsestart-02 (work in progress), May 2016. 812 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 813 RFC 2131, DOI 10.17487/RFC2131, March 1997, 814 . 816 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 817 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 818 . 820 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 821 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 822 DOI 10.17487/RFC3646, December 2003, 823 . 825 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 826 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 827 December 2014, . 829 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 830 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 831 2015, . 833 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 834 DOI 10.17487/RFC7626, August 2015, 835 . 837 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 838 Kumari, "Client Subnet in DNS Queries", RFC 7871, 839 DOI 10.17487/RFC7871, May 2016, 840 . 842 Appendix A. Server capability probing and caching by DNS clients 844 This section presents a non-normative discussion of how DNS clients 845 might probe for and cache privacy capabilities of DNS servers. 847 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 848 Not all servers will support one or both of these protocols and the 849 well-known port might be blocked by some middleboxes. Clients will 850 be expected to keep track of servers that support DNS-over-TLS and/or 851 DNS-over-DTLS, and those that have been previously authenticated. 853 If no server capability information is available then (unless 854 otherwise specified by the configuration of the DNS client) DNS 855 clients that implement both TLS and DTLS should try to authenticate 856 using both protocols before failing or falling back to a lower 857 security. DNS clients using opportunistic security should try all 858 available servers (possibly in parallel) in order to obtain an 859 authenticated encrypted connection before falling back to a lower 860 security. (RATIONALE: This approach can increase latency while 861 discovering server capabilities but maximizes the chance of sending 862 the query over an authenticated encrypted connection.) 864 Appendix B. Changes between revisions 866 [Note to RFC Editor: please remove this section prior to 867 publication.] 869 B.1. -02 version 871 Introduction: Added paragraph on the background and scope of the 872 document. 874 Introduction and Discussion: Added more information on what a Usage 875 profiles is (and is not) the the two presented here. 877 Introduction: Added paragraph to make a comparison with the Strict 878 profile in RFC7858 clearer. 880 Section 4.2: Re-worked the description of Opportunistic and the 881 table. 883 Section 8.3: Clarified statement about use of DHCP in Opportunistic 884 profile 886 Title abbreviated. 888 B.2. -01 version 890 Section 4.2: Make clear that the Strict Privacy Profile can include 891 meta queries performed using Opportunistic Privacy. 893 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 894 does not guarantee protection against passive attack. 896 Section 4.2: Add sentence discussing client/provider trusted 897 relationships. 899 Section 5: Add more discussion of detection of active attacks when 900 using Opportunistic Privacy. 902 Section 8.2: Clarify description and example. 904 B.3. draft-ietf-dprive-dtls-and-tls-profiles-00 906 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 907 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 908 fixed. 910 Authors' Addresses 912 Sara Dickinson 913 Sinodun Internet Technologies 914 Magdalen Centre 915 Oxford Science Park 916 Oxford OX4 4GA 917 UK 919 Email: sara@sinodun.com 920 URI: http://sinodun.com 922 Daniel Kahn Gillmor 923 ACLU 924 125 Broad Street, 18th Floor 925 New York NY 10004 926 USA 928 Email: dkg@fifthhorseman.net 930 Tirumaleswar Reddy 931 Cisco Systems, Inc. 932 Cessna Business Park, Varthur Hobli 933 Sarjapur Marathalli Outer Ring Road 934 Bangalore, Karnataka 560103 935 India 937 Email: tireddy@cisco.com