idnits 2.17.00 (12 Aug 2021) /tmp/idnits32471/draft-ietf-dprive-dtls-and-tls-profiles-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 16, 2017) is 1800 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 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 7918 ** Downref: Normative reference to an Experimental RFC: RFC 8094 == Outdated reference: draft-ietf-dprive-padding-policy has been published as RFC 8467 == Outdated reference: A later version (-07) exists of draft-ietf-tls-dnssec-chain-extension-04 == Outdated reference: draft-ietf-tls-tls13 has been published as RFC 8446 -- 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: 5 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: December 18, 2017 T. Reddy 7 McAfee 8 June 16, 2017 10 Usage and (D)TLS Profiles for DNS-over-(D)TLS 11 draft-ietf-dprive-dtls-and-tls-profiles-10 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 December 18, 2017. 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. -10 version . . . . . . . . . . . . . . . . . . . . . . . 25 95 B.2. -09 version . . . . . . . . . . . . . . . . . . . . . . . 26 96 B.3. -08 version . . . . . . . . . . . . . . . . . . . . . . . 26 97 B.4. -07 version . . . . . . . . . . . . . . . . . . . . . . . 26 98 B.5. -06 version . . . . . . . . . . . . . . . . . . . . . . . 26 99 B.6. -05 version . . . . . . . . . . . . . . . . . . . . . . . 27 100 B.7. -04 version . . . . . . . . . . . . . . . . . . . . . . . 27 101 B.8. -03 version . . . . . . . . . . . . . . . . . . . . . . . 27 102 B.9. -02 version . . . . . . . . . . . . . . . . . . . . . . . 27 103 B.10. -01 version . . . . . . . . . . . . . . . . . . . . . . . 28 104 B.11. draft-ietf-dprive-dtls-and-tls-profiles-00 . . . . . . . 28 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 107 1. Introduction 109 DNS Privacy issues are discussed in [RFC7626]. The specific issues 110 described there that are most relevant to this document are 112 o Passive attacks which eavesdrop on clear text DNS transactions on 113 the wire (Section 2.4) and 115 o Active attacks which redirect clients to rogue servers to monitor 116 DNS traffic (Section 2.5.3). 118 Mitigating against these attacks increases the privacy of DNS 119 transactions, however many of the other issues raised in [RFC7626] 120 still apply. 122 Two documents that provide ways to increase DNS privacy between DNS 123 clients and DNS servers are: 125 o Specification for DNS over Transport Layer Security (TLS) 126 [RFC7858], referred to here as simply 'DNS-over-TLS' 128 o DNS over Datagram Transport Layer Security (DTLS) [RFC8094], 129 referred to here simply as 'DNS-over-DTLS'. Note that this 130 document has the Category of Experimental. 132 Both documents are limited in scope to communications between stub 133 clients and recursive resolvers and the same scope is applied to this 134 document (see Section 2 and Section 3). The proposals here might be 135 adapted or extended in future to be used for recursive clients and 136 authoritative servers, but this application was out of scope for the 137 Working Group charter at the time this document was finished. 139 This document specifies two Usage Profiles (Strict and Opportunistic) 140 for DTLS [RFC6347] and TLS [RFC5246] which provide improved levels of 141 mitigation against the attacks described above compared to using only 142 clear text DNS. 144 Section 5 presents a generalized discussion of Usage Profiles by 145 separating the Usage Profile, which is based purely on the security 146 properties it offers the user, from the specific mechanism(s) that 147 are used for DNS server authentication. The Profiles described are: 149 o A Strict Profile that requires an encrypted connection and 150 successful authentication of the DNS server which mitigates both 151 passive eavesdropping and client re-direction (at the expense of 152 providing no DNS service if this is not available). 154 o An Opportunistic Profile that will attempt, but does not require, 155 encryption and successful authentication; it therefore provides 156 limited or no mitigation against such attacks but offers maximum 157 chance of DNS service. 159 The above Usage Profiles attempt authentication of the server using 160 at least one authentication mechanism. Section 6.4 discusses how to 161 combine authentication mechanisms to determine the overall 162 authentication result. Depending on that overall authentication 163 result (and whether encryption is available) the Usage Profile will 164 determine if the connection should proceed, fallback or fail. 166 One authentication mechanism is already described in [RFC7858]. That 167 document specifies a Subject Public Key Info (SPKI) based 168 authentication mechanism for DNS-over-TLS in the context of a 169 specific case of a Strict Usage Profile using that single 170 authentication mechanism. Therefore the "Out-of-band Key-pinned 171 Privacy Profile" described in [RFC7858] would qualify as a "Strict 172 Usage Profile" that used SPKI pinning for authentication. 174 This document extends the use of SPKI pinset based authentication so 175 that it is considered a general authentication mechanism that can be 176 used with either DNS-over-(D)TLS Usage Profile. That is, the SPKI 177 pinset mechanism described in [RFC7858] MAY be used with DNS- 178 over-(D)TLS. 180 This document also describes a number of additional authentication 181 mechanisms all of which specify how a DNS client should authenticate 182 a DNS server based on an 'authentication domain name'. In 183 particular, the following is described: 185 o How a DNS client can obtain the combination of an authentication 186 domain name and IP address for a DNS server. See Section 7. 188 o What are the acceptable credentials a DNS server can present to 189 prove its identity for (D)TLS authentication based on a given 190 authentication domain name. See Section 8. 192 o How a DNS client can verify that any given credential matches the 193 authentication domain name obtained for a DNS server. See 194 Section 8. 196 In Section 9 this document defines a (D)TLS protocol profile for use 197 with DNS. This profile defines the configuration options and 198 protocol extensions required of both parties to optimize connection 199 establishment and session resumption for transporting DNS, and to 200 support all currently specified authentication mechanisms. 202 2. Terminology 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 Several terms are used specifically in the context of this draft: 210 o DNS client: a DNS stub resolver or forwarder. In the case of a 211 forwarder, the term "DNS client" is used to discuss the side that 212 sends queries. 214 o DNS server: a DNS recursive resolver or forwarder. In the case of 215 a forwarder, the term "DNS server" is used to discuss the side 216 that responds to queries. For emphasis, in this document the term 217 does not apply to authoritative servers. 219 o Privacy-enabling DNS server: A DNS server that implements DNS- 220 over-TLS [RFC7858] and may optionally implement DNS-over-DTLS 221 [RFC8094]. The server should also offer at least one of the 222 credentials described in Section 8 and implement the (D)TLS 223 profile described in Section 9. 225 o (D)TLS: For brevity this term is used for statements that apply to 226 both Transport Layer Security [RFC5246] and Datagram Transport 227 Layer Security [RFC6347]. Specific terms will be used for any 228 statement that applies to either protocol alone. 230 o DNS-over-(D)TLS: For brevity this term is used for statements that 231 apply to both DNS-over-TLS [RFC7858] and DNS-over-DTLS [RFC8094]. 232 Specific terms will be used for any statement that applies to 233 either protocol alone. 235 o Authentication domain name: A domain name that can be used to 236 authenticate a privacy-enabling DNS server. Sources of 237 authentication domain names are discussed in Section 7. 239 o SPKI Pinsets: [RFC7858] describes the use of cryptographic digests 240 to "pin" public key information in a manner similar to HTTP Public 241 Key Pinning [RFC7469] (HPKP). An SPKI pinset is a collection of 242 these pins that constrains a DNS server. 244 o Authentication information: Information a DNS client may use as 245 the basis of an authentication mechanism. In this context that 246 can be either a: 248 * a SPKI pinset or 250 * an authentication domain name 252 o Reference Identifier: a Reference Identifier as described in 253 [RFC6125], constructed by the DNS client when performing TLS 254 authentication of a DNS server. 256 o Credential: Information available for a DNS server which proves 257 its identity for authentication purposes. Credentials discussed 258 here include: 260 * PKIX certificate 262 * DNSSEC validated chain to a TLSA record 264 but may also include SPKI pinsets. 266 3. Scope 268 This document is limited to describing 270 o Usage Profiles based on general authentication mechanisms 272 o The details of domain name based authentication of DNS servers by 273 DNS clients (as defined in the terminology section) 275 o The (D)TLS profiles needed to support authentication in DNS- 276 over-(D)TLS. 278 As such, the following things are out of scope: 280 o Authentication of authoritative servers by recursive resolvers. 282 o Authentication of DNS clients by DNS servers. 284 o The details of how to perform SPKI-pinset-based authentication. 285 This is defined in [RFC7858]. 287 o Any server identifier other than domain names, including IP 288 addresses, organizational names, country of origin, etc. 290 4. Discussion 292 One way to mitigate against passive attackers eavesdropping on clear 293 text DNS transactions is to encrypt the query (and response). Such 294 encryption typically provides integrity protection as a side-effect, 295 which means on-path attackers cannot simply inject bogus DNS 296 responses. To also mitigate against active attackers pretending to 297 be the server, the client must authenticate the (D)TLS connection to 298 the server. 300 This document discusses Usage Profiles, which provide differing 301 levels of attack mitigation to DNS clients, based on the requirements 302 for authentication and encryption, regardless of the context (for 303 example, which network the client is connected to). A Usage Profile 304 is a distinct concept to a usage policy or usage model, which might 305 dictate which Profile should be used in a particular context 306 (enterprise vs coffee shop), with a particular set of DNS Servers or 307 with reference to other external factors. A description of the 308 variety of usage policies is out of scope of this document, but may 309 be the subject of future work. 311 The term 'privacy-enabling DNS server' is used throughout this 312 document. This is a DNS server that: 314 o MUST implement DNS-over-TLS [RFC7858]. 316 o MAY implement DNS-over-DTLS [RFC8094]. 318 o SHOULD offer at least one of the credentials described in 319 Section 8. 321 o Implements the (D)TLS profile described in Section 9. 323 5. Usage Profiles 325 A DNS client has a choice of Usage Profiles available to increase the 326 privacy of DNS transactions. This choice is briefly discussed in 327 both [RFC7858] and [RFC8094]. These Usage Profiles are: 329 o Strict profile: the DNS client requires both an encrypted and 330 authenticated connection to a privacy-enabling DNS Server. A hard 331 failure occurs if this is not available. This requires the client 332 to securely obtain authentication information it can use to 333 authenticate the server. This profile mitigates against both 334 passive and active attacks providing the client with the best 335 available privacy for DNS. This Profile is discussed in detail in 336 Section 6.6. 338 o Opportunistic Privacy: the DNS client uses Opportunistic Security 339 as described in [RFC7435] 341 "... the use of cleartext as the baseline communication 342 security policy, with encryption and authentication negotiated 343 and applied to the communication when available." 345 The use of Opportunistic Privacy is intended to support 346 incremental deployment of increased privacy with a view to 347 widespread adoption of the Strict profile. It should be employed 348 when the DNS client might otherwise settle for cleartext; it 349 provides the maximum protection an attacker will allow. As 350 described in [RFC7435] it might result in 352 * an encrypted and authenticated connection 354 * an encrypted connection 356 * a clear text connection 358 depending on the fallback logic of the client, the available 359 authentication information and the capabilities of the DNS Server. 360 In all these cases the DNS client is willing to continue with a 361 connection to the DNS Server and perform resolution of queries. 363 Both profiles can include an initial meta query (performed using an 364 Opportunistic lookup) to obtain the IP address for the privacy- 365 enabling DNS server to which the DNS client will subsequently 366 connect. The rationale for permitting this for the Strict profile is 367 that requiring such meta queries to also be performed using the 368 Strict profile would introduce significant deployment obstacles. 369 However, it should be noted that in this scenario an active attack is 370 possible on the meta query which could result in the client not being 371 able to connect to a privacy-enabling DNS server that it can 372 authenticate. 374 To compare the two Usage profiles the table below shows a successful 375 Strict profile along side the 3 possible outcomes of an Opportunistic 376 profile. In the best case scenario for the Opportunistic profile (an 377 authenticated and encrypted connection) it is equivalent to the 378 Strict profile. In the worst case scenario it is equivalent to clear 379 text. Clients using the Opportunistic profile SHOULD try for the 380 best case but MAY fallback to the intermediate case and eventually 381 the worst case scenario in order to obtain a response. One reason to 382 fallback without trying every available privacy-enabling DNS server 383 is if latency is more important than attack mitigation, see 384 Appendix A. The Opportunistic profile therefore provides varying 385 protection depending on what kind of connection is actually used 386 including no attack mitigation at all. 388 Note that there is no requirement in Opportunistic Security to notify 389 the user what type of connection is actually used, the 'detection' 390 described below is only possible if such connection information is 391 available. However, if it is available and the user is informed that 392 an unencrypted connection was used to connect to a server then the 393 user should assume (detect) that the connection is subject to both 394 active and passive attack since the DNS queries are sent in clear 395 text. This might be particularly useful if a new connection to a 396 certain server is unencrypted when all previous connections were 397 encrypted. Similarly if the user is informed that an encrypted but 398 unauthenticated connection was used then the user can detect that the 399 connection may be subject to active attack. In other words for the 400 cases where no protection is provided against an attacker (N) it is 401 possible to detect that an attack might be happening (D). This is 402 discussed in Section 6.5. 404 +---------------+------------+------------------+-----------------+ 405 | Usage Profile | Connection | Passive Attacker | Active Attacker | 406 +---------------+------------+------------------+-----------------+ 407 | Strict | A, E | P | P | 408 | Opportunistic | A, E | P | P | 409 | Opportunistic | E | P | N, D | 410 | Opportunistic | | N, D | N, D | 411 +---------------+------------+------------------+-----------------+ 413 P == Protection; N == No protection; D == Detection is possible; A == 414 Authenticated connection; E == Encrypted connection 416 Table 1: Attack protection by Usage Profile and type of attacker 418 The Strict profile provides the best attack mitigation and therefore 419 SHOULD always be implemented in DNS clients that implement 420 Opportunistic Privacy. 422 A DNS client that implements DNS-over-(D)TLS SHOULD NOT be configured 423 by default to use only clear text. 425 The choice between the two profiles depends on a number of factors 426 including which is more important to the particular client: 428 o DNS service at the cost of no attack mitigation (Opportunistic) or 429 o best available attack mitigation at the potential cost of no DNS 430 service (Strict). 432 Additionally the two profiles require varying levels of configuration 433 (or a trusted relationship with a provider) and DNS server 434 capabilities, therefore DNS clients will need to carefully select 435 which profile to use based on their communication needs. 437 A DNS server that implements DNS-over-(D)TLS SHOULD provide at least 438 one credential so that those DNS clients that wish to do so are able 439 to use the Strict profile (see Section 2). 441 5.1. DNS Resolution 443 A DNS client SHOULD select a particular Usage Profile when resolving 444 a query. A DNS client MUST NOT fallback from Strict Privacy to 445 Opportunistic Privacy during the resolution of a given query as this 446 could invalidate the protection offered against attackers. It is 447 anticipated that DNS clients will use a particular Usage Profile for 448 all queries to all configured servers until an operational issue or 449 policy update dictates a change in the profile used. 451 6. Authentication in DNS-over(D)TLS 453 This section describes authentication mechanisms and how they can be 454 used in either Strict or Opportunistic Privacy for DNS-over-(D)TLS. 456 6.1. DNS-over-(D)TLS Startup Configuration Problems 458 Many (D)TLS clients use PKIX authentication [RFC6125] based on an 459 authentication domain name for the server they are contacting. These 460 clients typically first look up the server's network address in the 461 DNS before making this connection. Such a DNS client therefore has a 462 bootstrap problem, as it will typically only know the IP address of 463 its DNS server. 465 In this case, before connecting to a DNS server, a DNS client needs 466 to learn the authentication domain name it should associate with the 467 IP address of a DNS server for authentication purposes. Sources of 468 authentication domain names are discussed in Section 7. 470 One advantage of this domain name based approach is that it 471 encourages association of stable, human recognizable identifiers with 472 secure DNS service providers. 474 6.2. Credential Verification 476 The use of SPKI pinset verification is discussed in [RFC7858]. 478 In terms of domain name based verification, once an authentication 479 domain name is known for a DNS server a choice of authentication 480 mechanisms can be used for credential verification. Section 8 481 discusses these mechanisms in detail, namely PKIX certificate based 482 authentication and DANE. 484 Note that the use of DANE adds requirements on the ability of the 485 client to get validated DNSSEC results. This is discussed in more 486 detail in Section 8.2. 488 6.3. Summary of Authentication Mechanisms 490 This section provides an overview of the various authentication 491 mechanisms. The table below indicates how the DNS client obtains 492 information to use for authentication for each option; either 493 statically via direct configuration or dynamically. Of course, the 494 Opportunistic Usage Profile does not require authentication and so a 495 client using that profile may choose to connect to a privacy-enabling 496 DNS server on the basis of just an IP address. 498 +---+------------+-------------+------------------------------------+ 499 | # | Static | Dynamically | Short name: Description | 500 | | Config | Obtained | | 501 +---+------------+-------------+------------------------------------+ 502 | 1 | SPKI + IP | | SPKI: SPKI pinset(s) and IP | 503 | | | | address obtained out of band | 504 | | | | [RFC7858] | 505 | | | | | 506 | 2 | ADN + IP | | ADN: ADN and IP address obtained | 507 | | | | out of band (see Section 7.1) | 508 | | | | | 509 | 3 | ADN | IP | ADN only: Opportunistic lookups to | 510 | | | | a NP DNS server for A/AAAA (see | 511 | | | | Section 7.2) | 512 | | | | | 513 | 4 | | ADN + IP | DHCP: DHCP configuration only (see | 514 | | | | Section 7.3.1) | 515 | | | | | 516 | 5 | [ADN + IP] | [ADN + IP] | DANE: DNSSEC chain obtained via | 517 | | | TLSA record | Opportunistic lookups to NP DNS | 518 | | | | server (see Section 8.2.1) | 519 | | | | | 520 | 6 | [ADN + IP] | [ADN + IP] | TLS extension: DNSSEC chain | 521 | | | TLSA record | provided by PE DNS server in TLS | 522 | | | | DNSSEC chain extension (see | 523 | | | | Section 8.2.2) | 524 +---+------------+-------------+------------------------------------+ 526 SPKI == SPKI pinset(s), IP == IP Address, ADN == Authentication 527 Domain Name, NP == Network provided, PE == Privacy-enabling, [ ] == 528 Data may be obtained either statically or dynamically 530 Table 2: Overview of Authentication Mechanisms 532 The following summary attempts to present some key attributes of each 533 of the mechanisms (using the 'Short name' from Table 2), indicating 534 attractive attributes with a '+' and undesirable attributes with a 535 '-'. 537 1. SPKI 539 + Minimal leakage (Note that the ADN is always leaked in the 540 Server Name Indication (SNI) field in the Client Hello in TLS 541 when communicating with a privacy-enabling DNS server) 543 - Overhead of on-going key management required 545 2. ADN 546 + Minimal leakage 548 + One-off direct configuration only 550 3. ADN only 552 + Minimal one-off direct configuration, only a human 553 recognizable domain name needed 555 - A/AAAA meta queries leaked to network provided DNS server 556 that may be subject to active attack 558 4. DHCP 560 + No static config 562 - Requires a non-standard or future DHCP option in order to 563 provide the ADN 565 - Requires secure and trustworthy connection to DHCP server if 566 used with a Strict Usage profile 568 5. DANE 570 The ADN and/or IP may be obtained statically or dynamically 571 and the relevant attributes of that method apply 573 + DANE options (e.g., matching on entire certificate) 575 - Requires a DNSSEC validating stub implementation (deployment 576 of which is limited at the time of writing) 578 - DNSSEC chain meta queries leaked to network provided DNS 579 server that may be subject to active attack 581 6. TLS extension 583 The ADN and/or IP may be obtained statically or dynamically 584 and the relevant attributes of that method apply 586 + Reduced latency compared with 'DANE' 588 + No network provided DNS server required if ADN and IP 589 statically configured 591 + DANE options (e.g., matching on entire certificate) 593 - Requires a DNSSEC validating stub implementation 595 6.4. Combining Authentication Mechanisms 597 This draft does not make explicit recommendations about how an SPKI 598 pinset based authentication mechanism should be combined with a 599 domain based mechanism from an operator perspective. However it can 600 be envisaged that a DNS server operator may wish to make both an SPKI 601 pinset and an authentication domain name available to allow clients 602 to choose which mechanism to use. Therefore, the following is 603 guidance on how clients ought to behave if they choose to configure 604 both, as is possible in HPKP [RFC7469]. 606 A DNS client that is configured with both an authentication domain 607 name and a SPKI pinset for a DNS server SHOULD match on both a valid 608 credential for the authentication domain name and a valid SPKI pinset 609 (if both are available) when connecting to that DNS server. In this 610 case the client SHOULD treat the SPKI pin as specified in Section 2.6 611 of [RFC7469] with regard to user defined trust anchors. The overall 612 authentication result SHOULD only be considered successful if both 613 authentication mechanisms are successful. 615 6.5. Authentication in Opportunistic Privacy 617 An Opportunistic Security [RFC7435] profile is described in [RFC7858] 618 which MAY be used for DNS-over-(D)TLS. 620 DNS clients issuing queries under an opportunistic profile and which 621 know authentication information for a given privacy-enabling DNS 622 server SHOULD try to authenticate the server using the mechanisms 623 described here. This is useful for detecting (but not preventing) 624 active attack, since the fact that authentication information is 625 available indicates that the server in question is a privacy-enabling 626 DNS server to which it should be possible to establish an 627 authenticated and encrypted connection. In this case, whilst a 628 client cannot know the reason for an authentication failure, from a 629 security standpoint the client should consider an active attack in 630 progress and proceed under that assumption. For example, a client 631 that implements a nameserver selection algorithm that preferentially 632 uses nameservers which successfully authenticated (see Section 5) 633 might not continue to use the failing server if there were 634 alternative servers available. 636 Attempting authentication is also useful for debugging or diagnostic 637 purposes if there are means to report the result. This information 638 can provide a basis for a DNS client to switch to (preferred) Strict 639 Privacy where it is viable e.g, where all the configured servers 640 support DNS-over-(D)TLS and successfully authenticate. 642 6.6. Authentication in Strict Privacy 644 To authenticate a privacy-enabling DNS server, a DNS client needs to 645 know authentication information for each server it is willing to 646 contact. This is necessary to protect against active attacks which 647 attempt to re-direct clients to rogue DNS servers. 649 A DNS client requiring Strict Privacy MUST either use one of the 650 sources listed in Section 7 to obtain an authentication domain name 651 for the server it contacts, or use an SPKI pinset as described in 652 [RFC7858]. 654 A DNS client requiring Strict Privacy MUST only attempt to connect to 655 DNS servers for which at least one piece of authentication 656 information is known. The client MUST use the available verification 657 mechanisms described in Section 8 to authenticate the server, and 658 MUST abort connections to a server when no verification mechanism 659 succeeds. 661 With Strict Privacy, the DNS client MUST NOT commence sending DNS 662 queries until at least one of the privacy-enabling DNS servers 663 becomes available. 665 A privacy-enabling DNS server may be temporarily unavailable when 666 configuring a network. For example, for clients on networks that 667 require registration through web-based login (a.k.a. "captive 668 portals"), such registration may rely on DNS interception and 669 spoofing. Techniques such as those used by DNSSEC-trigger 670 [dnssec-trigger] MAY be used during network configuration, with the 671 intent to transition to the designated privacy-enabling DNS servers 672 after captive portal registration. If using a Strict Usage profile 673 the system MUST alert by some means that the DNS is not private 674 during such bootstrap. 676 6.7. Implementation guidance 678 Section 9 describes the (D)TLS profile for DNS-over(D)TLS. 679 Additional considerations relating to general implementation 680 guidelines are discussed in both Section 11 and in Appendix A. 682 7. Sources of Authentication Domain Names 684 7.1. Full direct configuration 686 DNS clients may be directly and securely provisioned with the 687 authentication domain name of each privacy-enabling DNS server. For 688 example, using a client specific configuration file or API. 690 In this case, direct configuration for a DNS client would consist of 691 both an IP address and an authentication domain name for each DNS 692 server. 694 7.2. Direct configuration of ADN only 696 A DNS client may be configured directly and securely with only the 697 authentication domain name of each of its privacy-enabling DNS 698 servers. For example, using a client specific configuration file or 699 API. 701 A DNS client might learn of a default recursive DNS resolver from an 702 untrusted source (such as DHCP's DNS server option [RFC3646]). It 703 can then use Opportunistic DNS connections to an untrusted recursive 704 DNS resolver to establish the IP address of the intended privacy- 705 enabling DNS resolver by doing a lookup of A/AAAA records. Private 706 DNS resolution can now be done by the DNS client against the pre- 707 configured privacy-enabling DNS resolver, using the IP address 708 gathered from the untrusted DNS resolver. 710 A DNS client so configured that successfully connects to a privacy- 711 enabling DNS server MAY choose to locally cache the server host IP 712 addresses in order to not have to repeat the opportunistic lookup. 714 7.3. Dynamic discovery of ADN 716 This section discusses the general case of a DNS client discovering 717 both the authentication domain name and IP address dynamically. This 718 is not possible at the time of writing by any standard means. 719 However since, for example, a future DHCP extension could (in 720 principle) provide this mechanism the required security properties of 721 such mechanisms are outlined here. 723 When using a Strict profile the dynamic discovery technique used as a 724 source of authentication domain names MUST be considered secure and 725 trustworthy. This requirement does not apply when using an 726 Opportunistic profile given the security expectation of that profile. 728 7.3.1. DHCP 730 In the typical case today, a DHCP server [RFC2131] [RFC3315] provides 731 a list of IP addresses for DNS resolvers (see Section 3.8 of 732 [RFC2132]), but does not provide an authentication domain name for 733 the DNS resolver, thus preventing the use of most of the 734 authentication methods described here (all those that are based on a 735 mechanism with ADN in Table 2). 737 This document does not specify or request any DHCP extension to 738 provide authentication domain names. However, if one is developed in 739 future work the issues outlined in Section 8 of [RFC7227] should be 740 taken into account as should the Security Considerations in 741 Section 23 of [RFC3315]). 743 This document does not attempt to describe secured and trusted 744 relationships to DHCP servers, which is a purely DHCP issue (still 745 open, at the time of writing.) Whilst some implementation work is in 746 progress to secure IPv6 connections for DHCP, IPv4 connections have 747 received little to no implementation attention in this area. 749 8. Authentication Domain Name based Credential Verification 751 8.1. PKIX Certificate Based Authentication 753 When a DNS client configured with an authentication domain name 754 connects to its configured DNS server over (D)TLS, the server may 755 present it with a PKIX certificate. In order to ensure proper 756 authentication, DNS clients MUST verify the entire certification path 757 per [RFC5280]. The DNS client additionally uses [RFC6125] validation 758 techniques to compare the domain name to the certificate provided. 760 A DNS client constructs one Reference Identifier for the server based 761 on the authentication domain name: A DNS-ID which is simply the 762 authentication domain name itself. 764 If the Reference Identifier is found in the PKIX certificate's 765 subjectAltName extension as described in section 6 of [RFC6125], the 766 DNS client should accept the certificate for the server. 768 A compliant DNS client MUST only inspect the certificate's 769 subjectAltName extension for the Reference Identifier. In 770 particular, it MUST NOT inspect the Subject field itself. 772 8.2. DANE 774 DANE [RFC6698] provides mechanisms to anchor certificate and raw 775 public key trust with DNSSEC. However this requires the DNS client 776 to have an authentication domain name for the DNS Privacy Server 777 which must be obtained via a trusted source. 779 This section assumes a solid understanding of both DANE [RFC6698] and 780 DANE Operations [RFC7671]. A few pertinent issues covered in these 781 documents are outlined here as useful pointers, but familiarity with 782 both these documents in their entirety is expected. 784 It is noted that [RFC6698] says 785 "Clients that validate the DNSSEC signatures themselves MUST use 786 standard DNSSEC validation procedures. Clients that rely on 787 another entity to perform the DNSSEC signature validation MUST use 788 a secure mechanism between themselves and the validator." 790 It is noted that [RFC7671] covers the following topics: 792 o Section 4.1: Opportunistic Security and PKIX Usages and 793 Section 14: Security Considerations, which both discuss the use of 794 Trust Anchor and End Entity based schemes (PKIX-TA(0) and PKIX- 795 EE(1) respectively) for Opportunistic Security. 797 o Section 5: Certificate-Usage-Specific DANE Updates and Guidelines. 798 Specifically Section 5.1 which outlines the combination of 799 Certificate Usage DANE-EE(3) and Selector Usage SPKI(1) with Raw 800 Public Keys [RFC7250]. Section 5.1 also discusses the security 801 implications of this mode, for example, it discusses key lifetimes 802 and specifies that validity period enforcement is based solely on 803 the TLSA RRset properties for this case. 805 o Section 13: Operational Considerations, which discusses TLSA TTLs 806 and signature validity periods. 808 The specific DANE record for a DNS Privacy Server would take the 809 form: 811 _853._tcp.[authentication-domain-name] for TLS 813 _853._udp.[authentication-domain-name] for DTLS 815 8.2.1. Direct DNS Lookup 817 The DNS client MAY choose to perform the DNS lookups to retrieve the 818 required DANE records itself. The DNS queries for such DANE records 819 MAY use Opportunistic encryption or be in the clear to avoid trust 820 recursion. The records MUST be validated using DNSSEC as described 821 above in [RFC6698]. 823 8.2.2. TLS DNSSEC Chain extension 825 The DNS client MAY offer the TLS extension described in 826 [I-D.ietf-tls-dnssec-chain-extension]. If the DNS server supports 827 this extension, it can provide the full chain to the client in the 828 handshake. 830 If the DNS client offers the TLS DNSSEC Chain extension, it MUST be 831 capable of validating the full DNSSEC authentication chain down to 832 the leaf. If the supplied DNSSEC chain does not validate, the client 833 MUST ignore the DNSSEC chain and validate only via other supplied 834 credentials. 836 9. (D)TLS Protocol Profile 838 This section defines the (D)TLS protocol profile of DNS-over-(D)TLS. 840 Clients and servers MUST adhere to the (D)TLS implementation 841 recommendations and security considerations of [RFC7525] except with 842 respect to (D)TLS version. 844 Since encryption of DNS using (D)TLS is a green-field deployment DNS 845 clients and servers MUST implement only (D)TLS 1.2 or later. For 846 example, implementing TLS 1.3 [I-D.ietf-tls-tls13] is also an option. 848 Implementations MUST NOT offer or provide TLS compression, since 849 compression can leak significant amounts of information, especially 850 to a network observer capable of forcing the user to do an arbitrary 851 DNS lookup in the style of the CRIME attacks [CRIME]. 853 Implementations compliant with this profile MUST implement all of the 854 following items: 856 o TLS session resumption without server-side state [RFC5077] which 857 eliminates the need for the server to retain cryptographic state 858 for longer than necessary (This statement updates [RFC7858]). 860 o Raw public keys [RFC7250] which reduce the size of the 861 ServerHello, and can be used by servers that cannot obtain 862 certificates (e.g., DNS servers on private networks). A client 863 MUST only indicate support for raw public keys if it has an SPKI 864 pinset pre-configured (for interoperability reasons). 866 Implementations compliant with this profile SHOULD implement all of 867 the following items: 869 o TLS False Start [RFC7918] which reduces round-trips by allowing 870 the TLS second flight of messages (ChangeCipherSpec) to also 871 contain the (encrypted) DNS query. 873 o Cached Information Extension [RFC7924] which avoids transmitting 874 the server's certificate and certificate chain if the client has 875 cached that information from a previous TLS handshake. 877 Guidance specific to TLS is provided in [RFC7858] and that specific 878 to DTLS it is provided in [RFC8094]. 880 10. IANA Considerations 882 This memo includes no request to IANA. 884 11. Security Considerations 886 Security considerations discussed in [RFC7525], [RFC8094] and 887 [RFC7858] apply to this document. 889 DNS Clients SHOULD implement support for the mechanisms described in 890 Section 8.2 and offering a configuration option which limits 891 authentication to using only those mechanisms (i.e., with no fallback 892 to pure PKIX based authentication) such that authenticating solely 893 via the PKIX infrastructure can be avoided. 895 11.1. Counter-measures to DNS Traffic Analysis 897 This section makes suggestions for measures that can reduce the 898 ability of attackers to infer information pertaining to encrypted 899 client queries by other means (e.g., via an analysis of encrypted 900 traffic size, or via monitoring of resolver to authoritative 901 traffic). 903 DNS-over-(D)TLS clients and servers SHOULD implement the following 904 relevant DNS extensions 906 o EDNS(0) padding [RFC7830], which allows encrypted queries and 907 responses to hide their size making analysis of encrypted traffic 908 harder. 910 Guidance on padding policies for EDNS(0) is provided in 911 [I-D.ietf-dprive-padding-policy] 913 DNS-over-(D)TLS clients SHOULD implement the following relevant DNS 914 extensions 916 o Privacy Election using Client Subnet in DNS Queries [RFC7871]. If 917 a DNS client does not include an EDNS0 Client Subnet Option with a 918 SOURCE PREFIX-LENGTH set to 0 in a query, the DNS server may 919 potentially leak client address information to the upstream 920 authoritative DNS servers. A DNS client ought to be able to 921 inform the DNS Resolver that it does not want any address 922 information leaked, and the DNS Resolver should honor that 923 request. 925 12. Acknowledgments 927 Thanks to the authors of both [RFC8094] and [RFC7858] for laying the 928 ground work that this draft builds on and for reviewing the contents. 929 The authors would also like to thank John Dickinson, Shumon Huque, 930 Melinda Shore, Gowri Visweswaran, Ray Bellis, Stephane Bortzmeyer, 931 Jinmei Tatuya, Paul Hoffman, Christian Huitema and John Levine for 932 review and discussion of the ideas presented here. 934 13. References 936 13.1. Normative References 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 944 "Transport Layer Security (TLS) Session Resumption without 945 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 946 January 2008, . 948 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 949 (TLS) Protocol Version 1.2", RFC 5246, 950 DOI 10.17487/RFC5246, August 2008, 951 . 953 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 954 Housley, R., and W. Polk, "Internet X.509 Public Key 955 Infrastructure Certificate and Certificate Revocation List 956 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 957 . 959 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 960 Verification of Domain-Based Application Service Identity 961 within Internet Public Key Infrastructure Using X.509 962 (PKIX) Certificates in the Context of Transport Layer 963 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 964 2011, . 966 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 967 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 968 January 2012, . 970 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 971 of Named Entities (DANE) Transport Layer Security (TLS) 972 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 973 2012, . 975 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 976 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 977 Transport Layer Security (TLS) and Datagram Transport 978 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 979 June 2014, . 981 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 982 "Recommendations for Secure Use of Transport Layer 983 Security (TLS) and Datagram Transport Layer Security 984 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 985 2015, . 987 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 988 Authentication of Named Entities (DANE) Protocol: Updates 989 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 990 October 2015, . 992 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 993 DOI 10.17487/RFC7830, May 2016, 994 . 996 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 997 and P. Hoffman, "Specification for DNS over Transport 998 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 999 2016, . 1001 [RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport 1002 Layer Security (TLS) False Start", RFC 7918, 1003 DOI 10.17487/RFC7918, August 2016, 1004 . 1006 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 1007 (TLS) Cached Information Extension", RFC 7924, 1008 DOI 10.17487/RFC7924, July 2016, 1009 . 1011 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 1012 Transport Layer Security (DTLS)", RFC 8094, 1013 DOI 10.17487/RFC8094, February 2017, 1014 . 1016 13.2. Informative References 1018 [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", 2012. 1020 [dnssec-trigger] 1021 NLnetLabs, "Dnssec-Trigger", May 2014, 1022 . 1024 [I-D.ietf-dprive-padding-policy] 1025 Mayrhofer, A., "Padding Policy for EDNS(0)", draft-ietf- 1026 dprive-padding-policy-00 (work in progress), December 1027 2016. 1029 [I-D.ietf-tls-dnssec-chain-extension] 1030 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 1031 Record and DNSSEC Authentication Chain Extension for TLS", 1032 draft-ietf-tls-dnssec-chain-extension-04 (work in 1033 progress), June 2017. 1035 [I-D.ietf-tls-tls13] 1036 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1037 Version 1.3", draft-ietf-tls-tls13-20 (work in progress), 1038 April 2017. 1040 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1041 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1042 . 1044 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1045 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1046 . 1048 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1049 C., and M. Carney, "Dynamic Host Configuration Protocol 1050 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1051 2003, . 1053 [RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic 1054 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1055 DOI 10.17487/RFC3646, December 2003, 1056 . 1058 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 1059 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 1060 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 1061 . 1063 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1064 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1065 December 2014, . 1067 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1068 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1069 2015, . 1071 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 1072 DOI 10.17487/RFC7626, August 2015, 1073 . 1075 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 1076 Kumari, "Client Subnet in DNS Queries", RFC 7871, 1077 DOI 10.17487/RFC7871, May 2016, 1078 . 1080 Appendix A. Server capability probing and caching by DNS clients 1082 This section presents a non-normative discussion of how DNS clients 1083 might probe for and cache capabilities of privacy-enabling DNS 1084 servers. 1086 Deployment of both DNS-over-TLS and DNS-over-DTLS will be gradual. 1087 Not all servers will support one or both of these protocols and the 1088 well-known port might be blocked by some middleboxes. Clients will 1089 be expected to keep track of servers that support DNS-over-TLS and/or 1090 DNS-over-DTLS, and those that have been previously authenticated. 1092 If no server capability information is available then (unless 1093 otherwise specified by the configuration of the DNS client) DNS 1094 clients that implement both TLS and DTLS should try to authenticate 1095 using both protocols before failing or falling back to a 1096 unauthenticated or clear text connections. DNS clients using an 1097 Opportunistic Usage profile should try all available servers 1098 (possibly in parallel) in order to obtain an authenticated and 1099 encrypted connection before falling back. (RATIONALE: This approach 1100 can increase latency while discovering server capabilities but 1101 maximizes the chance of sending the query over an authenticated and 1102 encrypted connection.) 1104 Appendix B. Changes between revisions 1106 [Note to RFC Editor: please remove this section prior to 1107 publication.] 1109 B.1. -10 version 1111 Clarified the specific attacks the Usage profiles mitigate against. 1113 Revised wording in the draft relating 'security/privacy guarantees' 1114 and generally improved consistency of wording throughout the 1115 document. 1117 Corrected and added a number of references: 1119 o RFC7924 is now Normative 1121 o RFC7918 and RFC8094 are now Normative (and therefore Downrefs) 1123 o draft-ietf-tls-tls13, draft-ietf-dprive-padding-policy,RFC3315 and 1124 RFC7227 added 1126 Terminology: Update definition of Privacy-enabling DNS server and 1127 moved normative definition to section 4. 1129 Section 5 and 6.3: Included discussion of the additional attacks 1130 possible when using meta-queries to bootstrap the DNS service 1132 Section 5: Added sentence on why Opportunistic Profile may fallback 1133 for latency reasons. 1135 Section 5.1: Added discussion of when clients might change Usage 1136 Profiles. 1138 Section 6.4: Added caveat on use of combined authentication re 1139 RFC7469. 1141 Section 6.5: Added more detail on how authentication results might be 1142 used in Opportunistic. Opportunistic clients now SHOULD try for the 1143 best case. 1145 Section 7.3: Re-worked this section and the discussion of DHCP. 1147 Section 9: Removed unnecessary text, added condition on use of 1148 RFC7250 (Raw public keys). 1150 Section 11.: More detail on padding policies. 1152 Numerous editorial corrections. 1154 B.2. -09 version 1156 Remove the SRV record to simplify the draft. 1158 Add suggestion that clients offer option to avoid using only PKIX 1159 authentication. 1161 Clarify that the MUST on implementing TLS session resumption updates 1162 RFC7858. 1164 Update page header to be '(D)TLS Authentication for TLS'. 1166 B.3. -08 version 1168 Removed hard failure as an option for Opportunistic Usage profile. 1170 Added a new section comparing the Authentication Mechanisms 1172 B.4. -07 version 1174 Re-work of the Abstract and Introduction to better describe the 1175 contents in this version. 1177 Terminology: New definition of 'authentication information'. 1179 Scope: Changes to the Scope section. 1181 Moved discussion of combining authentication mechanism earlier. 1183 Changes to the section headings and groupings to make the 1184 presentation more logical. 1186 B.5. -06 version 1188 Introduction: Re-word discussion of Working group charter. 1190 Introduction: Re-word first and third bullet point about 'obtaining' 1191 a domain name and IP address. 1193 Introduction: Update reference to DNS-over-TLS draft. 1195 Terminology: Change forwarder/proxy to just forwarder 1197 Terminology: Add definition of 'Authentication domain name' and use 1198 this throughout 1200 Section 4.2: Remove parenthesis in the table. 1202 Section 4.2: Change the text after the table as agreed with Paul 1203 Hoffman. 1205 Section 4.3.1: Change title and remove brackets around last 1206 statement. 1208 Section 11: Split second paragraph. 1210 B.6. -05 version 1212 Add more details on detecting passive attacks to section 4.2 1214 Changed X.509 to PKIX throughout 1216 Change comment about future I-D on usage policies. 1218 B.7. -04 version 1220 Introduction: Add comment that DNS-over-DTLS draft is Experiments 1222 Update 2 I-D references to RFCs. 1224 B.8. -03 version 1226 Section 9: Update DANE section with better references to RFC7671 and 1227 RFC7250 1229 B.9. -02 version 1231 Introduction: Added paragraph on the background and scope of the 1232 document. 1234 Introduction and Discussion: Added more information on what a Usage 1235 profiles is (and is not) the the two presented here. 1237 Introduction: Added paragraph to make a comparison with the Strict 1238 profile in RFC7858 clearer. 1240 Section 4.2: Re-worked the description of Opportunistic and the 1241 table. 1243 Section 8.3: Clarified statement about use of DHCP in Opportunistic 1244 profile 1246 Title abbreviated. 1248 B.10. -01 version 1250 Section 4.2: Make clear that the Strict Privacy Profile can include 1251 meta queries performed using Opportunistic Privacy. 1253 Section 4.2, Table 1: Update to clarify that Opportunistic Privacy 1254 does not guarantee protection against passive attack. 1256 Section 4.2: Add sentence discussing client/provider trusted 1257 relationships. 1259 Section 5: Add more discussion of detection of active attacks when 1260 using Opportunistic Privacy. 1262 Section 8.2: Clarify description and example. 1264 B.11. draft-ietf-dprive-dtls-and-tls-profiles-00 1266 Re-submission of draft-dgr-dprive-dtls-and-tls-profiles with name 1267 change to draft-ietf-dprive-dtls-and-tls-profiles. Also minor nits 1268 fixed. 1270 Authors' Addresses 1272 Sara Dickinson 1273 Sinodun Internet Technologies 1274 Magdalen Centre 1275 Oxford Science Park 1276 Oxford OX4 4GA 1277 UK 1279 Email: sara@sinodun.com 1280 URI: http://sinodun.com 1282 Daniel Kahn Gillmor 1283 ACLU 1284 125 Broad Street, 18th Floor 1285 New York NY 10004 1286 USA 1288 Email: dkg@fifthhorseman.net 1289 Tirumaleswar Reddy 1290 McAfee, Inc. 1291 Embassy Golf Link Business Park 1292 Bangalore, Karnataka 560071 1293 India 1295 Email: TirumaleswarReddy_Konda@McAfee.com