idnits 2.17.1 draft-hal-adot-operational-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 633 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 562 -- Looks like a reference, but probably isn't: '2' on line 565 -- Looks like a reference, but probably isn't: '3' on line 567 -- Looks like a reference, but probably isn't: '4' on line 569 -- Looks like a reference, but probably isn't: '5' on line 571 -- Looks like a reference, but probably isn't: '6' on line 573 -- Looks like a reference, but probably isn't: '7' on line 575 -- Looks like a reference, but probably isn't: '8' on line 577 -- Looks like a reference, but probably isn't: '9' on line 579 -- Looks like a reference, but probably isn't: '10' on line 581 -- Looks like a reference, but probably isn't: '11' on line 584 -- Looks like a reference, but probably isn't: '12' on line 587 -- Looks like a reference, but probably isn't: '13' on line 589 == Outdated reference: A later version (-07) exists of draft-hoffman-c2pq-05 == Outdated reference: A later version (-01) exists of draft-wood-tls-external-psk-importer-00 -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 7626 (Obsoleted by RFC 9076) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive or dnsop K. Henderson 3 Internet-Draft Verisign 4 Intended status: Informational T. April 5 Expires: January 9, 2020 Akamai 6 J. Livingood 7 Comcast 8 July 8, 2019 10 Authoritative DNS-over-TLS Operational Considerations 11 draft-hal-adot-operational-considerations-00 13 Abstract 15 DNS over TLS (DoT) has been gaining attention, primarily as a means 16 of communication between stub resolvers and recursive resolvers. 17 There have also been discussions and experiments involving the use of 18 DoT to communicate with authoritative nameservers (Authoritative DNS 19 over TLS or "ADoT"), including communication between recursive and 20 authoritative resolvers. However, we have identified a number of 21 operational concerns with ADoT. These operational concerns need to 22 be addressed prior to ADoT's deployment at scale by DNS operators in 23 order to maintain the stability and resilience of the global DNS. 24 The document also provides some suggested next steps to advance the 25 operator community's understanding of ADoT's operational impact. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction 62 1.1. Background and Motivation 63 1.1.1. Why operational considerations are so important for 64 ADoT 65 1.1.2. Other considerations related to ADoT 66 2. Terminology 67 2.1. Requirements Language 68 2.2. Definitions 69 3. Key Issues and Questions 70 3.1. Signaling Support for ADoT 71 3.2. Port number 72 3.3. TLS version 73 3.4. Resumptions 74 3.5. Operational Monitoring 75 3.6. Architecture 76 3.7. Socket efficiency/tuning considerations 77 3.8. Post-Quantum Security 78 4. Suggestions for further research and development 79 4.1. Required studies and analysis 80 4.2. Authoritative DNS over TLS (ADoT) Profile 81 5. Security Considerations 82 6. References 83 6.1. Informative References 84 6.2. URIs 85 Appendix A. Acknowledgements 86 Appendix B. Change Log 87 Authors' Addresses 89 1. Introduction 91 Typically, DNS communication between stub resolvers, recursive 92 resolvers, and authoritative servers is not encrypted. Some argue 93 that this can pose a privacy challenge for Internet users, because 94 their access to named network resources can potentially be tracked 95 through their DNS communication. In principle, any network element 96 along the path between the user and resolving or authoritative 97 nameservers could observe this unencrypted traffic. Many of these 98 concerns are addressed in [RFC7626]. 100 [RFC8310] proposes using DNS over TLS (DoT) in order to encrypt DNS 101 traffic. 103 Historically, much of the work on DNS encryption has focused on the 104 stub-to-recursive path as the recursive-to-authoritative server path 105 does not leak user specific information. However, with the increased 106 deployment of EDNS0 Client Subnet [RFC7871], recursive-to- 107 authoritative encryption is becoming an area of interest. Therefore, 108 this document focuses on the recursive-to-authoritative aspect of DoT 109 and we use the term Authoritative DNS over TLS (ADoT) in order to 110 differentiate it from the stub-to-recursive path. 112 The addition of ADoT, while providing encryption for DNS 113 communication, also introduces other factors that might impact the 114 stability and resiliency of authoritative nameserver operations which 115 may have been optimized for unencrypted DNS, often focusing on UDP 116 transport. 118 The objective of this document is to try to describe the problem 119 space, make suggestions about solutions, and propose next steps that 120 can help inform both recursive and authoritative operators on how to 121 assess and address the challenges posed by ADoT deployment. 123 1.1. Background and Motivation 125 1.1.1. Why operational considerations are so important for ADoT 127 The main concerns for most authoritative operators are the stability, 128 resiliency, scalability, and performance of their platforms. These 129 concerns need to be weighed against the benefits, if any, offered to 130 the end user by encrypting DNS queries to the authoritative servers 131 and the associated benefit of protection from modifications in 132 transit. 134 The communication between the recursive-to-authoritative server is 135 less able to be associated with a particular user than information 136 communicated along the stub-to-recursive path given that the 137 originating IP address is that of the recursive resolver, not the 138 user's, and the QNAME is potentially minimized. Therefore, initial 139 deployments of ADoT may offer an immediate expansion of the attack 140 surface (additional port, transport protocol, and computationally 141 expensive crypto operations for an attacker to exploit) while 142 potentially providing limited benefit to end users. 144 1.1.2. Other considerations related to ADoT 146 As resolvers add encryption on the client-to-recursive path, they may 147 also change the way they handle data on the recursive-to- 148 authoritative path. This is expressed in Mozilla Trusted Recursive 149 Resolver (TRR) requirements [1], for example, which require 150 participating resolvers to perform QNAME minimization [RFC7816], and 151 TRR requirement #6, which forbids the EDNS0 Client subnet (ECS) from 152 being propagated unless the recursive-to-authoritative path is 153 encrypted. 155 The latter requirement may have the possible unintended consequence 156 of reducing the authoritative name servers' ability to provide a best 157 response to DNS queries, until such time as they deploy DNS 158 encryption. 160 Given that recursive resolvers should be configured to prevent ECS 161 transmission to root, top-level, and effective top-level domain (TLD) 162 servers [RFC7871] section 12.1 [2] - the ECS encryption requirement 163 motivates consideration of authoritative DNS encryption below these 164 levels. 166 At the higher levels, techniques such as QNAME minimization and 167 Aggressive Use of DNSSEC-Validated Cache [RFC8198] arguably provide 168 an alternate path toward mitigating the risk of disclosure of 169 sensitive information without the operational risk of DNS encryption. 171 Resolver requirements may change as the understanding of DNS 172 encryption options evolve, but in the meantime, they provide 173 motivation for authoritative name server operators to weigh the risks 174 and benefits of DNS encryption, hence the importance of understanding 175 these operational considerations. 177 2. Terminology 179 2.1. Requirements Language 181 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 182 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 183 "OPTIONAL" in this document are to be interpreted as described in 184 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 185 capitals, as shown here. 187 2.2. Definitions 189 ADoT: Authoritative DNS over TLS - the use of DNS over TLS (DoT) when 190 communicating with an authoritative DNS server. eg: between the 191 recursive resolver and the authoritative DNS server (recursive-to- 192 authoritative). We use DoT when discussing generic DNS over TLS or 193 when referring to encrypted communication between stub and recursive 194 resolver. 196 Attack Surface: The sum of attack vectors where an unauthorized user 197 (attacker) can try to enter or extract data from the environment or 198 compromise a service via resource starvation. 200 Authoritative Operator: An operator of an authoritative DNS server. 202 CDN: Content Delivery Network - distributed network of servers which 203 proxy traffic between content providers and end users in order to 204 provide high availability and high performance. 206 ECS: EDNS0 Client Subnet [RFC7871] - an extension to EDNS0 where the 207 client's subnet is included in the DNS query, intended to provide a 208 hint to authoritative servers who may wish to provide different 209 answers in an attempt to provide higher performance for end users 210 based on their network location. 212 EPSK: External Pre-Shared Key - TLS 1.3 [RFC8446] uses the same PSK 213 extension for keys established both during handshake (resumption PSK) 214 and keys established externally. The EPSK acronym was introduced in 215 draft [I-D.draft-wood-tls-external-psk-importer-00] in order to 216 disambiguate External vs Resumption PSKs. 218 Performance: 220 o QRTT: Query Round-Trip Time - the time it takes between sending a 221 query and receiving a response. 223 o Best Response - whether or not the authoritative server, if 224 dynamic responses are used as they are in CDNs, are able to 225 determine or infer location and provide the most local response. 226 It is a key part of the end-to-end performance for end users to 227 get not just _an_ answer quickly but to get the best and most 228 local answer. 230 o System Performance - the cost in system resources such as CPU/IO/ 231 Memory. 233 o Queries Per Second (QPS) - the maximum number of simultaneous 234 queries that a DNS server can handle, on a per second basis. 236 Authoritative Server - see [RFC8499] 238 Recursive Resolver - see [RFC8499] 240 Stub Resolver - see [RFC8499] 242 TLS: - see [RFC8446] 244 SUDN: Special-Use Domain Names - see [RFC6761] 246 3. Key Issues and Questions 248 3.1. Signaling Support for ADoT 250 [RFC8310] does not define a method for a nameserver to advertise its 251 support of DoT other than to have the client make a connection 252 attempt to the default port of 853. The extra round-trip to check 253 for ADoT support imposes a penalty for clients and resolvers that 254 either do not remember the nameserver or have not communicated with 255 that nameserver before. The extra round-trip required may lead some 256 implementers down a similar path to happy eyeballs [RFC8305] which, 257 in the case of DNS, would send the same query over both encrypted and 258 un-encrypted channels at the same time. A happy eyeballs type 259 approach, which we'll call "leaky resolvers", would defeat the 260 purpose of the encryption protection for the testing query, but may 261 enable subsequent queries to be sent over a private channel with the 262 first query being subject to on-path adversaries. An implementation 263 could use some constant query string as a test query. However any 264 query included in the set of queries comprising the iterative 265 resolution for a QNAME first sent over an encrypted channel that 266 leaks the original stub QNAME, SHOULD NOT be used. 268 3.2. Port number 270 [RFC7858] section 3 [3] indicates that port 853 MUST be used for 271 session establishment unless otherwise negotiated and configured by 272 both the client and server. In the stub-to-recursive connection, 273 changing the port is something that can be done at stub configuration 274 time however, managing this negotiation between the recursive-to- 275 authoritative server is not scalable or standardized. The 276 scalability problem is due to the fact that recursive resolvers 277 communicate with thousands of authoritative servers, therefore port/ 278 service discovery for each of these authoritatives becomes difficult. 280 Static use of a pre-defined port provides on-path adversaries the 281 ability to more easily drop or manipulate traffic intended for that 282 port, possibly triggering resolvers to downgrade a connection back to 283 a traditional DNS query, eliminating the encryption protections. 284 This attack is more likely to happen on the stub-to-recursive 285 connection but is also a possible threat for recursive-to- 286 authoritative connections. 288 3.3. TLS version 290 Implementers of ADoT should read, understand, and follow the guidance 291 provided in BCP195 [4], also known as [RFC7525], when deploying DoT 292 on their platforms. At the time of writing, [RFC7525] did not 293 include coverage for TLS 1.3. However, TLS 1.3 should be included in 294 the document that obsoletes this BCP. Until this happens, TLS 1.3 295 SHOULD be preferred over TLS 1.2, as 1.3 offers both security and 296 performance enhancements. Additionally, operators should monitor TLS 297 version issues and cipher suite vulnerabilities for the version of 298 TLS that their platforms offer. 300 In the absence of any widespread ADoT deployments, it is easier to 301 limit TLS version 1.3 or greater. The absence of widespread adoption 302 also allows the IETF to create and enforce standards/policies that 303 ensure TLS versions are kept current going forward. 305 3.4. Resumptions 307 TLS resumption allows clients and servers to use information from a 308 previously established session in order to bootstrap the 309 cryptographic state while avoiding a full handshake. The resumption 310 mechanism is redesigned in TLS 1.3 [RFC8446] section 2.2 [5] and 311 section 2.3 [6], eliminating both [RFC5077] session tickets and 312 session ID resumption. 314 Resumption improves both connection and resource (socket and CPU) 315 efficiency, therefore operators SHOULD allow for TLS resumption. 316 However, special consideration should be given to 0-RTT resumption as 317 it is vulnerable to replay attacks [RFC3552] see Section 3.3.1 [7]. 318 The replay attack may not be as important for DNS, as DNS queries are 319 generally idempotent. However consideration should be given to 320 possible side-channel attacks [8]. 322 3.5. Operational Monitoring 324 Many operators use external passive monitors in order to understand 325 the health and performance of their infrastructure. Infrastructure 326 monitoring is also often done to retain a copy of traffic for 327 forensic purposes - such as the BIND "packet of death" [9] scenario. 328 These legacy monitoring systems may break with the use of TLS 1.3. 329 Therefore alternatives may need to be deployed/developed in order to 330 maintain effective operational performance and security monitoring 331 functionality. 333 A number of solutions have been suggested: 335 o Data Center use of Static Diffie-Hellman in TLS 1.3 336 [I-D.draft-green-tls-static-dh-in-tls13-01] 338 o TLS Security and Data Center Monitoring: Searching for a Path 339 Forward [10] 341 o TLS 1.3: Will Your Network Monitoring Go Blind? [11] 343 3.6. Architecture 345 Operators often reconfigure their architectural designs to best 346 deliver a new product offering or service. Operators should consider 347 the following design alternatives for the new ADoT service: 349 o Operators should consider segregating ADoT addresses from 350 traditional DNS over UDP/TCP to enable better attack mitigation, 351 better service monitoring, less service interference, and more 352 stability. 354 o Operators should weigh the pros/cons of using a TLS proxy vs 355 direct client-to-host connection. In case of ADoT, the client is 356 most likely a recursive resolver and the host is the authoritative 357 host server. 359 3.7. Socket efficiency/tuning considerations 361 Operators can realize substantial gains in client session 362 establishment and improve overall RTT by tuning sockets setting for 363 best use-case efficiency. 365 For the ADoT use case, operators should consult [RFC7766] section 6.2 366 [12] and minimally consider the following: 368 o Optimal number of persistent connections - consideration should be 369 given to the number of persistent connections maintained for both 370 the recursive resolvers and authoritative servers 372 o Optimal read/write buffer size 374 o Optimal session timeout 376 o Optimal close wait state time 378 o Optimal connection time/timeout 380 3.8. Post-Quantum Security 382 Given that ADoT deployments will likely have a long lifetime and are 383 being introduced in an era where post-quantum security is now an 384 important design consideration, it is prudent to consider how 385 protections against quantum computers might be integrated into the 386 deployments. 388 [I-D.draft-hoffman-c2pq-05] outlines the threat quantum computing 389 presents to classical cryptographic algorithms. 391 External Pre-Shared Keys (EPSKs) may be less vulnerable to quantum 392 attacks. A proposed approach to combining EPSKs and certificates in 393 TLS is described in 394 [I-D.draft-housley-tls-tls13-cert-with-extern-psk-03]. 396 4. Suggestions for further research and development 398 4.1. Required studies and analysis 400 Unlike stub-to-recursive DNS communication, authoritative nameservers 401 affect users in ways that end users cannot avoid or work around. In 402 the event that all authoritative servers for a zone are unreachable, 403 the zone becomes globally unavailable. Hence, in order to preserve 404 stability and resiliency of authoritative nameservers when deploying 405 ADoT, more empirical studies and analysis MUST be conducted. The 406 following list is a minimal set of studies and considerations that 407 need to be conducted/addressed in order to maintain authoritative 408 stability and resilience. 410 o Attack vectors and mitigation: consider the new adversarial powers 411 enabled by ADoT - types of attacks and denial of service, or other 412 security challenges that are created with the addition of ADoT to 413 authoritative nameservers. 415 o Traffic: consider how traffic patterns to authoritative 416 nameservers change with the introduction of ADoT and how these 417 traffic patterns change when the parameters of the service are 418 changed; e.g. persistent connection lifetime, TLS connection 419 parameters, use of TLS session tickets [RFC5077] or Pre-Shared Key 420 extension in TLS 1.3 [RFC8446] section 2.2 [13]. Consider how 421 these traffic pattern changes will affect the architecture and 422 infrastructure for authoritative operators. 424 o ADoT capacity and footprint expansion: consider how common scaling 425 techniques impact authoritative operators; e.g. anycast, load 426 balancing, custom hardware. 428 o DTLS/UDP - consider if there is any reason to implement DTLS given 429 that we lose the benefit of pipelining requests and must drop back 430 to TLS/TCP in the case of fragmentation. 432 It is critical to conduct large-scale measurements of DNS 433 infrastructure in order to quantify some of the scalability issues. 434 While these tests may be performed initially in a controlled lab 435 environment, the public Internet is fundamentally more variable. 436 Therefore, global testing at scale on the Internet MUST also be 437 conducted in order to understand and measure potential issues which 438 must be overcome before full global deployment can occur. 440 4.2. Authoritative DNS over TLS (ADoT) Profile 442 Profiles can be used as a mechanism to help mitigate operational 443 concerns over increased attack surface by restricting features such 444 as computationally expensive processes, insecure ciphers, general 445 starvation vectors, or other features that may limit operational 446 performance. 448 Therefore, an ADoT application profile draft, taking into account the 449 conclusions of required studies and analysis, may help assuage some 450 of the concerns raised in this document. 452 5. Security Considerations 454 In addition to the applicable security considerations described in 455 RFCs [RFC7626] and [RFC8310], considerations focused on future 456 deployment of quantum computers are described in Post-Quantum 457 Security (Section 3.8). Additional considerations associated with 458 ADoT are TBD based on working group discussions. 460 6. References 462 6.1. Informative References 464 [I-D.draft-green-tls-static-dh-in-tls13-01] 465 Green, M., Droms, R., Housley, R., Turner, P., and S. 466 Fenter, "Data Center use of Static Diffie-Hellman in TLS 467 1.3", draft-green-tls-static-dh-in-tls13-01 (work in 468 progress), July 2017. 470 [I-D.draft-hoffman-c2pq-05] 471 Hoffman, P., "The Transition from Classical to Post- 472 Quantum Cryptography", draft-hoffman-c2pq-05 (work in 473 progress), May 2019. 475 [I-D.draft-housley-tls-tls13-cert-with-extern-psk-03] 476 Housley, R., "TLS 1.3 Extension for Certificate-based 477 Authentication with an External Pre-Shared Key", draft- 478 housley-tls-tls13-cert-with-extern-psk-03 (work in 479 progress), November 2018. 481 [I-D.draft-wood-tls-external-psk-importer-00] 482 Wood, C., "Importing External PSKs for TLS 1.3", draft- 483 wood-tls-external-psk-importer-00 (work in progress), 484 October 2018. 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 492 Text on Security Considerations", BCP 72, RFC 3552, 493 DOI 10.17487/RFC3552, July 2003, 494 . 496 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 497 "Transport Layer Security (TLS) Session Resumption without 498 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 499 January 2008, . 501 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 502 RFC 6761, DOI 10.17487/RFC6761, February 2013, 503 . 505 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 506 "Recommendations for Secure Use of Transport Layer 507 Security (TLS) and Datagram Transport Layer Security 508 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 509 2015, . 511 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 512 DOI 10.17487/RFC7626, August 2015, 513 . 515 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 516 D. Wessels, "DNS Transport over TCP - Implementation 517 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 518 . 520 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 521 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 522 . 524 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 525 and P. Hoffman, "Specification for DNS over Transport 526 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 527 2016, . 529 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 530 Kumari, "Client Subnet in DNS Queries", RFC 7871, 531 DOI 10.17487/RFC7871, May 2016, 532 . 534 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 535 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 536 May 2017, . 538 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 539 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 540 July 2017, . 542 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 543 Better Connectivity Using Concurrency", RFC 8305, 544 DOI 10.17487/RFC8305, December 2017, 545 . 547 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 548 for DNS over TLS and DNS over DTLS", RFC 8310, 549 DOI 10.17487/RFC8310, March 2018, 550 . 552 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 553 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 554 . 556 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 557 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 558 January 2019, . 560 6.2. URIs 562 [1] https://wiki.mozilla.org/Security/DOH-resolver- 563 policy#Privacy_Requirements 565 [2] https://tools.ietf.org/html/rfc7871#section-12.1 567 [3] https://tools.ietf.org/html/rfc7858#section-3 569 [4] https://tools.ietf.org/html/bcp195 571 [5] https://tools.ietf.org/html/rfc8446#section-2.2 573 [6] https://tools.ietf.org/html/rfc8446#section-2.3 575 [7] https://tools.ietf.org/html/rfc3552#section-3.3.1 577 [8] https://eprint.iacr.org/2005/388.pdf 579 [9] https://www.nominet.uk/the-packet-of-death/ 581 [10] https://www.rsa.com/en-us/blog/2017-08/tls-security-and-data- 582 center-monitoring-searching-for-a-path-forward 584 [11] https://www.extrahop.com/company/blog/2018/maintain-visibility- 585 with-tls-1.3/ 587 [12] https://tools.ietf.org/html/rfc7766#section-6.2 589 [13] https://tools.ietf.org/html/rfc8446#section-2.2 591 Appendix A. Acknowledgements 593 Thanks to those that provided usage data, reviewed and/or improved 594 this document, including: Piet Barber, Michael Bentkofsky, David 595 Blacka, Florent Guiliani, Scott Hollenbeck, Burt Kaliski, Glen Wiley, 596 and Richard Wilhelm. 598 Appendix B. Change Log 600 RFC EDITOR: PLEASE REMOVE THE THIS SECTION PRIOR TO PUBLICATION. 602 TODO: Zero this change log out when -00 is submitted to IETF. 604 pre-00 606 o Initial draft. 608 ~~~ 01234567890123456789012345678901234567890123456789012345678901234 609 5678912 611 Authors' Addresses 613 Karl Henderson 614 Verisign 616 Email: khenderson@verisign.com 618 Tim April 619 Akamai 621 Email: ietf@tapril.net 623 Jason Livingood 624 Comcast 626 Email: jason_livingood@comcast.com