idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-00.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 (January 30, 2016) is 3007 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 (-09) exists of draft-ietf-dprive-dns-over-tls-05 == Outdated reference: A later version (-15) exists of draft-ietf-dprive-dnsodtls-04 == Outdated reference: A later version (-03) exists of draft-ietf-dprive-edns0-padding-02 == 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 (~~), 7 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: August 2, 2016 ACLU 6 T. Reddy 7 Cisco 8 January 30, 2016 10 Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS 11 draft-ietf-dprive-dtls-and-tls-profiles-00 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 August 2, 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 . . . . . . . 7 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 . . . . . . . . . . . . . . . . 8 70 8.2. Direct configuration of name only . . . . . . . . . . . . 8 71 8.3. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Credential Verification . . . . . . . . . . . . . . . . . . . 9 73 9.1. X.509 Certificate Based Authentication . . . . . . . . . 9 74 9.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 10 76 9.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 11 77 10. Combined Credentials with SPKI Pinsets . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . 13 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 16 87 Appendix B. Changes between revisions . . . . . . . . . . . . . 17 88 B.1. draft-ietf-dprive-dtls-and-tls-profiles . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 91 1. Introduction 93 The DPRIVE working group has two active documents that provide DNS 94 privacy between DNS clients and DNS servers (to address the concerns 95 in [RFC7626]): 97 o DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] 99 o DNS-over-DTLS [I-D.ietf-dprive-dnsodtls] 101 This document defines usage profiles and authentication mechanisms 102 for DTLS [RFC6347] and TLS [RFC5246] that specify how a DNS client 103 should authenticate a DNS server based on a domain name. In 104 particular, it describes: 106 o How a DNS client can obtain a domain name for a DNS server to use 107 for (D)TLS authentication. 109 o What are the acceptable credentials a DNS server can present to 110 prove its identity for (D)TLS authentication based on a given 111 domain name. 113 o How a DNS client can verify that any given credential matches the 114 domain name obtained for a DNS server. 116 This document also defines a (D)TLS protocol profile for use with 117 DNS. This profile defines the configuration options and protocol 118 extensions required of both parties to optimize connection 119 establishment and session resumption for transporting DNS, and to 120 support the authentication profiles defined here. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 Several terms are used specifically in the context of this draft: 130 o DNS client: a DNS stub resolver or forwarder/proxy. In the case 131 of a forwarder, the term "DNS client" is used to discuss the side 132 that sends queries. 134 o DNS server: a DNS recursive resolver or forwarder/proxy. In the 135 case of a forwarder, the term "DNS server" is used to discuss the 136 side that responds to queries. 138 o Privacy-enabling DNS server: A DNS server that: 140 * MUST implement DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] and 141 MAY implement DNS-over-DTLS [I-D.ietf-dprive-dnsodtls]. 143 * Can offer at least one of the credentials described in 144 Section 9. 146 * Implements the (D)TLS profile described in Section 11. 148 o (D)TLS: For brevity this term is used for statements that apply to 149 both Transport Layer Security [RFC5246] and Datagram Transport 150 Layer Security [RFC6347]. Specific terms will be used for any 151 statement that applies to either protocol alone. 153 o DNS-over-(D)TLS: For brevity this term is used for statements that 154 apply to both DNS-over-TLS [I-D.ietf-dprive-dns-over-tls] and DNS- 155 over-DTLS [I-D.ietf-dprive-dnsodtls]. Specific terms will be used 156 for any statement that applies to either protocol alone. 158 o Credential: Information available for a DNS server which proves 159 its identity for authentication purposes. Credentials discussed 160 here include: 162 * X.509 certificate 164 * DNSSEC validated chain to a TLSA record 166 but may also include SPKI pinsets. 168 o SPKI Pinsets: [I-D.ietf-dprive-dns-over-tls] describes the use of 169 cryptographic digests to "pin" public key information in a manner 170 similar to HPKP [RFC7469]. An SPKI pinset is a collection of 171 these pins that constrains a DNS server. 173 o Reference Identifier: a Reference Identifier as described in 174 [RFC6125], constructed by the DNS client when performing TLS 175 authentication of a DNS server. 177 3. Scope 179 This document is limited to domain-name-based authentication of DNS 180 servers by DNS clients (as defined in the terminology section), and 181 the (D)TLS profiles needed to support this. As such, the following 182 things are out of scope: 184 o Authentication of authoritative servers by recursive resolvers. 186 o Authentication of DNS clients by DNS servers. 188 o SPKI-pinset-based authentication. This is defined in 189 [I-D.ietf-dprive-dns-over-tls]. However, Section 10 does describe 190 how to combine that approach with the domain name based mechanism 191 described here. 193 o Any server identifier other than domain names, including IP 194 address, organizational name, country of origin, etc. 196 4. Discussion 198 4.1. Background 200 To protect against passive attacks DNS privacy requires encrypting 201 the query (and response). Such encryption typically provides 202 integrity protection as a side-effect, which means on-path attackers 203 cannot simply inject bogus DNS responses. For DNS privacy to also 204 provide protection against active attackers pretending to be the 205 server, the client must authenticate the server. 207 4.2. Usage Profiles 209 A DNS client has a choice of privacy usage profiles available. This 210 choice is briefly discussed in both [I-D.ietf-dprive-dns-over-tls] 211 and [I-D.ietf-dprive-dnsodtls]. In summary, the usage profiles are: 213 o Strict Privacy: the DNS client requires both an encrypted and 214 authenticated connection to a DNS Server. A hard failure occurs 215 if this is not available. This requires the client to securely 216 obtain information it can use to authenticate the server. This 217 provides strong privacy guarantees to the client. This is 218 discussed in detail in Section 6. 220 o Opportunistic Privacy: the DNS client uses Opportunistic Security 221 as described in [RFC7435] 223 "... the use of cleartext as the baseline communication 224 security policy, with encryption and authentication negotiated 225 and applied to the communication when available." 227 In the best case scenario (authenticated and encrypted connection) 228 this is equivalent to Strict Privacy, in the worst case (clear 229 text connection) this is equivalent to No Privacy. Clients will 230 try for the best case but are willing to fallback to intermediate 231 cases and eventually the worst case scenario in order to obtain a 232 response. This provides an undetermined privacy guarantee to the 233 user depending on what kind of connection is actually used. This 234 is discussed in Section 5 236 o No Privacy: the DNS client does not require or attempt to use 237 either encryption or authentication. Queries are always sent in 238 clear text. This provides no privacy guarantees to the client. 240 +-----------------------+------------------+-----------------+ 241 | Usage Profile | Passive Attacker | Active Attacker | 242 +-----------------------+------------------+-----------------+ 243 | No Privacy | N | N | 244 | Opportunistic Privacy | P | N (D) | 245 | Strict Privacy | P | P | 246 +-----------------------+------------------+-----------------+ 248 P == protection; N == no protection; D == detection is possible 250 Table 1: DNS Privacy Protection by Usage Profile and type of attacker 252 Since Strict Privacy provides the strongest privacy guarantees it is 253 preferable to Opportunistic Privacy which is preferable to No 254 Privacy. However since the different profiles require varying levels 255 of configuration (or a trusted relationship with a provider) DNS 256 clients will need to carefully select which profile to use based on 257 their communication privacy needs. 259 A DNS client SHOULD select a particular usage profile when resolving 260 a query. A DNS client MUST NOT fallback from Strict Privacy to 261 Opportunistic Privacy during the resolution process as this could 262 invalidate the protection offered against active attackers. 264 4.3. Authentication 266 This document describes authentication mechanisms that can be used in 267 either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 269 4.3.1. DNS-over-(D)TLS Bootstrapping Problems 271 Many (D)TLS clients use PKIX authentication [RFC6125] based on a 272 domain name for the server they are contacting. These clients 273 typically first look up the server's network address in the DNS 274 before making this connection. A DNS client therefore has a 275 bootstrap problem. DNS clients typically know only the IP address of 276 a DNS server. 278 As such, before connecting to a DNS server, a DNS client needs to 279 learn the domain name it should associate with the IP address of a 280 DNS server for authentication purposes. Sources of domains names are 281 discussed in Section 7 and Section 8. 283 One advantage of this domain name based approach is that it 284 encourages association of stable, human recognisable identifiers with 285 secure DNS service providers. 287 4.3.2. Credential Verification 289 The use of SPKI pinset verification is discussed in 290 [I-D.ietf-dprive-dns-over-tls]. 292 In terms of domain name based verification, once a domain name is 293 known for a DNS server a choice of mechanisms can be used for 294 authentication. Section 9 discusses these mechanisms in detail, 295 namely X.509 certificate based authentication and DANE. 297 Note that the use of DANE adds requirements on the ability of the 298 client to get validated DNSSEC results. This is discussed in more 299 detail in Section 9.2. 301 4.3.3. Implementation guidance 303 Section 11 describes the (D)TLS profile for DNS-over(D)TLS. 304 Additional considerations relating to general implementation 305 guidelines are discussed in both Section 13 and in Appendix A. 307 5. Authentication in Opportunistic DNS-over(D)TLS Privacy 309 An Opportunistic Security [RFC7435] profile is described in 310 [I-D.ietf-dprive-dns-over-tls] which MAY be used for DNS-over-(D)TLS. 312 DNS clients issuing queries under an opportunistic profile which know 313 of a domain name for a DNS server MAY choose to try to authenticate 314 the server using the mechanisms described here. This is useful for 315 detecting (but not preventing) active attack, and for debugging or 316 diagnostic purposes if there are means to report the result of the 317 authentication attempt. This information can provide a basis for a 318 DNS client to switch to (preferred) Strict Privacy where it is 319 viable. 321 6. Authentication in Strict DNS-over(D)TLS Privacy 323 To authenticate a privacy-enabling DNS server, a DNS client needs to 324 know the domain name for each server it is willing to contact. This 325 is necessary to protect against active attacks on DNS privacy. 327 A DNS client requiring Strict Privacy MUST either use one of the 328 sources listed in Section 8 to obtain a domain name for the server it 329 contacts, or use an SPKI pinset as described in 330 [I-D.ietf-dprive-dns-over-tls]. 332 A DNS client requiring Strict Privacy MUST only attempt to connect to 333 DNS servers for which either a domain name or a SPKI pinset is known 334 (or both). The client MUST use the available verification mechanisms 335 described in Section 9 to authenticate the server, and MUST abort 336 connections to a server when no verification mechanism succeeds. 338 With Strict Privacy, the DNS client MUST NOT commence sending DNS 339 queries until at least one of the privacy-enabling DNS servers 340 becomes available. 342 A privacy-enabling DNS server may be temporarily unavailable when 343 configuring a network. For example, for clients on networks that 344 require registration through web-based login (a.k.a. "captive 345 portals"), such registration may rely on DNS interception and 346 spoofing. Techniques such as those used by DNSSEC-trigger 347 [dnssec-trigger] MAY be used during network configuration, with the 348 intent to transition to the designated privacy-enabling DNS servers 349 after captive portal registration. The system MUST alert by some 350 means that the DNS is not private during such bootstrap. 352 7. In Band Source of Domain Name: SRV Service Label 354 This specification adds a SRV service label "domain-s" for privacy- 355 enabling DNS servers. 357 Example service records (for TLS and DTLS respectively): 359 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns1.example.com. 360 _domain-s._tcp.dns.example.com. SRV 0 1 853 dns2.example.com. 362 _domain-s._udp.dns.example.com. SRV 0 1 853 dns3.example.com. 364 8. Out of Band Sources of Domain Name 366 8.1. Full direct configuration 368 DNS clients may be directly and securely provisioned with the domain 369 name of each privacy-enabling DNS server. For example, using a 370 client specific configuration file or API. 372 In this case, direct configuration for a DNS client would consist of 373 both an IP address and a domain name for each DNS server. 375 8.2. Direct configuration of name only 377 A DNS client may be configured directly and securely with only the 378 domain name of its privacy-enabling DNS server. For example, using a 379 client specific configuration file or API. 381 It can then use opportunistic DNS connections to untrusted DNS 382 servers (e.g. provided by the local DHCP service) to establish the IP 383 address of the intended privacy-enabling DNS server by doing a lookup 384 of SRV records. Such records MUST be validated using DNSSEC. 386 Example: For a DNSSEC validating DNS client configured in this way to 387 do strict DNS privacy to dns.example.net, it would opportunistically 388 look up the SRV for _domain-s._tcp.dns.example.net and determine 389 addresses (via opportunistic A and/or AAAA lookups) for the resulting 390 SRV response(s). The records obtained during this process would only 391 be used if they were validated by the client using DNSSEC. 393 A DNS client so configured that successfully connects to a privacy- 394 enabling DNS server MAY choose to locally cache the looked up 395 addresses in order to not have to repeat the opportunistic lookup. 397 8.3. DHCP 399 Some clients may have an established trust relationship with a known 400 DHCP [RFC2131] server for discovering their network configuration. 401 In the typical case, such a DHCP server provides a list of IP 402 addresses for DNS servers (see section 3.8 of [RFC2132]), but does 403 not provide a domain name for the DNS server itself. 405 A DHCP server might use a DHCP extension to provide a list of domain 406 names for the offered DNS servers, which correspond to IP addresses 407 listed. 409 Note that this requires the client to trust the DHCP server, and to 410 have a secured/authenticated connection to it. Therefore this 411 mechanism may be limited to only certain environments. This document 412 does not attempt to describe secured and trusted relationships to 413 DHCP servers. 415 [NOTE: It is noted (at the time of writing) that whilst some 416 implementation work is in progress to secure IPv6 connections for 417 DHCP, IPv4 connections have received little to no implementation 418 attention in this area.] 420 [QUESTION: The authors would like to solicit feedback on the use of 421 DHCP to determine whether to pursue a new DHCP option in a later 422 version of this draft, or defer it.] 424 9. Credential Verification 426 9.1. X.509 Certificate Based Authentication 428 When a DNS client configured with a domain name connects to its 429 configured DNS server over (D)TLS, the server may present it with an 430 X.509 certificate. In order to ensure proper authentication, DNS 431 clients MUST verify the entire certification path per [RFC5280]. The 432 DNS client additionally uses [RFC6125] validation techniques to 433 compare the domain name to the certificate provided. 435 A DNS client constructs two Reference Identifiers for the server 436 based on the domain name: A DNS-ID and an SRV-ID [RFC4985]. The DNS- 437 ID is simply the domain name itself. The SRV-ID uses a "_domain-s." 438 prefix. So if the configured domain name is "dns.example.com", then 439 the two Reference Identifiers are: 441 DNS-ID: dns.example.com 443 SRV-ID: _domain-s.dns.example.com 445 If either of the Reference Identifiers are found in the X.509 446 certificate's subjectAltName extension as described in section 6 of 447 [RFC6125], the DNS client should accept the certificate for the 448 server. 450 A compliant DNS client MUST only inspect the certificate's 451 subjectAltName extension for these Reference Identifiers. In 452 particular, it MUST NOT inspect the Subject field itself. 454 9.2. DANE 456 DANE [RFC6698] provides mechanisms to root certificate and raw public 457 keys trust with DNSSEC. However this requires a domain name which 458 must be obtained via a trusted source. 460 It is noted that [RFC6698] says 462 "Clients that validate the DNSSEC signatures themselves MUST use 463 standard DNSSEC validation procedures. Clients that rely on 464 another entity to perform the DNSSEC signature validation MUST use 465 a secure mechanism between themselves and the validator." 467 The specific DANE record would take the form: 469 _853._tcp.[server-domain-name] for TLS 471 _853._udp.[server-domain-name] for DTLS 473 9.2.1. Direct DNS Lookup 475 The DNS client MAY choose to perform the DNS lookups to retrieve the 476 required DANE records itself. The DNS queries for such DANE records 477 MAY use opportunistic encryption or be in the clear to avoid trust 478 recursion. The records MUST be validated using DNSSEC as described 479 above in [RFC6698]. 481 9.2.2. TLS DNSSEC Chain extension 483 The DNS client MAY offer the TLS extension described in 484 [I-D.shore-tls-dnssec-chain-extension]. If the DNS server supports 485 this extension, it can provide the full chain to the client in the 486 handshake. 488 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 489 capable of validating the full DNSSEC authentication chain down to 490 the leaf. If the supplied DNSSEC chain does not validate, the client 491 MUST ignore the DNSSEC chain and validate only via other supplied 492 credentials. 494 [ TODO: specify guidance for DANE parameters to be used here. For 495 example, a suggestion to use Certificate Usage of 3 (EE-DANE) 496 (section 2.1.1 of [RFC6698]) and a Selector of 1 (SPKI) (section 497 2.1.2) would completely remove all X.509 and certificate authorities 498 from the verification path and allows for private certification ] 500 [ TODO: discuss combination of DNSSEC Chain Extension with cert 501 validation. Note that the combination depends on the Certificate 502 Usage value of the TLSA response. ] 504 10. Combined Credentials with SPKI Pinsets 506 The SPKI pinset profile described in [I-D.ietf-dprive-dns-over-tls] 507 MAY be used with DNS-over-(D)TLS. 509 This draft does not make explicit recommendations about how a SPKI 510 pinset based authentication mechanism should be combined with a 511 domain based mechanism from an operator perspective. However it can 512 be envisaged that a DNS server operator may wish to make both an SPKI 513 pinset and a domain name available to allow clients to choose which 514 mechanism to use. Therefore, the following is guidance on how 515 clients ought to behave if they choose to configure both, as is 516 possible in HPKP [RFC7469]. 518 A DNS client that is configured with both a domain name and a SPKI 519 pinset for a DNS sever SHOULD match on both a valid credential for 520 the domain name and a valid SPKI pinset when connecting to that DNS 521 server. 523 11. (D)TLS Protocol Profile 525 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 527 There are known attacks on (D)TLS, such as machine-in-the-middle and 528 protocol downgrade. These are general attacks on (D)TLS and not 529 specific to DNS-over-TLS; please refer to the (D)TLS RFCs for 530 discussion of these security issues. Clients and servers MUST adhere 531 to the (D)TLS implementation recommendations and security 532 considerations of [RFC7525] except with respect to (D)TLS version. 533 Since encryption of DNS using (D)TLS is virtually a green-field 534 deployment DNS clients and server MUST implement only (D)TLS 1.2 or 535 later. 537 Implementations MUST NOT offer or provide TLS compression, since 538 compression can leak significant amounts of information, especially 539 to a network observer capable of forcing the user to do an arbitrary 540 DNS lookup in the style of the CRIME attacks [CRIME]. 542 Implementations compliant with this profile MUST implement all of the 543 following items: 545 o TLS session resumption without server-side state [RFC5077] which 546 eliminates the need for the server to retain cryptographic state 547 for longer than necessary. 549 o Raw public keys [RFC7250] which reduce the size of the 550 ServerHello, and can be used by servers that cannot obtain 551 certificates (e.g., DNS servers on private networks). 553 Implementations compliant with this profile SHOULD implement all of 554 the following items: 556 o TLS False Start [I-D.ietf-tls-falsestart] which reduces round- 557 trips by allowing the TLS second flight of messages 558 (ChangeCipherSpec) to also contain the (encrypted) DNS query 560 o Cached Information Extension [I-D.ietf-tls-cached-info] which 561 avoids transmitting the server's certificate and certificate chain 562 if the client has cached that information from a previous TLS 563 handshake 565 [NOTE: The references to (works in progress) should be upgraded to 566 MUST's if those references become RFC's prior to publication of this 567 document.] 569 Guidance specific to TLS or DTLS is provided in either 570 [I-D.ietf-dprive-dnsodtls] or [I-D.ietf-dprive-dns-over-tls]. 572 12. IANA Considerations 574 This memo includes no request to IANA. 576 13. Security Considerations 578 Security considerations discussed in [RFC7525], 579 [I-D.ietf-dprive-dnsodtls] and [I-D.ietf-dprive-dns-over-tls] apply 580 to this document. 582 13.1. Counter-measures to DNS Traffic Analysis 584 This section makes suggestions for measures that can reduce the 585 ability of attackers to infer information pertaining to encrypted 586 client queries by other means (e.g. via an analysis of encrypted 587 traffic size, or via monitoring of resolver to authoritative 588 traffic). 590 DNS-over-(D)TLS clients and servers SHOULD consider implementing the 591 following relevant DNS extensions 593 o EDNS(0) padding [I-D.ietf-dprive-edns0-padding], which allows 594 encrypted queries and responses to hide their size. 596 DNS-over-(D)TLS clients SHOULD consider implementing the following 597 relevant DNS extensions 599 o Privacy Election using Client Subnet in DNS Queries 600 [I-D.ietf-dnsop-edns-client-subnet]. If a DNS client does not 601 include an EDNS0 Client Subnet Option with a SOURCE PREFIX-LENGTH 602 set to 0 in a query, the DNS server may potentially leak client 603 address information to the upstream authoritative DNS servers. A 604 DNS client ought to be able to inform the DNS Resolver that it 605 does not want any address information leaked, and the DNS Resolver 606 should honor that request. 608 14. Acknowledgements 610 Thanks to the authors of both [I-D.ietf-dprive-dnsodtls] and 611 [I-D.ietf-dprive-dns-over-tls] for laying the ground work that this 612 draft builds on and for reviewing the contents. The authors would 613 also like to thank John Dickinson, Shumon Huque, Melinda Shore, Gowri 614 Visweswaran and Ray Bellis for review and discussion of the ideas 615 presented here. 617 15. References 619 15.1. Normative References 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, 623 DOI 10.17487/RFC2119, March 1997, 624 . 626 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 627 Subject Alternative Name for Expression of Service Name", 628 RFC 4985, DOI 10.17487/RFC4985, August 2007, 629 . 631 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 632 "Transport Layer Security (TLS) Session Resumption without 633 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 634 January 2008, . 636 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 637 (TLS) Protocol Version 1.2", RFC 5246, 638 DOI 10.17487/RFC5246, August 2008, 639 . 641 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 642 Housley, R., and W. Polk, "Internet X.509 Public Key 643 Infrastructure Certificate and Certificate Revocation List 644 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 645 . 647 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 648 Verification of Domain-Based Application Service Identity 649 within Internet Public Key Infrastructure Using X.509 650 (PKIX) Certificates in the Context of Transport Layer 651 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 652 2011, . 654 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 655 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 656 January 2012, . 658 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 659 of Named Entities (DANE) Transport Layer Security (TLS) 660 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 661 2012, . 663 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 664 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 665 Transport Layer Security (TLS) and Datagram Transport 666 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 667 June 2014, . 669 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 670 "Recommendations for Secure Use of Transport Layer 671 Security (TLS) and Datagram Transport Layer Security 672 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 673 2015, . 675 15.2. Informative References 677 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 679 [dnssec-trigger] 680 NLnetLabs, "Dnssec-Trigger", May 2014, 681 . 683 [I-D.ietf-dnsop-edns-client-subnet] 684 Contavalli, C., Gaast, W., tale, t., and W. Kumari, 685 "Client Subnet in DNS Queries", draft-ietf-dnsop-edns- 686 client-subnet-06 (work in progress), December 2015. 688 [I-D.ietf-dprive-dns-over-tls] 689 Zi, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 690 and P. Hoffman, "DNS over TLS: Initiation and Performance 691 Considerations", draft-ietf-dprive-dns-over-tls-05 (work 692 in progress), January 2016. 694 [I-D.ietf-dprive-dnsodtls] 695 Reddy, T., Wing, D., and P. Patil, "DNS over DTLS 696 (DNSoD)", draft-ietf-dprive-dnsodtls-04 (work in 697 progress), January 2016. 699 [I-D.ietf-dprive-edns0-padding] 700 Mayrhofer, A., "The EDNS(0) Padding Option", draft-ietf- 701 dprive-edns0-padding-02 (work in progress), January 2016. 703 [I-D.ietf-tls-cached-info] 704 Santesson, S. and H. Tschofenig, "Transport Layer Security 705 (TLS) Cached Information Extension", draft-ietf-tls- 706 cached-info-22 (work in progress), January 2016. 708 [I-D.ietf-tls-falsestart] 709 Langley, A., Modadugu, N., and B. Moeller, "Transport 710 Layer Security (TLS) False Start", draft-ietf-tls- 711 falsestart-01 (work in progress), November 2015. 713 [I-D.shore-tls-dnssec-chain-extension] 714 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 715 Record and DNSSEC Authentication Chain Extension for TLS", 716 draft-shore-tls-dnssec-chain-extension-02 (work in 717 progress), October 2015. 719 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 720 RFC 2131, DOI 10.17487/RFC2131, March 1997, 721 . 723 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 724 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 725 . 727 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 728 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 729 December 2014, . 731 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 732 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 733 2015, . 735 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 736 DOI 10.17487/RFC7626, August 2015, 737 . 739 Appendix A. Server capability probing and caching by DNS clients 741 This section presents a non-normative discussion of how DNS clients 742 might probe for and cache privacy capabilities of DNS servers. 744 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 745 Not all servers will support one or both of these protocols and the 746 well-known port might be blocked by some middleboxes. Clients will 747 be expected to keep track of servers that support DNS-over-TLS and/or 748 DNS-over-DTLS, and those that have been previously authenticated. 750 If no server capability information is available then (unless 751 otherwise specified by the configuration of the DNS client) DNS 752 clients that implement both TLS and DTLS should try to authenticate 753 using both protocols before failing or falling back to a lower 754 security. DNS clients using opportunistic security should try all 755 available servers (possibly in parallel) in order to obtain an 756 authenticated encrypted connection before falling back to a lower 757 security. (RATIONALE: This approach can increase latency while 758 discovering server capabilities but maximizes the chance of sending 759 the query over an authenticated encrypted connection.) 761 Appendix B. Changes between revisions 763 [Note to RFC Editor: please remove this section prior to 764 publication.] 766 B.1. draft-ietf-dprive-dtls-and-tls-profiles 768 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 769 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 770 fixed. 772 Authors' Addresses 774 Sara Dickinson 775 Sinodun Internet Technologies 776 Magdalen Centre 777 Oxford Science Park 778 Oxford OX4 4GA 779 UK 781 Email: sara@sinodun.com 782 URI: http://sinodun.com 784 Daniel Kahn Gillmor 785 ACLU 786 125 Broad Street, 18th Floor 787 New York NY 10004 788 USA 790 Email: dkg@fifthhorseman.net 792 Tirumaleswar Reddy 793 Cisco Systems, Inc. 794 Cessna Business Park, Varthur Hobli 795 Sarjapur Marathalli Outer Ring Road 796 Bangalore, Karnataka 560103 797 India 799 Email: tireddy@cisco.com