idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-01.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 (March 21, 2016) is 2952 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 (-08) exists of draft-ietf-dnsop-edns-client-subnet-06 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-05 == Outdated reference: A later version (-23) exists of draft-ietf-tls-cached-info-22 == Outdated reference: A later version (-02) exists of draft-ietf-tls-falsestart-01 -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 5 errors (**), 0 flaws (~~), 5 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: September 22, 2016 ACLU 6 T. Reddy 7 Cisco 8 March 21, 2016 10 Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS 11 draft-ietf-dprive-dtls-and-tls-profiles-01 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 September 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.2. Usage Profiles . . . . . . . . . . . . . . . . . . . . . 5 61 4.3. Authentication . . . . . . . . . . . . . . . . . . . . . 6 62 4.3.1. DNS-over-(D)TLS Bootstrapping Problems . . . . . . . 6 63 4.3.2. Credential Verification . . . . . . . . . . . . . . . 7 64 4.3.3. Implementation guidance . . . . . . . . . . . . . . . 7 65 5. Authentication in Opportunistic DNS-over(D)TLS Privacy . . . 7 66 6. Authentication in Strict DNS-over(D)TLS Privacy . . . . . . . 8 67 7. In Band Source of Domain Name: SRV Service Label . . . . . . 8 68 8. Out of Band Sources of Domain Name . . . . . . . . . . . . . 8 69 8.1. Full direct configuration . . . . . . . . . . . . . . . . 9 70 8.2. Direct configuration of name only . . . . . . . . . . . . 9 71 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9. Credential Verification . . . . . . . . . . . . . . . . . . . 10 73 9.1. X.509 Certificate Based Authentication . . . . . . . . . 10 74 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 11 76 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 11 77 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 12 78 11. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 12 79 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 13.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 13 82 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 85 15.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Appendix A. Server capability probing and caching by DNS clients 17 87 Appendix B. Changes between revisions . . . . . . . . . . . . . 17 88 B.1. -01 version . . . . . . . . . . . . . . . . . . . . . . . 17 89 B.2. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 18 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 92 1. Introduction 94 The DPRIVE working group has two active documents that provide DNS 95 privacy between DNS clients and DNS servers (to address the concerns 96 in [RFC7626]): 98 o DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] 100 o DNS-over-DTLS [I-D.ietf-dprive-dnsodtls] 102 This document defines usage profiles and authentication mechanisms 103 for DTLS [RFC6347] and TLS [RFC5246] that specify how a DNS client 104 should authenticate a DNS server based on a domain name. In 105 particular, it describes: 107 o How a DNS client can obtain a domain name for a DNS server to use 108 for (D)TLS authentication. 110 o What are the acceptable credentials a DNS server can present to 111 prove its identity for (D)TLS authentication based on a given 112 domain name. 114 o How a DNS client can verify that any given credential matches the 115 domain name obtained for a DNS server. 117 This document also defines a (D)TLS protocol profile for use with 118 DNS. This profile defines the configuration options and protocol 119 extensions required of both parties to optimize connection 120 establishment and session resumption for transporting DNS, and to 121 support the authentication profiles defined here. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 Several terms are used specifically in the context of this draft: 131 o DNS client: a DNS stub resolver or forwarder/proxy. In the case 132 of a forwarder, the term "DNS client" is used to discuss the side 133 that sends queries. 135 o DNS server: a DNS recursive resolver or forwarder/proxy. In the 136 case of a forwarder, the term "DNS server" is used to discuss the 137 side that responds to queries. 139 o Privacy-enabling DNS server: A DNS server that: 141 * MUST implement DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] and 142 MAY implement DNS-over-DTLS [I-D.ietf-dprive-dnsodtls]. 144 * Can offer at least one of the credentials described in 145 Section 9. 147 * Implements the (D)TLS profile described in Section 11. 149 o (D)TLS: For brevity this term is used for statements that apply to 150 both Transport Layer Security [RFC5246] and Datagram Transport 151 Layer Security [RFC6347]. Specific terms will be used for any 152 statement that applies to either protocol alone. 154 o DNS-over-(D)TLS: For brevity this term is used for statements that 155 apply to both DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] and DNS- 156 over-DTLS [I-D.ietf-dprive-dnsodtls]. Specific terms will be used 157 for any statement that applies to either protocol alone. 159 o Credential: Information available for a DNS server which proves 160 its identity for authentication purposes. Credentials discussed 161 here include: 163 * X.509 certificate 165 * DNSSEC validated chain to a TLSA record 167 but may also include SPKI pinsets. 169 o SPKI Pinsets: [I-D.ietf-dprive-dns-over-tls] describes the use of 170 cryptographic digests to "pin" public key information in a manner 171 similar to HPKP [RFC7469]. An SPKI pinset is a collection of 172 these pins that constrains a DNS server. 174 o Reference Identifier: a Reference Identifier as described in 175 [RFC6125], constructed by the DNS client when performing TLS 176 authentication of a DNS server. 178 3. Scope 180 This document is limited to domain-name-based authentication of DNS 181 servers by DNS clients (as defined in the terminology section), and 182 the (D)TLS profiles needed to support this. As such, the following 183 things are out of scope: 185 o Authentication of authoritative servers by recursive resolvers. 187 o Authentication of DNS clients by DNS servers. 189 o SPKI-pinset-based authentication. This is defined in 190 [I-D.ietf-dprive-dns-over-tls]. However, Section 10 does describe 191 how to combine that approach with the domain name based mechanism 192 described here. 194 o Any server identifier other than domain names, including IP 195 address, organizational name, country of origin, etc. 197 4. Discussion 199 4.1. Background 201 To protect against passive attacks DNS privacy requires encrypting 202 the query (and response). Such encryption typically provides 203 integrity protection as a side-effect, which means on-path attackers 204 cannot simply inject bogus DNS responses. For DNS privacy to also 205 provide protection against active attackers pretending to be the 206 server, the client must authenticate the server. 208 4.2. Usage Profiles 210 A DNS client has a choice of privacy usage profiles available. This 211 choice is briefly discussed in both [I-D.ietf-dprive-dns-over-tls] 212 and [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 214 o Strict Privacy: the DNS client requires both an encrypted and 215 authenticated connection to a privacy-enabling DNS Server. A hard 216 failure occurs if this is not available. This requires the client 217 to securely obtain information it can use to authenticate the 218 server. This profile can include some initial meta queries 219 (performed using Opportunistic Privacy) to securely obtain the IP 220 address and authentication information for the privacy-enabling 221 DNS server to which the DNS client will subsequently connect. The 222 rationale for this is that requiring Strict Privacy for such meta 223 queries would introduce significant deployment obstacles. This 224 profile provides strong privacy guarantees to the client. This is 225 discussed in detail in Section 6. 227 o Opportunistic Privacy: the DNS client uses Opportunistic Security 228 as described in [RFC7435] 230 "... the use of cleartext as the baseline communication 231 security policy, with encryption and authentication negotiated 232 and applied to the communication when available." 234 In the best case scenario (authenticated and encrypted connection) 235 this is equivalent to Strict Privacy, in the worst case (clear 236 text connection) this is equivalent to No Privacy. Clients will 237 try for the best case but are willing to fallback to intermediate 238 cases and eventually the worst case scenario in order to obtain a 239 response. This provides an undetermined privacy guarantee to the 240 user depending on what kind of connection is actually used. This 241 is discussed in Section 5. 243 o No Privacy: the DNS client does not require or attempt to use 244 either encryption or authentication. Queries are always sent in 245 clear text. This provides no privacy guarantees to the client. 247 +-----------------------+------------------+-----------------+ 248 | Usage Profile | Passive Attacker | Active Attacker | 249 +-----------------------+------------------+-----------------+ 250 | No Privacy | N | N | 251 | Opportunistic Privacy | N (D) | N (D) | 252 | Strict Privacy | P | P | 253 +-----------------------+------------------+-----------------+ 255 P == protection; N == no protection; D == detection is possible 257 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 259 Since Strict Privacy provides the strongest privacy guarantees it is 260 preferable to Opportunistic Privacy which is preferable to No 261 Privacy. However since the different profiles require varying levels 262 of configuration (or a trusted relationship with a provider) DNS 263 clients will need to carefully select which profile to use based on 264 their communication privacy needs. For the case where a client has a 265 trusted relationship with a provider it is expected that the provider 266 will provide either a domain name or SPKI pinset via a secure out-of- 267 band mechanism and therefore Strict Privacy should be used. 269 A DNS client SHOULD select a particular usage profile when resolving 270 a query. A DNS client MUST NOT fallback from Strict Privacy to 271 Opportunistic Privacy during the resolution process as this could 272 invalidate the protection offered against active attackers. 274 4.3. Authentication 276 This document describes authentication mechanisms that can be used in 277 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 279 4.3.1. DNS-over-(D)TLS Bootstrapping Problems 281 Many (D)TLS clients use PKIX authentication [RFC6125] based on a 282 domain name for the server they are contacting. These clients 283 typically first look up the server's network address in the DNS 284 before making this connection. A DNS client therefore has a 285 bootstrap problem. DNS clients typically know only the IP address of 286 a DNS server. 288 As such, before connecting to a DNS server, a DNS client needs to 289 learn the domain name it should associate with the IP address of a 290 DNS server for authentication purposes. Sources of domains names are 291 discussed in Section 7 and Section 8. 293 One advantage of this domain name based approach is that it 294 encourages association of stable, human recognisable identifiers with 295 secure DNS service providers. 297 4.3.2. Credential Verification 299 The use of SPKI pinset verification is discussed in 300 [I-D.ietf-dprive-dns-over-tls]. 302 In terms of domain name based verification, once a domain name is 303 known for a DNS server a choice of mechanisms can be used for 304 authentication. Section 9 discusses these mechanisms in detail, 305 namely X.509 certificate based authentication and DANE. 307 Note that the use of DANE adds requirements on the ability of the 308 client to get validated DNSSEC results. This is discussed in more 309 detail in Section 9.2. 311 4.3.3. Implementation guidance 313 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 314 Additional considerations relating to general implementation 315 guidelines are discussed in both Section 13 and in Appendix A. 317 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 319 An Opportunistic Security [RFC7435] profile is described in 320 [I-D.ietf-dprive-dns-over-tls] which MAY be used for DNS-over-(D)TLS. 322 DNS clients issuing queries under an opportunistic profile which know 323 of a domain name or SPKI pinset for a given privacy-enabling DNS 324 server MAY choose to try to authenticate the server using the 325 mechanisms described here. This is useful for detecting (but not 326 preventing) active attack, since the fact that authentication 327 information is available indicates that the server in question is a 328 privacy-enabling DNS server to which it should be possible to 329 establish an authenticated, encrypted connection. In this case, 330 whilst a client cannot know the reason for an authentication failure, 331 from a privacy standpoint the client should consider an active attack 332 in progress and proceed under that assumption. Attempting 333 authentication is also useful for debugging or diagnostic purposes if 334 there are means to report the result. This information can provide a 335 basis for a DNS client to switch to (preferred) Strict Privacy where 336 it is viable. 338 6. Authentication in Strict DNS-over(D)TLS Privacy 340 To authenticate a privacy-enabling DNS server, a DNS client needs to 341 know the domain name for each server it is willing to contact. This 342 is necessary to protect against active attacks on DNS privacy. 344 A DNS client requiring Strict Privacy MUST either use one of the 345 sources listed in Section 8 to obtain a domain name for the server it 346 contacts, or use an SPKI pinset as described in 347 [I-D.ietf-dprive-dns-over-tls]. 349 A DNS client requiring Strict Privacy MUST only attempt to connect to 350 DNS servers for which either a domain name or a SPKI pinset is known 351 (or both). The client MUST use the available verification mechanisms 352 described in Section 9 to authenticate the server, and MUST abort 353 connections to a server when no verification mechanism succeeds. 355 With Strict Privacy, the DNS client MUST NOT commence sending DNS 356 queries until at least one of the privacy-enabling DNS servers 357 becomes available. 359 A privacy-enabling DNS server may be temporarily unavailable when 360 configuring a network. For example, for clients on networks that 361 require registration through web-based login (a.k.a. "captive 362 portals"), such registration may rely on DNS interception and 363 spoofing. Techniques such as those used by DNSSEC-trigger 364 [dnssec-trigger] MAY be used during network configuration, with the 365 intent to transition to the designated privacy-enabling DNS servers 366 after captive portal registration. The system MUST alert by some 367 means that the DNS is not private during such bootstrap. 369 7. In Band Source of Domain Name: SRV Service Label 371 This specification adds a SRV service label "domain-s" for privacy- 372 enabling DNS servers. 374 Example service records (for TLS and DTLS respectively): 376 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 377 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 379 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 381 8. Out of Band Sources of Domain Name 382 8.1. Full direct configuration 384 DNS clients may be directly and securely provisioned with the domain 385 name of each privacy-enabling DNS server. For example, using a 386 client specific configuration file or API. 388 In this case, direct configuration for a DNS client would consist of 389 both an IP address and a domain name for each DNS server. 391 8.2. Direct configuration of name only 393 A DNS client may be configured directly and securely with only the 394 domain name of its privacy-enabling DNS server. For example, using a 395 client specific configuration file or API. 397 A DNS client might learn of a default recursive DNS resolver from an 398 untrusted source (such as DHCP's DNS server option [RFC3646]). It 399 can then use opportunistic DNS connections to untrusted recursive DNS 400 resolver to establish the IP address of the intended privacy-enabling 401 DNS server by doing a lookup of SRV records. Such records MUST be 402 validated using DNSSEC. Private DNS resolution can now be done by 403 the DNS client against the configured privacy-enabling DNS server. 405 Example: 407 o A DNSSEC validating DNS client is configured with the domain name 408 dns.example.net for a privacy-enabling DNS server 410 o Using Opportunistic Privacy to a default DNS resolver (acquired, 411 for example, using DHCP) the client performs look ups for 413 * SRV record for _domain-s._tcp.dns.example.net to obtain the 414 server host name 416 * A and/or AAAA lookups to obtain IP address for the server host 417 name 419 o Client validates all the records obtained in the previous step 420 using DNSSEC. 422 o If the records successfully validate the client proceeds to 423 connect to the privacy-enabling DNS server using Strict Privacy. 425 A DNS client so configured that successfully connects to a privacy- 426 enabling DNS server MAY choose to locally cache the looked up 427 addresses in order to not have to repeat the opportunistic lookup. 429 8.3. DHCP 431 Some clients may have an established trust relationship with a known 432 DHCP [RFC2131] server for discovering their network configuration. 433 In the typical case, such a DHCP server provides a list of IP 434 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 435 not provide a domain name for the DNS server itself. 437 A DHCP server might use a DHCP extension to provide a list of domain 438 names for the offered DNS servers, which correspond to IP addresses 439 listed. 441 Note that this requires the client to trust the DHCP server, and to 442 have a secured/authenticated connection to it. Therefore this 443 mechanism may be limited to only certain environments. This document 444 does not attempt to describe secured and trusted relationships to 445 DHCP servers. 447 [NOTE: It is noted (at the time of writing) that whilst some 448 implementation work is in progress to secure IPv6 connections for 449 DHCP, IPv4 connections have received little to no implementation 450 attention in this area.] 452 [QUESTION: The authors would like to solicit feedback on the use of 453 DHCP to determine whether to pursue a new DHCP option in a later 454 version of this draft, or defer it.] 456 9. Credential Verification 458 9.1. X.509 Certificate Based Authentication 460 When a DNS client configured with a domain name connects to its 461 configured DNS server over (D)TLS, the server may present it with an 462 X.509 certificate. In order to ensure proper authentication, DNS 463 clients MUST verify the entire certification path per [RFC5280]. The 464 DNS client additionally uses [RFC6125] validation techniques to 465 compare the domain name to the certificate provided. 467 A DNS client constructs two Reference Identifiers for the server 468 based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- 469 ID is simply the domain name itself. The SRV-ID uses a "_domain-s." 470 prefix. So if the configured domain name is "dns.example.com", then 471 the two Reference Identifiers are: 473 DNS-ID: dns.example.com 475 SRV-ID: _domain-s.dns.example.com 477 If either of the Reference Identifiers are found in the X.509 478 certificate's subjectAltName extension as described in section 6 of 479 [RFC6125], the DNS client should accept the certificate for the 480 server. 482 A compliant DNS client MUST only inspect the certificate's 483 subjectAltName extension for these Reference Identifiers. In 484 particular, it MUST NOT inspect the Subject field itself. 486 9.2. DANE 488 DANE [RFC6698] provides mechanisms to root certificate and raw public 489 keys trust with DNSSEC. However this requires a domain name which 490 must be obtained via a trusted source. 492 It is noted that [RFC6698] says 494 "Clients that validate the DNSSEC signatures themselves MUST use 495 standard DNSSEC validation procedures. Clients that rely on 496 another entity to perform the DNSSEC signature validation MUST use 497 a secure mechanism between themselves and the validator." 499 The specific DANE record would take the form: 501 _853._tcp.[server-domain-name] for TLS 503 _853._udp.[server-domain-name] for DTLS 505 9.2.1. Direct DNS Lookup 507 The DNS client MAY choose to perform the DNS lookups to retrieve the 508 required DANE records itself. The DNS queries for such DANE records 509 MAY use opportunistic encryption or be in the clear to avoid trust 510 recursion. The records MUST be validated using DNSSEC as described 511 above in [RFC6698]. 513 9.2.2. TLS DNSSEC Chain extension 515 The DNS client MAY offer the TLS extension described in 516 [I-D.shore-tls-dnssec-chain-extension]. If the DNS server supports 517 this extension, it can provide the full chain to the client in the 518 handshake. 520 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 521 capable of validating the full DNSSEC authentication chain down to 522 the leaf. If the supplied DNSSEC chain does not validate, the client 523 MUST ignore the DNSSEC chain and validate only via other supplied 524 credentials. 526 [ TODO: specify guidance for DANE parameters to be used here. For 527 example, a suggestion to use Certificate Usage of 3 (EE-DANE) 528 (section 2.1.1 of [RFC6698]) and a Selector of 1 (SPKI) (section 529 2.1.2) would completely remove all X.509 and certificate authorities 530 from the verification path and allows for private certification ] 532 [ TODO: discuss combination of DNSSEC Chain Extension with cert 533 validation. Note that the combination depends on the Certificate 534 Usage value of the TLSA response. ] 536 10. Combined Credentials with SPKI Pinsets 538 The SPKI pinset profile described in [I-D.ietf-dprive-dns-over-tls] 539 MAY be used with DNS-over-(D)TLS. 541 This draft does not make explicit recommendations about how a SPKI 542 pinset based authentication mechanism should be combined with a 543 domain based mechanism from an operator perspective. However it can 544 be envisaged that a DNS server operator may wish to make both an SPKI 545 pinset and a domain name available to allow clients to choose which 546 mechanism to use. Therefore, the following is guidance on how 547 clients ought to behave if they choose to configure both, as is 548 possible in HPKP [RFC7469]. 550 A DNS client that is configured with both a domain name and a SPKI 551 pinset for a DNS sever SHOULD match on both a valid credential for 552 the domain name and a valid SPKI pinset when connecting to that DNS 553 server. 555 11. (D)TLS Protocol Profile 557 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 559 There are known attacks on (D)TLS, such as machine-in-the-middle and 560 protocol downgrade. These are general attacks on (D)TLS and not 561 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 562 discussion of these security issues. Clients and servers MUST adhere 563 to the (D)TLS implementation recommendations and security 564 considerations of [RFC7525] except with respect to (D)TLS version. 565 Since encryption of DNS using (D)TLS is virtually a green-field 566 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 567 later. 569 Implementations MUST NOT offer or provide TLS compression, since 570 compression can leak significant amounts of information, especially 571 to a network observer capable of forcing the user to do an arbitrary 572 DNS lookup in the style of the CRIME attacks [CRIME]. 574 Implementations compliant with this profile MUST implement all of the 575 following items: 577 o TLS session resumption without server-side state [RFC5077] which 578 eliminates the need for the server to retain cryptographic state 579 for longer than necessary. 581 o Raw public keys [RFC7250] which reduce the size of the 582 ServerHello, and can be used by servers that cannot obtain 583 certificates (e.g., DNS servers on private networks). 585 Implementations compliant with this profile SHOULD implement all of 586 the following items: 588 o TLS False Start [I-D.ietf-tls-falsestart] which reduces round- 589 trips by allowing the TLS second flight of messages 590 (ChangeCipherSpec) to also contain the (encrypted) DNS query 592 o Cached Information Extension [I-D.ietf-tls-cached-info] which 593 avoids transmitting the server's certificate and certificate chain 594 if the client has cached that information from a previous TLS 595 handshake 597 [NOTE: The references to (works in progress) should be upgraded to 598 MUST's if those references become RFC's prior to publication of this 599 document.] 601 Guidance specific to TLS or DTLS is provided in either 602 [I-D.ietf-dprive-dnsodtls] or [I-D.ietf-dprive-dns-over-tls]. 604 12. IANA Considerations 606 This memo includes no request to IANA. 608 13. Security Considerations 610 Security considerations discussed in [RFC7525], 611 [I-D.ietf-dprive-dnsodtls] and [I-D.ietf-dprive-dns-over-tls] apply 612 to this document. 614 13.1. Counter-measures to DNS Traffic Analysis 616 This section makes suggestions for measures that can reduce the 617 ability of attackers to infer information pertaining to encrypted 618 client queries by other means (e.g. via an analysis of encrypted 619 traffic size, or via monitoring of resolver to authoritative 620 traffic). 622 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 623 following relevant DNS extensions 625 o EDNS(0) padding [I-D.ietf-dprive-edns0-padding], which allows 626 encrypted queries and responses to hide their size. 628 DNS-over-(D)TLS clients SHOULD consider implementing the following 629 relevant DNS extensions 631 o Privacy Election using Client Subnet in DNS Queries 632 [I-D.ietf-dnsop-edns-client-subnet]. If a DNS client does not 633 include an EDNS0 Client Subnet Option with a SOURCE PREFIX-LENGTH 634 set to 0 in a query, the DNS server may potentially leak client 635 address information to the upstream authoritative DNS servers. A 636 DNS client ought to be able to inform the DNS Resolver that it 637 does not want any address information leaked, and the DNS Resolver 638 should honor that request. 640 14. Acknowledgements 642 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 643 [I-D.ietf-dprive-dns-over-tls] for laying the ground work that this 644 draft builds on and for reviewing the contents. The authors would 645 also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri 646 Visweswaran, Ray Bellis, Stephane Bortzmeyer and Jinmei Tatuya for 647 review and discussion of the ideas presented here. 649 15. References 651 15.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 659 Subject Alternative Name for Expression of Service Name", 660 RFC 4985, DOI 10.17487/RFC4985, August 2007, 661 . 663 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 664 "Transport Layer Security (TLS) Session Resumption without 665 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 666 January 2008, . 668 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 669 (TLS) Protocol Version 1.2", RFC 5246, 670 DOI 10.17487/RFC5246, August 2008, 671 . 673 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 674 Housley, R., and W. Polk, "Internet X.509 Public Key 675 Infrastructure Certificate and Certificate Revocation List 676 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 677 . 679 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 680 Verification of Domain-Based Application Service Identity 681 within Internet Public Key Infrastructure Using X.509 682 (PKIX) Certificates in the Context of Transport Layer 683 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 684 2011, . 686 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 687 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 688 January 2012, . 690 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 691 of Named Entities (DANE) Transport Layer Security (TLS) 692 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 693 2012, . 695 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 696 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 697 Transport Layer Security (TLS) and Datagram Transport 698 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 699 June 2014, . 701 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 702 "Recommendations for Secure Use of Transport Layer 703 Security (TLS) and Datagram Transport Layer Security 704 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 705 2015, . 707 15.2. Informative References 709 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 711 [dnssec-trigger] 712 NLnetLabs, "Dnssec-Trigger", May 2014, 713 . 715 [I-D.ietf-dnsop-edns-client-subnet] 716 Contavalli, C., Gaast, W., tale, t., and W. Kumari, 717 "Client Subnet in DNS Queries", draft-ietf-dnsop-edns- 718 client-subnet-06 (work in progress), December 2015. 720 [I-D.ietf-dprive-dns-over-tls] 721 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 722 and P. Hoffman, "Specification for DNS over TLS", draft- 723 ietf-dprive-dns-over-tls-09 (work in progress), March 724 2016. 726 [I-D.ietf-dprive-dnsodtls] 727 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 728 (DNSoD)", draft-ietf-dprive-dnsodtls-05 (work in 729 progress), March 2016. 731 [I-D.ietf-dprive-edns0-padding] 732 Mayrhofer, A., "The EDNS(0) Padding Option", draft-ietf- 733 dprive-edns0-padding-03 (work in progress), March 2016. 735 [I-D.ietf-tls-cached-info] 736 Santesson, S. and H. Tschofenig, "Transport Layer Security 737 (TLS) Cached Information Extension", draft-ietf-tls- 738 cached-info-22 (work in progress), January 2016. 740 [I-D.ietf-tls-falsestart] 741 Langley, A., Modadugu, N., and B. Moeller, "Transport 742 Layer Security (TLS) False Start", draft-ietf-tls- 743 falsestart-01 (work in progress), November 2015. 745 [I-D.shore-tls-dnssec-chain-extension] 746 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 747 Record and DNSSEC Authentication Chain Extension for TLS", 748 draft-shore-tls-dnssec-chain-extension-02 (work in 749 progress), October 2015. 751 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 752 RFC 2131, DOI 10.17487/RFC2131, March 1997, 753 . 755 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 756 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 757 . 759 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 760 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 761 DOI 10.17487/RFC3646, December 2003, 762 . 764 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 765 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 766 December 2014, . 768 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 769 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 770 2015, . 772 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 773 DOI 10.17487/RFC7626, August 2015, 774 . 776 Appendix A. Server capability probing and caching by DNS clients 778 This section presents a non-normative discussion of how DNS clients 779 might probe for and cache privacy capabilities of DNS servers. 781 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 782 Not all servers will support one or both of these protocols and the 783 well-known port might be blocked by some middleboxes. Clients will 784 be expected to keep track of servers that support DNS-over-TLS and/or 785 DNS-over-DTLS, and those that have been previously authenticated. 787 If no server capability information is available then (unless 788 otherwise specified by the configuration of the DNS client) DNS 789 clients that implement both TLS and DTLS should try to authenticate 790 using both protocols before failing or falling back to a lower 791 security. DNS clients using opportunistic security should try all 792 available servers (possibly in parallel) in order to obtain an 793 authenticated encrypted connection before falling back to a lower 794 security. (RATIONALE: This approach can increase latency while 795 discovering server capabilities but maximizes the chance of sending 796 the query over an authenticated encrypted connection.) 798 Appendix B. Changes between revisions 800 [Note to RFC Editor: please remove this section prior to 801 publication.] 803 B.1. -01 version 805 Section 4.2: Make clear that the Strict Privacy Profile can include 806 meta queries performed using Opportunistic Privacy. 808 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 809 does not guarantee protection against passive attack. 811 Section 4.2: Add sentence discussing client/provider trusted 812 relationships. 814 Section 5: Add more discussion of detection of active attacks when 815 using Opportunistic Privacy. 817 Section 8.2: Clarify description and example. 819 B.2. draft-ietf-dprive-dtls-and-tls-profiles-00 821 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 822 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 823 fixed. 825 Authors' Addresses 827 Sara Dickinson 828 Sinodun Internet Technologies 829 Magdalen Centre 830 Oxford Science Park 831 Oxford OX4 4GA 832 UK 834 Email: sara@sinodun.com 835 URI: http://sinodun.com 837 Daniel Kahn Gillmor 838 ACLU 839 125 Broad Street, 18th Floor 840 New York NY 10004 841 USA 843 Email: dkg@fifthhorseman.net 845 Tirumaleswar Reddy 846 Cisco Systems, Inc. 847 Cessna Business Park, Varthur Hobli 848 Sarjapur Marathalli Outer Ring Road 849 Bangalore, Karnataka 560103 850 India 852 Email: tireddy@cisco.com