idnits 2.17.1 draft-ietf-dprive-dtls-and-tls-profiles-11.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 (September 11, 2017) is 2418 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) ** Downref: Normative reference to an Informational RFC: RFC 7918 ** Downref: Normative reference to an Experimental RFC: RFC 8094 == Outdated reference: A later version (-06) exists of draft-ietf-dprive-padding-policy-01 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-04 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive S. Dickinson 3 Internet-Draft Sinodun 4 Updates: 7858 (if approved) D. Gillmor 5 Intended status: Standards Track ACLU 6 Expires: March 15, 2018 T. Reddy 7 McAfee 8 September 11, 2017 10 Usage and (D)TLS Profiles for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-11 13 Abstract 15 This document discusses Usage Profiles, based on one or more 16 authentication mechanisms, which can be used for DNS over Transport 17 Layer Security (TLS) or Datagram TLS (DTLS). These profiles can 18 increase the privacy of DNS transactions compared to using only clear 19 text DNS. This document also specifies new authentication mechanisms 20 - it describes several ways a DNS client can use an authentication 21 domain name to authenticate a (D)TLS connection to a DNS server. 22 Additionally, it defines (D)TLS protocol profiles for DNS clients and 23 servers implementing DNS-over-(D)TLS. This document updates RFC 24 7858. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on March 15, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Usage Profiles . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. DNS Resolution . . . . . . . . . . . . . . . . . . . . . 10 66 6. Authentication in DNS-over(D)TLS . . . . . . . . . . . . . . 10 67 6.1. DNS-over-(D)TLS Startup Configuration Problems . . . . . 10 68 6.2. Credential Verification . . . . . . . . . . . . . . . . . 11 69 6.3. Summary of Authentication Mechanisms . . . . . . . . . . 11 70 6.4. Combining Authentication Mechanisms . . . . . . . . . . . 14 71 6.5. Authentication in Opportunistic Privacy . . . . . . . . . 14 72 6.6. Authentication in Strict Privacy . . . . . . . . . . . . 15 73 6.7. Implementation guidance . . . . . . . . . . . . . . . . . 15 74 7. Sources of Authentication Domain Names . . . . . . . . . . . 15 75 7.1. Full direct configuration . . . . . . . . . . . . . . . . 15 76 7.2. Direct configuration of ADN only . . . . . . . . . . . . 16 77 7.3. Dynamic discovery of ADN . . . . . . . . . . . . . . . . 16 78 7.3.1. DHCP . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Authentication Domain Name based Credential Verification . . 17 80 8.1. PKIX Certificate Based Authentication . . . . . . . . . . 17 81 8.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8.2.1. Direct DNS Lookup . . . . . . . . . . . . . . . . . . 18 83 8.2.2. TLS DNSSEC Chain extension . . . . . . . . . . . . . 18 84 9. (D)TLS Protocol Profile . . . . . . . . . . . . . . . . . . . 19 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 11.1. Counter-measures to DNS Traffic Analysis . . . . . . . . 20 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 13.2. Informative References . . . . . . . . . . . . . . . . . 23 92 Appendix A. Server capability probing and caching by DNS clients 24 93 Appendix B. Changes between revisions . . . . . . . . . . . . . 24 94 B.1. -11 version . . . . . . . . . . . . . . . . . . . . . . . 25 95 B.2. -10 version . . . . . . . . . . . . . . . . . . . . . . . 25 96 B.3. -09 version . . . . . . . . . . . . . . . . . . . . . . . 26 97 B.4. -08 version . . . . . . . . . . . . . . . . . . . . . . . 26 98 B.5. -07 version . . . . . . . . . . . . . . . . . . . . . . . 26 99 B.6. -06 version . . . . . . . . . . . . . . . . . . . . . . . 26 100 B.7. -05 version . . . . . . . . . . . . . . . . . . . . . . . 27 101 B.8. -04 version . . . . . . . . . . . . . . . . . . . . . . . 27 102 B.9. -03 version . . . . . . . . . . . . . . . . . . . . . . . 27 103 B.10. -02 version . . . . . . . . . . . . . . . . . . . . . . . 27 104 B.11. -01 version . . . . . . . . . . . . . . . . . . . . . . . 28 105 B.12. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 108 1. Introduction 110 DNS Privacy issues are discussed in [RFC7626]. The specific issues 111 described there that are most relevant to this document are 113 o Passive attacks which eavesdrop on clear text DNS transactions on 114 the wire (Section 2.4) and 116 o Active attacks which redirect clients to rogue servers to monitor 117 DNS traffic (Section 2.5.3). 119 Mitigating against these attacks increases the privacy of DNS 120 transactions, however many of the other issues raised in [RFC7626] 121 still apply. 123 Two documents that provide ways to increase DNS privacy between DNS 124 clients and DNS servers are: 126 o Specification for DNS over Transport Layer Security (TLS) 127 [RFC7858], referred to here as simply 'DNS-over-TLS' 129 o DNS over Datagram Transport Layer Security (DTLS) [RFC8094], 130 referred to here simply as 'DNS-over-DTLS'. Note that this 131 document has the Category of Experimental. 133 Both documents are limited in scope to communications between stub 134 clients and recursive resolvers and the same scope is applied to this 135 document (see Section 2 and Section 3). The proposals here might be 136 adapted or extended in future to be used for recursive clients and 137 authoritative servers, but this application was out of scope for the 138 Working Group charter at the time this document was finished. 140 This document specifies two Usage Profiles (Strict and Opportunistic) 141 for DTLS [RFC6347] and TLS [RFC5246] which provide improved levels of 142 mitigation against the attacks described above compared to using only 143 clear text DNS. 145 Section 5 presents a generalized discussion of Usage Profiles by 146 separating the Usage Profile, which is based purely on the security 147 properties it offers the user, from the specific mechanism(s) that 148 are used for DNS server authentication. The Profiles described are: 150 o A Strict Profile that requires an encrypted connection and 151 successful authentication of the DNS server which mitigates both 152 passive eavesdropping and client re-direction (at the expense of 153 providing no DNS service if this is not available). 155 o An Opportunistic Profile that will attempt, but does not require, 156 encryption and successful authentication; it therefore provides 157 limited or no mitigation against such attacks but offers maximum 158 chance of DNS service. 160 The above Usage Profiles attempt authentication of the server using 161 at least one authentication mechanism. Section 6.4 discusses how to 162 combine authentication mechanisms to determine the overall 163 authentication result. Depending on that overall authentication 164 result (and whether encryption is available) the Usage Profile will 165 determine if the connection should proceed, fallback or fail. 167 One authentication mechanism is already described in [RFC7858]. That 168 document specifies a Subject Public Key Info (SPKI) based 169 authentication mechanism for DNS-over-TLS in the context of a 170 specific case of a Strict Usage Profile using that single 171 authentication mechanism. Therefore the "Out-of-band Key-pinned 172 Privacy Profile" described in [RFC7858] would qualify as a "Strict 173 Usage Profile" that used SPKI pinning for authentication. 175 This document extends the use of SPKI pinset based authentication so 176 that it is considered a general authentication mechanism that can be 177 used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI 178 pinset mechanism described in [RFC7858] MAY be used with DNS- 179 over-(D)TLS. 181 This document also describes a number of additional authentication 182 mechanisms all of which specify how a DNS client should authenticate 183 a DNS server based on an 'authentication domain name'. In 184 particular, the following is described: 186 o How a DNS client can obtain the combination of an authentication 187 domain name and IP address for a DNS server. See Section 7. 189 o What are the acceptable credentials a DNS server can present to 190 prove its identity for (D)TLS authentication based on a given 191 authentication domain name. See Section 8. 193 o How a DNS client can verify that any given credential matches the 194 authentication domain name obtained for a DNS server. See 195 Section 8. 197 In Section 9 this document defines a (D)TLS protocol profile for use 198 with DNS. This profile defines the configuration options and 199 protocol extensions required of both parties to optimize connection 200 establishment and session resumption for transporting DNS, and to 201 support all currently specified authentication mechanisms. 203 2. Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [RFC2119]. 209 Several terms are used specifically in the context of this draft: 211 o DNS client: a DNS stub resolver or forwarder. In the case of a 212 forwarder, the term "DNS client" is used to discuss the side that 213 sends queries. 215 o DNS server: a DNS recursive resolver or forwarder. In the case of 216 a forwarder, the term "DNS server" is used to discuss the side 217 that responds to queries. For emphasis, in this document the term 218 does not apply to authoritative servers. 220 o Privacy-enabling DNS server: A DNS server that implements DNS- 221 over-TLS [RFC7858] and may optionally implement DNS-over-DTLS 222 [RFC8094]. The server should also offer at least one of the 223 credentials described in Section 8 and implement the (D)TLS 224 profile described in Section 9. 226 o (D)TLS: For brevity this term is used for statements that apply to 227 both Transport Layer Security [RFC5246] and Datagram Transport 228 Layer Security [RFC6347]. Specific terms will be used for any 229 statement that applies to either protocol alone. 231 o DNS-over-(D)TLS: For brevity this term is used for statements that 232 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS [RFC8094]. 233 Specific terms will be used for any statement that applies to 234 either protocol alone. 236 o Authentication domain name: A domain name that can be used to 237 authenticate a privacy-enabling DNS server. Sources of 238 authentication domain names are discussed in Section 7. 240 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 241 to "pin" public key information in a manner similar to HTTP Public 242 Key Pinning [RFC7469] (HPKP). An SPKI pinset is a collection of 243 these pins that constrains a DNS server. 245 o Authentication information: Information a DNS client may use as 246 the basis of an authentication mechanism. In this context that 247 can be either a: 249 * a SPKI pinset or 251 * an authentication domain name 253 o Reference Identifier: a Reference Identifier as described in 254 [RFC6125], constructed by the DNS client when performing TLS 255 authentication of a DNS server. 257 o Credential: Information available for a DNS server which proves 258 its identity for authentication purposes. Credentials discussed 259 here include: 261 * PKIX certificate 263 * DNSSEC validated chain to a TLSA record 265 but may also include SPKI pinsets. 267 3. Scope 269 This document is limited to describing 271 o Usage Profiles based on general authentication mechanisms 273 o The details of domain name based authentication of DNS servers by 274 DNS clients (as defined in the terminology section) 276 o The (D)TLS profiles needed to support authentication in DNS- 277 over-(D)TLS. 279 As such, the following things are out of scope: 281 o Authentication of authoritative servers by recursive resolvers. 283 o Authentication of DNS clients by DNS servers. 285 o The details of how to perform SPKI-pinset-based authentication. 286 This is defined in [RFC7858]. 288 o Any server identifier other than domain names, including IP 289 addresses, organizational names, country of origin, etc. 291 4. Discussion 293 One way to mitigate against passive attackers eavesdropping on clear 294 text DNS transactions is to encrypt the query (and response). Such 295 encryption typically provides integrity protection as a side-effect, 296 which means on-path attackers cannot simply inject bogus DNS 297 responses. To also mitigate against active attackers pretending to 298 be the server, the client must authenticate the (D)TLS connection to 299 the server. 301 This document discusses Usage Profiles, which provide differing 302 levels of attack mitigation to DNS clients, based on the requirements 303 for authentication and encryption, regardless of the context (for 304 example, which network the client is connected to). A Usage Profile 305 is a distinct concept to a usage policy or usage model, which might 306 dictate which Profile should be used in a particular context 307 (enterprise vs coffee shop), with a particular set of DNS Servers or 308 with reference to other external factors. A description of the 309 variety of usage policies is out of scope of this document, but may 310 be the subject of future work. 312 The term 'privacy-enabling DNS server' is used throughout this 313 document. This is a DNS server that: 315 o MUST implement DNS-over-TLS [RFC7858]. 317 o MAY implement DNS-over-DTLS [RFC8094]. 319 o SHOULD offer at least one of the credentials described in 320 Section 8. 322 o Implements the (D)TLS profile described in Section 9. 324 5. Usage Profiles 326 A DNS client has a choice of Usage Profiles available to increase the 327 privacy of DNS transactions. This choice is briefly discussed in 328 both [RFC7858] and [RFC8094]. These Usage Profiles are: 330 o Strict profile: the DNS client requires both an encrypted and 331 authenticated connection to a privacy-enabling DNS Server. A hard 332 failure occurs if this is not available. This requires the client 333 to securely obtain authentication information it can use to 334 authenticate the server. This profile mitigates against both 335 passive and active attacks providing the client with the best 336 available privacy for DNS. This Profile is discussed in detail in 337 Section 6.6. 339 o Opportunistic Privacy: the DNS client uses Opportunistic Security 340 as described in [RFC7435] 342 "... the use of cleartext as the baseline communication 343 security policy, with encryption and authentication negotiated 344 and applied to the communication when available." 346 As described in [RFC7435] it might result in 348 * an encrypted and authenticated connection 350 * an encrypted connection 352 * a clear text connection 354 depending on the fallback logic of the client, the available 355 authentication information and the capabilities of the DNS Server. 356 In all these cases the DNS client is willing to continue with a 357 connection to the DNS Server and perform resolution of queries. 358 The use of Opportunistic Privacy is intended to support 359 incremental deployment of increased privacy with a view to 360 widespread adoption of the Strict profile. It should be employed 361 when the DNS client might otherwise settle for cleartext; it 362 provides the maximum protection available depending on the 363 combination of factors described above. If all the configured DNS 364 Servers are DNS Privacy servers then it provides protection 365 against passive attacks but not active ones. 367 Both profiles can include an initial meta query (performed using an 368 Opportunistic lookup) to obtain the IP address for the privacy- 369 enabling DNS server to which the DNS client will subsequently 370 connect. The rationale for permitting this for the Strict profile is 371 that requiring such meta queries to also be performed using the 372 Strict profile would introduce significant deployment obstacles. 373 However, it should be noted that in this scenario an active attack is 374 possible on the meta query. Such an attack could result in a Strict 375 profile client connecting to a server it cannot authenticate and so 376 not obtaining DNS service, or an Opportunistic Privacy client 377 connecting to a server controlled by the attacker. DNSSEC validation 378 can detect the attack on the meta query and results in the client not 379 obtaining DNS service (for both Usage profiles) because it will not 380 proceed to connect to the server in question (see Section 7.2) 382 To compare the two Usage profiles the table below shows a successful 383 Strict profile along side the 3 possible outcomes of an Opportunistic 384 profile. In the best case scenario for the Opportunistic profile (an 385 authenticated and encrypted connection) it is equivalent to the 386 Strict profile. In the worst case scenario it is equivalent to clear 387 text. Clients using the Opportunistic profile SHOULD try for the 388 best case but MAY fallback to the intermediate case and eventually 389 the worst case scenario in order to obtain a response. One reason to 390 fallback without trying every available privacy-enabling DNS server 391 is if latency is more important than attack mitigation, see 392 Appendix A. The Opportunistic profile therefore provides varying 393 protection depending on what kind of connection is actually used 394 including no attack mitigation at all. 396 Note that there is no requirement in Opportunistic Security to notify 397 the user what type of connection is actually used, the 'detection' 398 described below is only possible if such connection information is 399 available. However, if it is available and the user is informed that 400 an unencrypted connection was used to connect to a server then the 401 user should assume (detect) that the connection is subject to both 402 active and passive attack since the DNS queries are sent in clear 403 text. This might be particularly useful if a new connection to a 404 certain server is unencrypted when all previous connections were 405 encrypted. Similarly if the user is informed that an encrypted but 406 unauthenticated connection was used then the user can detect that the 407 connection may be subject to active attack. In other words for the 408 cases where no protection is provided against an attacker (N) it is 409 possible to detect that an attack might be happening (D). This is 410 discussed in Section 6.5. 412 +---------------+------------+------------------+-----------------+ 413 | Usage Profile | Connection | Passive Attacker | Active Attacker | 414 +---------------+------------+------------------+-----------------+ 415 | Strict | A, E | P | P | 416 | Opportunistic | A, E | P | P | 417 | Opportunistic | E | P | N, D | 418 | Opportunistic | | N, D | N, D | 419 +---------------+------------+------------------+-----------------+ 421 P == Protection; N == No protection; D == Detection is possible; A == 422 Authenticated connection; E == Encrypted connection 424 Table 1: Attack protection by Usage Profile and type of attacker 426 The Strict profile provides the best attack mitigation and therefore 427 SHOULD always be implemented in DNS clients that implement 428 Opportunistic Privacy. 430 A DNS client that implements DNS-over-(D)TLS SHOULD NOT be configured 431 by default to use only clear text. 433 The choice between the two profiles depends on a number of factors 434 including which is more important to the particular client: 436 o DNS service at the cost of no attack mitigation (Opportunistic) or 438 o best available attack mitigation at the potential cost of no DNS 439 service (Strict). 441 Additionally the two profiles require varying levels of configuration 442 (or a trusted relationship with a provider) and DNS server 443 capabilities, therefore DNS clients will need to carefully select 444 which profile to use based on their communication needs. 446 A DNS server that implements DNS-over-(D)TLS SHOULD provide at least 447 one credential so that those DNS clients that wish to do so are able 448 to use the Strict profile (see Section 2). 450 5.1. DNS Resolution 452 A DNS client SHOULD select a particular Usage Profile when resolving 453 a query. A DNS client MUST NOT fallback from Strict Privacy to 454 Opportunistic Privacy during the resolution of a given query as this 455 could invalidate the protection offered against attackers. It is 456 anticipated that DNS clients will use a particular Usage Profile for 457 all queries to all configured servers until an operational issue or 458 policy update dictates a change in the profile used. 460 6. Authentication in DNS-over(D)TLS 462 This section describes authentication mechanisms and how they can be 463 used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 465 6.1. DNS-over-(D)TLS Startup Configuration Problems 467 Many (D)TLS clients use PKIX authentication [RFC6125] based on an 468 authentication domain name for the server they are contacting. These 469 clients typically first look up the server's network address in the 470 DNS before making this connection. Such a DNS client therefore has a 471 bootstrap problem, as it will typically only know the IP address of 472 its DNS server. 474 In this case, before connecting to a DNS server, a DNS client needs 475 to learn the authentication domain name it should associate with the 476 IP address of a DNS server for authentication purposes. Sources of 477 authentication domain names are discussed in Section 7. 479 One advantage of this domain name based approach is that it 480 encourages association of stable, human recognizable identifiers with 481 secure DNS service providers. 483 6.2. Credential Verification 485 The use of SPKI pinset verification is discussed in [RFC7858]. 487 In terms of domain name based verification, once an authentication 488 domain name is known for a DNS server a choice of authentication 489 mechanisms can be used for credential verification. Section 8 490 discusses these mechanisms in detail, namely PKIX certificate based 491 authentication and DANE. 493 Note that the use of DANE adds requirements on the ability of the 494 client to get validated DNSSEC results. This is discussed in more 495 detail in Section 8.2. 497 6.3. Summary of Authentication Mechanisms 499 This section provides an overview of the various authentication 500 mechanisms. The table below indicates how the DNS client obtains 501 information to use for authentication for each option; either 502 statically via direct configuration or dynamically. Of course, the 503 Opportunistic Usage Profile does not require authentication and so a 504 client using that profile may choose to connect to a privacy-enabling 505 DNS server on the basis of just an IP address. 507 +---+------------+-------------+------------------------------------+ 508 | # | Static | Dynamically | Short name: Description | 509 | | Config | Obtained | | 510 +---+------------+-------------+------------------------------------+ 511 | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | 512 | | | | address obtained out of band | 513 | | | | [RFC7858] | 514 | | | | | 515 | 2 | ADN + IP | | ADN: ADN and IP address obtained | 516 | | | | out of band (see Section 7.1) | 517 | | | | | 518 | 3 | ADN | IP | ADN only: Opportunistic lookups to | 519 | | | | a NP DNS server for A/AAAA (see | 520 | | | | Section 7.2) | 521 | | | | | 522 | 4 | | ADN + IP | DHCP: DHCP configuration only (see | 523 | | | | Section 7.3.1) | 524 | | | | | 525 | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | 526 | | | TLSA record | Opportunistic lookups to NP DNS | 527 | | | | server (see Section 8.2.1) | 528 | | | | | 529 | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | 530 | | | TLSA record | provided by PE DNS server in TLS | 531 | | | | DNSSEC chain extension (see | 532 | | | | Section 8.2.2) | 533 +---+------------+-------------+------------------------------------+ 535 SPKI == SPKI pinset(s), IP == IP Address, ADN == Authentication 536 Domain Name, NP == Network provided, PE == Privacy-enabling, [ ] == 537 Data may be obtained either statically or dynamically 539 Table 2: Overview of Authentication Mechanisms 541 The following summary attempts to present some key attributes of each 542 of the mechanisms (using the 'Short name' from Table 2), indicating 543 attractive attributes with a '+' and undesirable attributes with a 544 '-'. 546 1. SPKI 548 + Minimal leakage (Note that the ADN is always leaked in the 549 Server Name Indication (SNI) field in the Client Hello in TLS 550 when communicating with a privacy-enabling DNS server) 552 - Overhead of on-going key management required 554 2. ADN 555 + Minimal leakage 557 + One-off direct configuration only 559 3. ADN only 561 + Minimal one-off direct configuration, only a human 562 recognizable domain name needed 564 - A/AAAA meta queries leaked to network provided DNS server 565 that may be subject to active attack (attack can be mitigated 566 by DNSSEC validation). 568 4. DHCP 570 + No static config 572 - Requires a non-standard or future DHCP option in order to 573 provide the ADN 575 - Requires secure and trustworthy connection to DHCP server if 576 used with a Strict Usage profile 578 5. DANE 580 The ADN and/or IP may be obtained statically or dynamically 581 and the relevant attributes of that method apply 583 + DANE options (e.g., matching on entire certificate) 585 - Requires a DNSSEC validating stub implementation (deployment 586 of which is limited at the time of writing) 588 - DNSSEC chain meta queries leaked to network provided DNS 589 server that may be subject to active attack 591 6. TLS extension 593 The ADN and/or IP may be obtained statically or dynamically 594 and the relevant attributes of that method apply 596 + Reduced latency compared with 'DANE' 598 + No network provided DNS server required if ADN and IP 599 statically configured 601 + DANE options (e.g., matching on entire certificate) 602 - Requires a DNSSEC validating stub implementation 604 6.4. Combining Authentication Mechanisms 606 This draft does not make explicit recommendations about how an SPKI 607 pinset based authentication mechanism should be combined with a 608 domain based mechanism from an operator perspective. However it can 609 be envisaged that a DNS server operator may wish to make both an SPKI 610 pinset and an authentication domain name available to allow clients 611 to choose which mechanism to use. Therefore, the following is 612 guidance on how clients ought to behave if they choose to configure 613 both, as is possible in HPKP [RFC7469]. 615 A DNS client that is configured with both an authentication domain 616 name and a SPKI pinset for a DNS server SHOULD match on both a valid 617 credential for the authentication domain name and a valid SPKI pinset 618 (if both are available) when connecting to that DNS server. In this 619 case the client SHOULD treat the SPKI pin as specified in Section 2.6 620 of [RFC7469] with regard to user defined trust anchors. The overall 621 authentication result SHOULD only be considered successful if both 622 authentication mechanisms are successful. 624 6.5. Authentication in Opportunistic Privacy 626 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 627 which MAY be used for DNS-over-(D)TLS. 629 DNS clients issuing queries under an opportunistic profile and which 630 know authentication information for a given privacy-enabling DNS 631 server SHOULD try to authenticate the server using the mechanisms 632 described here. This is useful for detecting (but not preventing) 633 active attack, since the fact that authentication information is 634 available indicates that the server in question is a privacy-enabling 635 DNS server to which it should be possible to establish an 636 authenticated and encrypted connection. In this case, whilst a 637 client cannot know the reason for an authentication failure, from a 638 security standpoint the client should consider an active attack in 639 progress and proceed under that assumption. For example, a client 640 that implements a nameserver selection algorithm that preferentially 641 uses nameservers which successfully authenticated (see Section 5) 642 might not continue to use the failing server if there were 643 alternative servers available. 645 Attempting authentication is also useful for debugging or diagnostic 646 purposes if there are means to report the result. This information 647 can provide a basis for a DNS client to switch to (preferred) Strict 648 Privacy where it is viable e.g, where all the configured servers 649 support DNS-over-(D)TLS and successfully authenticate. 651 6.6. Authentication in Strict Privacy 653 To authenticate a privacy-enabling DNS server, a DNS client needs to 654 know authentication information for each server it is willing to 655 contact. This is necessary to protect against active attacks which 656 attempt to re-direct clients to rogue DNS servers. 658 A DNS client requiring Strict Privacy MUST either use one of the 659 sources listed in Section 7 to obtain an authentication domain name 660 for the server it contacts, or use an SPKI pinset as described in 661 [RFC7858]. 663 A DNS client requiring Strict Privacy MUST only attempt to connect to 664 DNS servers for which at least one piece of authentication 665 information is known. The client MUST use the available verification 666 mechanisms described in Section 8 to authenticate the server, and 667 MUST abort connections to a server when no verification mechanism 668 succeeds. 670 With Strict Privacy, the DNS client MUST NOT commence sending DNS 671 queries until at least one of the privacy-enabling DNS servers 672 becomes available. 674 A privacy-enabling DNS server may be temporarily unavailable when 675 configuring a network. For example, for clients on networks that 676 require registration through web-based login (a.k.a. "captive 677 portals"), such registration may rely on DNS interception and 678 spoofing. Techniques such as those used by DNSSEC-trigger 679 [dnssec-trigger] MAY be used during network configuration, with the 680 intent to transition to the designated privacy-enabling DNS servers 681 after captive portal registration. If using a Strict Usage profile 682 the system MUST alert by some means that the DNS is not private 683 during such bootstrap. 685 6.7. Implementation guidance 687 Section 9 describes the (D)TLS profile for DNS-over(D)TLS. 688 Additional considerations relating to general implementation 689 guidelines are discussed in both Section 11 and in Appendix A. 691 7. Sources of Authentication Domain Names 693 7.1. Full direct configuration 695 DNS clients may be directly and securely provisioned with the 696 authentication domain name of each privacy-enabling DNS server. For 697 example, using a client specific configuration file or API. 699 In this case, direct configuration for a DNS client would consist of 700 both an IP address and an authentication domain name for each DNS 701 server. 703 7.2. Direct configuration of ADN only 705 A DNS client may be configured directly and securely with only the 706 authentication domain name of each of its privacy-enabling DNS 707 servers. For example, using a client specific configuration file or 708 API. 710 A DNS client might learn of a default recursive DNS resolver from an 711 untrusted source (such as DHCP's DNS server option [RFC3646]). It 712 can then use Opportunistic DNS connections to an untrusted recursive 713 DNS resolver to establish the IP address of the intended privacy- 714 enabling DNS resolver by doing a lookup of A/AAAA records. Such 715 records SHOULD be DNSSEC validated when using a Strict Usage profile 716 and MUST be validated when using Opportunistic Privacy. Private DNS 717 resolution can now be done by the DNS client against the pre- 718 configured privacy-enabling DNS resolver, using the IP address 719 gathered from the untrusted DNS resolver. 721 A DNS client so configured that successfully connects to a privacy- 722 enabling DNS server MAY choose to locally cache the server host IP 723 addresses in order to not have to repeat the opportunistic lookup. 725 7.3. Dynamic discovery of ADN 727 This section discusses the general case of a DNS client discovering 728 both the authentication domain name and IP address dynamically. This 729 is not possible at the time of writing by any standard means. 730 However since, for example, a future DHCP extension could (in 731 principle) provide this mechanism the required security properties of 732 such mechanisms are outlined here. 734 When using a Strict profile the dynamic discovery technique used as a 735 source of authentication domain names MUST be considered secure and 736 trustworthy. This requirement does not apply when using an 737 Opportunistic profile given the security expectation of that profile. 739 7.3.1. DHCP 741 In the typical case today, a DHCP server [RFC2131] [RFC3315] provides 742 a list of IP addresses for DNS resolvers (see Section 3.8 of 743 [RFC2132]), but does not provide an authentication domain name for 744 the DNS resolver, thus preventing the use of most of the 745 authentication methods described here (all those that are based on a 746 mechanism with ADN in Table 2). 748 This document does not specify or request any DHCP extension to 749 provide authentication domain names. However, if one is developed in 750 future work the issues outlined in Section 8 of [RFC7227] should be 751 taken into account as should the Security Considerations in 752 Section 23 of [RFC3315]). 754 This document does not attempt to describe secured and trusted 755 relationships to DHCP servers, which is a purely DHCP issue (still 756 open, at the time of writing.) Whilst some implementation work is in 757 progress to secure IPv6 connections for DHCP, IPv4 connections have 758 received little to no implementation attention in this area. 760 8. Authentication Domain Name based Credential Verification 762 8.1. PKIX Certificate Based Authentication 764 When a DNS client configured with an authentication domain name 765 connects to its configured DNS server over (D)TLS, the server may 766 present it with a PKIX certificate. In order to ensure proper 767 authentication, DNS clients MUST verify the entire certification path 768 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 769 techniques to compare the domain name to the certificate provided. 771 A DNS client constructs one Reference Identifier for the server based 772 on the authentication domain name: A DNS-ID which is simply the 773 authentication domain name itself. 775 If the Reference Identifier is found in the PKIX certificate's 776 subjectAltName extension as described in section 6 of [RFC6125], the 777 DNS client should accept the certificate for the server. 779 A compliant DNS client MUST only inspect the certificate's 780 subjectAltName extension for the Reference Identifier. In 781 particular, it MUST NOT inspect the Subject field itself. 783 8.2. DANE 785 DANE [RFC6698] provides mechanisms to anchor certificate and raw 786 public key trust with DNSSEC. However this requires the DNS client 787 to have an authentication domain name for the DNS Privacy Server 788 which must be obtained via a trusted source. 790 This section assumes a solid understanding of both DANE [RFC6698] and 791 DANE Operations [RFC7671]. A few pertinent issues covered in these 792 documents are outlined here as useful pointers, but familiarity with 793 both these documents in their entirety is expected. 795 It is noted that [RFC6698] says 796 "Clients that validate the DNSSEC signatures themselves MUST use 797 standard DNSSEC validation procedures. Clients that rely on 798 another entity to perform the DNSSEC signature validation MUST use 799 a secure mechanism between themselves and the validator." 801 It is noted that [RFC7671] covers the following topics: 803 o Section 4.1: Opportunistic Security and PKIX Usages and 804 Section 14: Security Considerations, which both discuss the use of 805 Trust Anchor and End Entity based schemes (PKIX-TA(0) and PKIX- 806 EE(1) respectively) for Opportunistic Security. 808 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 809 Specifically Section 5.1 which outlines the combination of 810 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 811 Public Keys [RFC7250]. Section 5.1 also discusses the security 812 implications of this mode, for example, it discusses key lifetimes 813 and specifies that validity period enforcement is based solely on 814 the TLSA RRset properties for this case. 816 o Section 13: Operational Considerations, which discusses TLSA TTLs 817 and signature validity periods. 819 The specific DANE record for a DNS Privacy Server would take the 820 form: 822 _853._tcp.[authentication-domain-name] for TLS 824 _853._udp.[authentication-domain-name] for DTLS 826 8.2.1. Direct DNS Lookup 828 The DNS client MAY choose to perform the DNS lookups to retrieve the 829 required DANE records itself. The DNS queries for such DANE records 830 MAY use Opportunistic encryption or be in the clear to avoid trust 831 recursion. The records MUST be validated using DNSSEC as described 832 above in [RFC6698]. 834 8.2.2. TLS DNSSEC Chain extension 836 The DNS client MAY offer the TLS extension described in 837 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 838 this extension, it can provide the full chain to the client in the 839 handshake. 841 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 842 capable of validating the full DNSSEC authentication chain down to 843 the leaf. If the supplied DNSSEC chain does not validate, the client 844 MUST ignore the DNSSEC chain and validate only via other supplied 845 credentials. 847 9. (D)TLS Protocol Profile 849 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 851 Clients and servers MUST adhere to the (D)TLS implementation 852 recommendations and security considerations of [RFC7525] except with 853 respect to (D)TLS version. 855 Since encryption of DNS using (D)TLS is a green-field deployment DNS 856 clients and servers MUST implement only (D)TLS 1.2 or later. For 857 example, implementing TLS 1.3 [I-D.ietf-tls-tls13] is also an option. 859 Implementations MUST NOT offer or provide TLS compression, since 860 compression can leak significant amounts of information, especially 861 to a network observer capable of forcing the user to do an arbitrary 862 DNS lookup in the style of the CRIME attacks [CRIME]. 864 Implementations compliant with this profile MUST implement all of the 865 following items: 867 o TLS session resumption without server-side state [RFC5077] which 868 eliminates the need for the server to retain cryptographic state 869 for longer than necessary (This statement updates [RFC7858]). 871 o Raw public keys [RFC7250] which reduce the size of the 872 ServerHello, and can be used by servers that cannot obtain 873 certificates (e.g., DNS servers on private networks). A client 874 MUST only indicate support for raw public keys if it has an SPKI 875 pinset pre-configured (for interoperability reasons). 877 Implementations compliant with this profile SHOULD implement all of 878 the following items: 880 o TLS False Start [RFC7918] which reduces round-trips by allowing 881 the TLS second flight of messages (ChangeCipherSpec) to also 882 contain the (encrypted) DNS query. 884 o Cached Information Extension [RFC7924] which avoids transmitting 885 the server's certificate and certificate chain if the client has 886 cached that information from a previous TLS handshake. 888 Guidance specific to TLS is provided in [RFC7858] and that specific 889 to DTLS it is provided in [RFC8094]. 891 10. IANA Considerations 893 This memo includes no request to IANA. 895 11. Security Considerations 897 Security considerations discussed in [RFC7525], [RFC8094] and 898 [RFC7858] apply to this document. 900 DNS Clients SHOULD implement support for the mechanisms described in 901 Section 8.2 and offering a configuration option which limits 902 authentication to using only those mechanisms (i.e., with no fallback 903 to pure PKIX based authentication) such that authenticating solely 904 via the PKIX infrastructure can be avoided. 906 11.1. Counter-measures to DNS Traffic Analysis 908 This section makes suggestions for measures that can reduce the 909 ability of attackers to infer information pertaining to encrypted 910 client queries by other means (e.g., via an analysis of encrypted 911 traffic size, or via monitoring of resolver to authoritative 912 traffic). 914 DNS-over-(D)TLS clients and servers SHOULD implement the following 915 relevant DNS extensions 917 o EDNS(0) padding [RFC7830], which allows encrypted queries and 918 responses to hide their size making analysis of encrypted traffic 919 harder. 921 Guidance on padding policies for EDNS(0) is provided in 922 [I-D.ietf-dprive-padding-policy] 924 DNS-over-(D)TLS clients SHOULD implement the following relevant DNS 925 extensions 927 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 928 a DNS client does not include an EDNS0 Client Subnet Option with a 929 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 930 potentially leak client address information to the upstream 931 authoritative DNS servers. A DNS client ought to be able to 932 inform the DNS Resolver that it does not want any address 933 information leaked, and the DNS Resolver should honor that 934 request. 936 12. Acknowledgments 938 Thanks to the authors of both [RFC8094] and [RFC7858] for laying the 939 ground work that this draft builds on and for reviewing the contents. 940 The authors would also like to thank John Dickinson, Shumon Huque, 941 Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, 942 Jinmei Tatuya, Paul Hoffman, Christian Huitema and John Levine for 943 review and discussion of the ideas presented here. 945 13. References 947 13.1. Normative References 949 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 950 Requirement Levels", BCP 14, RFC 2119, 951 DOI 10.17487/RFC2119, March 1997, . 954 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 955 "Transport Layer Security (TLS) Session Resumption without 956 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 957 January 2008, . 959 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 960 (TLS) Protocol Version 1.2", RFC 5246, 961 DOI 10.17487/RFC5246, August 2008, . 964 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 965 Housley, R., and W. Polk, "Internet X.509 Public Key 966 Infrastructure Certificate and Certificate Revocation List 967 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 968 . 970 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 971 Verification of Domain-Based Application Service Identity 972 within Internet Public Key Infrastructure Using X.509 973 (PKIX) Certificates in the Context of Transport Layer 974 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 975 2011, . 977 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 978 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 979 January 2012, . 981 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 982 of Named Entities (DANE) Transport Layer Security (TLS) 983 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 984 2012, . 986 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 987 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 988 Transport Layer Security (TLS) and Datagram Transport 989 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 990 June 2014, . 992 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 993 "Recommendations for Secure Use of Transport Layer 994 Security (TLS) and Datagram Transport Layer Security 995 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 996 2015, . 998 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 999 Authentication of Named Entities (DANE) Protocol: Updates 1000 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 1001 October 2015, . 1003 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 1004 DOI 10.17487/RFC7830, May 2016, . 1007 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1008 and P. Hoffman, "Specification for DNS over Transport 1009 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1010 2016, . 1012 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1013 Layer Security (TLS) False Start", RFC 7918, 1014 DOI 10.17487/RFC7918, August 2016, . 1017 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1018 (TLS) Cached Information Extension", RFC 7924, 1019 DOI 10.17487/RFC7924, July 2016, . 1022 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1023 Transport Layer Security (DTLS)", RFC 8094, 1024 DOI 10.17487/RFC8094, February 2017, . 1027 13.2. Informative References 1029 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 1031 [dnssec-trigger] 1032 NLnetLabs, "Dnssec-Trigger", May 2014, 1033 . 1035 [I-D.ietf-dprive-padding-policy] 1036 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 1037 dprive-padding-policy-01 (work in progress), July 2017. 1039 [I-D.ietf-tls-dnssec-chain-extension] 1040 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 1041 Record and DNSSEC Authentication Chain Extension for TLS", 1042 draft-ietf-tls-dnssec-chain-extension-04 (work in 1043 progress), June 2017. 1045 [I-D.ietf-tls-tls13] 1046 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1047 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1048 July 2017. 1050 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1051 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1052 . 1054 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1055 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1056 . 1058 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1059 C., and M. Carney, "Dynamic Host Configuration Protocol 1060 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1061 2003, . 1063 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1064 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1065 DOI 10.17487/RFC3646, December 2003, . 1068 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1069 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1070 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1071 . 1073 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1074 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1075 December 2014, . 1077 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1078 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1079 2015, . 1081 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1082 DOI 10.17487/RFC7626, August 2015, . 1085 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1086 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1087 DOI 10.17487/RFC7871, May 2016, . 1090 Appendix A. Server capability probing and caching by DNS clients 1092 This section presents a non-normative discussion of how DNS clients 1093 might probe for and cache capabilities of privacy-enabling DNS 1094 servers. 1096 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 1097 Not all servers will support one or both of these protocols and the 1098 well-known port might be blocked by some middleboxes. Clients will 1099 be expected to keep track of servers that support DNS-over-TLS and/or 1100 DNS-over-DTLS, and those that have been previously authenticated. 1102 If no server capability information is available then (unless 1103 otherwise specified by the configuration of the DNS client) DNS 1104 clients that implement both TLS and DTLS should try to authenticate 1105 using both protocols before failing or falling back to a 1106 unauthenticated or clear text connections. DNS clients using an 1107 Opportunistic Usage profile should try all available servers 1108 (possibly in parallel) in order to obtain an authenticated and 1109 encrypted connection before falling back. (RATIONALE: This approach 1110 can increase latency while discovering server capabilities but 1111 maximizes the chance of sending the query over an authenticated and 1112 encrypted connection.) 1114 Appendix B. Changes between revisions 1116 [Note to RFC Editor: please remove this section prior to 1117 publication.] 1119 B.1. -11 version 1121 Section 5: Re-ordered and re-worded the text in section on 1122 Opportunistic profile to make the protection offered by Opportunistic 1123 clearer. 1125 Section 5: Provide a more detailed analysis of attacks on the meta 1126 queries 1128 Section 7.2: Re-introduce a requirement to DNSSEC validate the meta- 1129 queries making it as SHOULD for Strict and a MUST for Opportunistic. 1131 B.2. -10 version 1133 Clarified the specific attacks the Usage profiles mitigate against. 1135 Revised wording in the draft relating 'security/privacy guarantees' 1136 and generally improved consistency of wording throughout the 1137 document. 1139 Corrected and added a number of references: 1141 o RFC7924 is now Normative 1143 o RFC7918 and RFC8094 are now Normative (and therefore Downrefs) 1145 o draft-ietf-tls-tls13, draft-ietf-dprive-padding-policy, RFC3315 1146 and RFC7227 added 1148 Terminology: Update definition of Privacy-enabling DNS server and 1149 moved normative definition to section 4. 1151 Section 5 and 6.3: Included discussion of the additional attacks 1152 possible when using meta-queries to bootstrap the DNS service 1154 Section 5: Added sentence on why Opportunistic Profile may fallback 1155 for latency reasons. 1157 Section 5.1: Added discussion of when clients might change Usage 1158 Profiles. 1160 Section 6.4: Added caveat on use of combined authentication re 1161 RFC7469. 1163 Section 6.5: Added more detail on how authentication results might be 1164 used in Opportunistic. Opportunistic clients now SHOULD try for the 1165 best case. 1167 Section 7.3: Re-worked this section and the discussion of DHCP. 1169 Section 9: Removed unnecessary text, added condition on use of 1170 RFC7250 (Raw public keys). 1172 Section 11.: More detail on padding policies. 1174 Numerous editorial corrections. 1176 B.3. -09 version 1178 Remove the SRV record to simplify the draft. 1180 Add suggestion that clients offer option to avoid using only PKIX 1181 authentication. 1183 Clarify that the MUST on implementing TLS session resumption updates 1184 RFC7858. 1186 Update page header to be '(D)TLS Authentication for TLS'. 1188 B.4. -08 version 1190 Removed hard failure as an option for Opportunistic Usage profile. 1192 Added a new section comparing the Authentication Mechanisms 1194 B.5. -07 version 1196 Re-work of the Abstract and Introduction to better describe the 1197 contents in this version. 1199 Terminology: New definition of 'authentication information'. 1201 Scope: Changes to the Scope section. 1203 Moved discussion of combining authentication mechanism earlier. 1205 Changes to the section headings and groupings to make the 1206 presentation more logical. 1208 B.6. -06 version 1210 Introduction: Re-word discussion of Working group charter. 1212 Introduction: Re-word first and third bullet point about 'obtaining' 1213 a domain name and IP address. 1215 Introduction: Update reference to DNS-over-TLS draft. 1217 Terminology: Change forwarder/proxy to just forwarder 1219 Terminology: Add definition of 'Authentication domain name' and use 1220 this throughout 1222 Section 4.2: Remove parenthesis in the table. 1224 Section 4.2: Change the text after the table as agreed with Paul 1225 Hoffman. 1227 Section 4.3.1: Change title and remove brackets around last 1228 statement. 1230 Section 11: Split second paragraph. 1232 B.7. -05 version 1234 Add more details on detecting passive attacks to section 4.2 1236 Changed X.509 to PKIX throughout 1238 Change comment about future I-D on usage policies. 1240 B.8. -04 version 1242 Introduction: Add comment that DNS-over-DTLS draft is Experiments 1244 Update 2 I-D references to RFCs. 1246 B.9. -03 version 1248 Section 9: Update DANE section with better references to RFC7671 and 1249 RFC7250 1251 B.10. -02 version 1253 Introduction: Added paragraph on the background and scope of the 1254 document. 1256 Introduction and Discussion: Added more information on what a Usage 1257 profiles is (and is not) the the two presented here. 1259 Introduction: Added paragraph to make a comparison with the Strict 1260 profile in RFC7858 clearer. 1262 Section 4.2: Re-worked the description of Opportunistic and the 1263 table. 1265 Section 8.3: Clarified statement about use of DHCP in Opportunistic 1266 profile 1268 Title abbreviated. 1270 B.11. -01 version 1272 Section 4.2: Make clear that the Strict Privacy Profile can include 1273 meta queries performed using Opportunistic Privacy. 1275 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 1276 does not guarantee protection against passive attack. 1278 Section 4.2: Add sentence discussing client/provider trusted 1279 relationships. 1281 Section 5: Add more discussion of detection of active attacks when 1282 using Opportunistic Privacy. 1284 Section 8.2: Clarify description and example. 1286 B.12. draft-ietf-dprive-dtls-and-tls-profiles-00 1288 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1289 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1290 fixed. 1292 Authors' Addresses 1294 Sara Dickinson 1295 Sinodun Internet Technologies 1296 Magdalen Centre 1297 Oxford Science Park 1298 Oxford OX4 4GA 1299 UK 1301 Email: sara@sinodun.com 1302 URI: http://sinodun.com 1303 Daniel Kahn Gillmor 1304 ACLU 1305 125 Broad Street, 18th Floor 1306 New York NY 10004 1307 USA 1309 Email: dkg@fifthhorseman.net 1311 Tirumaleswar Reddy 1312 McAfee, Inc. 1313 Embassy Golf Link Business Park 1314 Bangalore, Karnataka 560071 1315 India 1317 Email: TirumaleswarReddy_Konda@McAfee.com