idnits 2.17.1 draft-pauly-dprive-adaptive-dns-privacy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 04, 2019) is 1665 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) == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-07 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-04 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') ** Downref: Normative reference to an Experimental draft: draft-pauly-dprive-oblivious-doh (ref. 'I-D.pauly-dprive-oblivious-doh') ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-04 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft T. Pauly 4 Intended status: Standards Track C. Wood 5 Expires: April 6, 2020 Apple Inc. 6 P. McManus 7 Fastly 8 October 04, 2019 10 Adaptive DNS: Improving Privacy of Name Resolution 11 draft-pauly-dprive-adaptive-dns-privacy-00 13 Abstract 15 This document defines an architecture that allows clients to 16 dynamically discover designated resolvers that offer encrypted DNS 17 services, and use them in an adaptive way that improves privacy while 18 co-existing with locally provisioned resolvers. These resolvers can 19 be used directly when looking up names for which they are designated. 20 These resolvers also provide the ability to proxy encrypted queries, 21 thus hiding the identity of the client requesting resolution. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 6, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Discovering Designated DoH Servers . . . . . . . . . . . 6 62 3.1.1. Whitelisting Designated DoH Servers . . . . . . . . . 7 63 3.1.2. Accessing Extended Information . . . . . . . . . . . 8 64 3.2. Discovering Local Resolvers . . . . . . . . . . . . . . . 9 65 3.3. Hostname Resolution Algorithm . . . . . . . . . . . . . . 10 66 3.4. Oblivious Resolution . . . . . . . . . . . . . . . . . . 11 67 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 68 4.1. Provide a DoH Server . . . . . . . . . . . . . . . . . . 12 69 4.1.1. Oblivious DoH Proxy . . . . . . . . . . . . . . . . . 12 70 4.1.2. Oblivious DoH Target . . . . . . . . . . . . . . . . 12 71 4.1.3. Keying Material . . . . . . . . . . . . . . . . . . . 12 72 4.2. Advertise the DoH Server . . . . . . . . . . . . . . . . 12 73 4.3. Provide Extended Configuration as a Web PvD . . . . . . . 13 74 5. Server Deployment Considerations . . . . . . . . . . . . . . 14 75 5.1. Single Content Provider . . . . . . . . . . . . . . . . . 14 76 5.2. Multiple Content Providers . . . . . . . . . . . . . . . 15 77 5.3. Avoid Narrow Deployments . . . . . . . . . . . . . . . . 15 78 6. Local Resolver Deployment Considerations . . . . . . . . . . 16 79 6.1. Designating Local DoH Servers . . . . . . . . . . . . . . 16 80 6.2. Local Use Cases . . . . . . . . . . . . . . . . . . . . . 16 81 6.2.1. Accessing Local-Only Resolvable Content . . . . . . . 17 82 6.2.2. Accessing Locally Optimized Content . . . . . . . . . 18 83 6.2.3. Walled-Garden and Captive Network Deployments . . . . 18 84 6.2.4. Network-Based Filtering . . . . . . . . . . . . . . . 19 85 7. Performance Considerations . . . . . . . . . . . . . . . . . 19 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 10.1. DoH Template PvD Key . . . . . . . . . . . . . . . . . . 21 90 10.2. DNS Filtering PvD Keys . . . . . . . . . . . . . . . . . 21 91 10.3. DoH URI Template DNS Parameter . . . . . . . . . . . . . 22 92 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 95 12.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 When clients need to resolve names into addresses in order to 101 establish networking connections, they traditionally use by default 102 the DNS resolver that is provisioned by the local network along with 103 their IP address [RFC2132] [RFC8106]. Alternatively, they can use a 104 resolver indicated by a tunneling service such as a VPN. 106 However, privacy-sensitive clients might prefer to use an encrypted 107 DNS service other than the one locally provisioned in order to 108 prevent interception, profiling, or modification by entities other 109 than the operator of the name service for the name being resolved. 110 Protocols that can improve the transport security of a client when 111 using DNS or creating TLS connections include DNS-over-TLS [RFC7858], 112 DNS-over-HTTPS [RFC8484], and encrypted Server Name Indication (ESNI) 113 [I-D.ietf-tls-esni]. 115 There are several concerns around a client using such privacy- 116 enhancing mechanisms for generic system traffic. A remote service 117 that provides encrypted DNS may not provide correct answers for 118 locally available resources, or private resources (such as domains 119 only accessible over a private network). Remote services may also be 120 untrusted from a privacy perspective: while encryption will prevent 121 on-path observers from seeing hostnames, client systems need to trust 122 the encrypted DNS service to not store or misuse queries made to it. 123 Further, extensive use of cloud based recursive resolvers obscures 124 the network location of the client which may degrade the performance 125 of the returned server due to lack of proximity at the benefit of 126 improved privacy. 128 Client systems are left with choosing between one of the following 129 stances: 131 1. Send all application DNS queries to a particular encrypted DNS 132 service, which requires establishing user trust of the service. 133 This can lead to resolution failures for local or private 134 enterprise domains absent heuristics or other workarounds for 135 detecting managed networks. 137 2. Allow the user or another entity to configure local policy for 138 which domains to send to local, private, or encrypted resolvers. 139 This provides more granularity at the cost of increasing user 140 burden. 142 3. Only use locally-provisioned resolvers, and opportunistically use 143 encrypted DNS to these resolvers when possible. (Clients may 144 learn of encrypted transport support by actively probing such 145 resolvers.) This provides marginal benefit over not using 146 encrypted DNS at all, especially if clients have no means of 147 authenticating or trusting local resolvers. 149 This document defines an architecture that allows clients to improve 150 the privacy of their DNS queries without requiring user intervention, 151 and allowing coexistence with local, private, and enterprise 152 resolvers. 154 This architecture is composed of several mechanisms: 156 o A DNS record that indicates a designated DoH server associated 157 with a name (Section 3.1); 159 o an extension to DoH that allows client IP addresses to be 160 disassociated from queries via proxying 161 ([I-D.pauly-dprive-oblivious-doh]); 163 o a DoH server that responds to queries directly and supports 164 proxying (Section 4); 166 o and client behavior rules for how to resolve names using a 167 combination of designated DoH resolvers, proxied queries, and 168 local resolvers (Section 3). 170 1.1. Specification of Requirements 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 2. Terminology 180 This document defines the following terms: 182 Adaptive DNS: Adaptive DNS is a technique to provide an encrypted 183 transport for DNS queries that can be sent directly to a 184 Designated DoH Server, to use Oblivious DoH to hide the client IP 185 address, or to use Direct Resolvers when required or appropriate. 187 Designated DoH Server: A DNS resolver that provides connectivity 188 over HTTPS (DoH) that is designated as a responsible resolver for 189 a given domain or zone. 191 Direct Resolver: A DNS resolver using any transport that is 192 provisioned directly by a local router or a VPN. 194 Exclusive Direct Resolver: A Direct Resolver that requires the 195 client to use it exclusively for a given set of domains, such as 196 private domains managed by a VPN. This status is governed by 197 local system policy. 199 Oblivious DoH: A technique that uses multiple DoH servers to proxy 200 queries in a way that disassociates the client's IP address from 201 query content. 203 Oblivious Proxy: A resolution server that proxies encrypted client 204 DNS queries to another resolution server that will be able to 205 decrypt the query (the Oblivious Target). 207 Oblivious Target: A resolution server that receives encrypted client 208 DNS queries via an Oblivious Proxy. 210 Privacy-Sensitive Connections: Connections made by clients that are 211 explicitly Privacy-Sensitive are treated differently from 212 connections made for generic system behavior, such as non-user- 213 initiated maintenance connections. This distinction is only 214 relevant on the client, and does not get communicated to other 215 network entities. Certain applications, such as browsers, can 216 choose to treat all connections as privacy-sensitive. 218 Web PvD: A Web Provisioning Domain, or Web PvD, represents the 219 configuration of resolvers, proxies, and other information that a 220 server deployment makes available to clients. See Section 4.3. 222 3. Client Behavior 224 Adaptive DNS allows client systems and applications to improve the 225 privacy of their DNS queries and connections, both by requiring 226 confidentiality via encryption, and by limiting the ability to 227 correlate client IP addresses with query contents. Specifically, the 228 goal for client queries is to achieve the following properties: 230 1. No party other than the client and server can learn or control 231 the names being queried by the client or the answers being 232 returned by the server. 234 2. Only a designated DNS resolver associated with the deployment 235 that is also hosting content will be able to read both the client 236 IP address and queried names for Privacy-Sensitive Connections. 237 For example, a resolver owned and operated by the same provider 238 that hosts "example.com" would be able to link queries for 239 "example.com" to specific clients (by their IP address), since 240 the server ultimately has this capability once clients 241 subsequently establish secure (e.g., TLS) connections to an 242 address to which "example.com" resolves. 244 3. Clients will be able to comply with policies required by VPNs and 245 local networks that are authoritative for private domains. 247 An algorithm for determining how to resolve a given name in a manner 248 that satisfies these properties is described in Section 3.3. Note 249 that this algorithm does not guarantee that responses that are not 250 signed with DNSSEC are valid, and clients that establish connections 251 to unsigned addresses may still expose their local IP addresses to 252 attackers that control their terminal resolver even if hidden during 253 resolution. 255 3.1. Discovering Designated DoH Servers 257 All direct (non-oblivious) queries for names in privacy-sensitive 258 connections MUST be sent to a server that both provides encryption 259 and is designated for the domain. 261 Clients dynamically build and maintain a set of known Designated DoH 262 Servers. The information that is associated with each server is: 264 o The URI Template of the DoH server [RFC8484] 266 o The public HPKE [I-D.irtf-cfrg-hpke] key of the DoH server used 267 for proxied oblivious queries [I-D.pauly-dprive-oblivious-doh] 269 o A list of domains for which the DoH server is designated 271 This information can be retrieved from several different sources. 272 The primary source for discovering Designated DoH Server 273 configurations is from properties stored in a SVCB (or a SVCB- 274 conformant type like HTTPSSVC) DNS Record 275 [I-D.nygren-dnsop-svcb-httpssvc]. This record provides the URI 276 Template and the public Oblivious DoH key of a DoH server that is 277 designated for a specific domain. A specific domain may have more 278 than one such record. 280 In order to designate a DoH server for a domain, a SVCB record can 281 contain the "dohuri", which has a SvcParamKey value of 4. The value 282 stored in the parameter is a URI, which is the DoH URI template 283 [RFC8484]. 285 The public key of the DoH server is sent as the "odohkey", which has 286 a SvcParamKey value of 5 [I-D.pauly-dprive-oblivious-doh]. 288 The following example shows a record containing a DoH URI, as 289 returned by a query for the HTTPSSVC variant of the SVCB record type 290 on "example.com". 292 example.com. 7200 IN HTTPSSVC 0 svc.example.net. 293 svc.example.net. 7200 IN HTTPSSVC 2 svc1.example.net. ( 294 dohuri=https://doh.example.net/dns-query 295 odohkey="..." ) 297 Clients MUST ignore any DoH server URI that was not retrieved from a 298 DNSSEC-signed record that was validated by the client [RFC4033]. 300 Whenever a client resolves a name for which it does not already have 301 a Designated DoH Server, it SHOULD try to determine the Designated 302 DoH Server by sending a query for the an SVCB record for the name. 303 If there is no DoH server designated for the name or zone, signaled 304 either by an NXDOMAIN answer or a SVCB record that does not contain a 305 DoH URI, the client SHOULD suppress queries for the SVCB record for a 306 given name until the time-to-live of the answer expires. 308 In order to bootstrap discovery of Designated DoH Servers, client 309 systems SHOULD have some saved list of at least two names that they 310 use consistently to perform SVCB record queries on the Direct 311 Resolvers configured by the local network. Since these queries are 312 likely not private, they SHOULD NOT be associated with user action or 313 contain user-identifying content. Rather, the expectation is that 314 all client systems of the same version and configuration would issue 315 the same bootstrapping queries when joining a network for the first 316 time when the list of Designated DoH Servers is empty. 318 3.1.1. Whitelisting Designated DoH Servers 320 Prior to using a Designated DoH Server for direct name queries on 321 privacy-sensitive connections, clients MUST whitelist the server. 323 The requirements for whitelisting are: 325 o Support for acting as an Oblivious Proxy. Each Designated DoH 326 Server is expected to support acting as a proxy for Oblivious DoH. 327 A client MUST issue at least one query that is proxied through the 328 server before sending direct queries to the server. 330 o Support for acting as an Oblivious Target. Each Designated DoH 331 Server is expected to support acting as a target for Oblivious 332 DoH. A client MUST issue at least one query that is targeted at 333 the server through a proxy before sending direct queries to the 334 server. 336 Designated DoH Servers are expected to act both as Oblivious Proxies 337 and as Oblivious Targets to ensure that clients have sufficient 338 options for preserving privacy using Oblivious DoH. Oblivious 339 Targets are expected to act as Oblivious Proxies to ensure that no 340 Oblivious DoH server can act as only a target (thus being able to see 341 patterns in name resolution, which might have value to a resolver) 342 and require other servers to take on a disproportionate load of 343 proxying. 345 Clients MAY further choose to restrict the whitelist by other local 346 policy. For example, a client system can have a list of trusted 347 resolver configurations, and it can limit the whitelist of Designated 348 DoH Servers to configurations that match this list. Alternatively, a 349 client system can check a server against a list of audited and 350 approved DoH Servers that have properties that the client approves. 352 Clients SHOULD NOT whitelist authority mappings for effective top- 353 level domains (eTLDs), such as ".com". 355 If a client detects at any point after whitelisting a DoH server that 356 the server no longer meets the criteria for whitelisting, such as 357 consistently failing to proxy or receive Oblivious DoH queries, the 358 client SHOULD remove the DoH server from its whitelist. 360 3.1.2. Accessing Extended Information 362 When a Designated DoH Server is discovered, clients SHOULD also check 363 to see if this server provides an extended configuration in the form 364 of a Web PvD (Section 4.3). To do this, the client performs a GET 365 request to the DoH URI, indicating that it accepts a media type of 366 "application/pvd+json" [I-D.ietf-intarea-provisioning-domains]. When 367 requesting the PvD information, the query and fragment components of 368 the requested path are left empty. Note that this is different from 369 a GET request for the "application/dns-message" type, in which the 370 query variable "dns" contains an encoded version of a DNS message. 372 In response, the server will return the JSON content for the PvD, if 373 present. The content-type MUST be "application/pvd+json". 375 The following exchange shows an example of a client retrieving a Web 376 PvD configuration for a DoH server with the URI Template 377 "https://dnsserver.example.net/dns-query". 379 The client sends: 381 :method = GET 382 :scheme = https 383 :authority = dnsserver.example.net 384 :path = /dns-query 385 accept = application/pvd+json 387 And the server replies: 389 :status = 200 390 content-type = application/pvd+json 391 content-length = 175 392 cache-control = max-age=86400 394 396 If the server does not support retrieving any extended PvD 397 information, it MUST reply with HTTP status code 415 (Unsupported 398 Media Type, [RFC7231]). 400 If the retrieved JSON contains a "dnsZones" array 401 [I-D.ietf-intarea-provisioning-domains], the client SHOULD perform an 402 SVCB record lookup of each of the listed zones on the DoH server and 403 validate that the DoH server is a designated server for the domain; 404 and if it is, add the domain to the local configuration. 406 3.2. Discovering Local Resolvers 408 If the local network provides configuration with an Explicit 409 Provisioning Domain (PvD), as defined by 410 [I-D.ietf-intarea-provisioning-domains], clients can learn about 411 domains for which the local network's resolver is authoritative. 413 If an RA provided by the router on the network defines an Explicit 414 PvD that has additional information, and this additional information 415 JSON dictionary contains the key "dohTemplate" (Section 10), then the 416 client SHOULD add this DoH server to its list of known DoH 417 configurations. The domains that the DoH server claims authority for 418 are listed in the "dnsZones" key. Clients MUST use an SVCB record 419 from the locally-provisioned DoH server and validate the answer with 420 DNSSEC [RFC4033] before creating a mapping from the domain to the 421 server. Once this has been validated, clients can use this server 422 for resolution as described in step 2 of Section 3.3. 424 See Section 6 for local deployment considerations. 426 3.3. Hostname Resolution Algorithm 428 When establishing a secure connection to a certain hostname, clients 429 need to first determine which resolver configuration ought to be used 430 for DNS resolution. 432 Several of the steps outlined in this algorithm take into account the 433 success or failure of name resolution. Failure can be indicated 434 either by a DNS response, such as SERVFAIL or NXDOMAIN, or by a 435 connection-level failure, such as a TCP reset, TLS handshake failure, 436 or an HTTP response error status. In effect, any unsuccessful 437 attempt to resolve a name can cause the client to try another 438 resolver if permitted by the algorithm. This is particularly useful 439 for cases in which a name may not be resolvable over public DNS but 440 has a valid answer only on the local network. 442 Given a specific hostname, the order of preference for which resolver 443 to use SHOULD be: 445 1. An Exclusive Direct Resolver, such as a resolver provisioned by a 446 VPN, with domain rules that include the hostname being resolved. 447 If the resolution fails, the connection will fail. See 448 Section 3.2 and Section 6. 450 2. A Direct Resolver, such as a local router, with domain rules that 451 are known to be authoritative for the domain containing the 452 hostname. If the resolution fails, the connection will try the 453 next resolver configuration based on this list. 455 3. The most specific Designated DoH Server that has been whitelisted 456 (Section 3.1.1) for the domain containing the hostname, i.e., the 457 designated DoH server which is associated with the longest 458 matching prefix of the hostname. For example, given two 459 Designated DoH Servers, one for foo.example.com and another 460 example.com, clients connecting to bar.foo.example.com should use 461 the former. If the resolution fails, the connection will try an 462 Oblivious DoH query. 464 4. Oblivious DoH queries using multiple DoH Servers 465 ([I-D.pauly-dprive-oblivious-doh]). If this resolution fails, 466 Privacy-Sensitive Connections will fail. All other connections 467 will use the last resort, the default Direct Resolvers. 469 5. The default Direct Resolver, generally the resolver provisioned 470 by the local router, is used as the last resort for any 471 connection that is not explicitly Privacy-Sensitive [RFC2132] 472 [RFC8106]. 474 If the system allows the user to specify a preferred encrypted 475 resolver, such as allowing the user to manually configure a DoH 476 server URI to use by default, the use of this resolver SHOULD come 477 between steps 2 and 3. This ensures that VPN-managed and locally- 478 accessible names remain accessible while all other names are resolved 479 using the user preference. 481 3.4. Oblivious Resolution 483 For all privacy-sensitive connection queries for names that do not 484 correspond to a Designated DoH Server, the client SHOULD use 485 Oblivious DoH to help conceal its IP address from eavesdroppers and 486 untrusted resolvers. 488 Disassociation of client IPs from query content is achieved by using 489 Oblivious DoH [I-D.pauly-dprive-oblivious-doh]. This extension to 490 DoH allows a client to encrypt a query with a target DoH server's 491 public key, and proxy the query through another server. The query is 492 packaged with a unique client-defined symmetric key that is used to 493 sign the DNS answer, which is sent back to the client via the proxy. 495 All DoH Servers that are used as Designated DoH Servers by the client 496 MUST support being both an Oblivious Proxy and an Oblivious Target, 497 as described in the server requirements (Section 4). 499 Since each Designated DoH Server can act as one of two roles in an 500 proxied exchange, there are (N) * (N - 1) / 2 possible pairs of 501 servers, where N is the number of whitelisted servers. While clients 502 SHOULD use a variety of server pairs in rotation to decrease the 503 ability for any given server to track client queries, it is not 504 expected that all possible combinations will be used. Some 505 combinations will be able to handle more load than others, and some 506 will have better latency properties than others. To optimize 507 performance, clients SHOULD maintain statistics to track the 508 performance characteristics and success rates of particular pairs. 510 Clients that are performing Oblivious DoH resolution SHOULD fall back 511 to another pair of servers if a first query times out, with a 512 locally-determined limit for the number of fallback attempts that 513 will be performed. 515 4. Server Requirements 517 Any server deployment that provides a set of services within one or 518 more domains, such as a CDN, can run a server node that allows 519 clients to run Adaptive DNS. A new server node can be added at any 520 time, and can be used once it is advertised to clients and can be 521 validated and whitelisted. The system overall is intended to scale 522 and provide improved performance as more nodes become available. 524 The basic requirements to participate as a server node in this 525 architecture are described below. 527 4.1. Provide a DoH Server 529 Each server node is primarily defined by a DoH server [RFC8484] that 530 is designated for a set of domains, and also provides Oblivious DoH 531 functionality. As such, the DoH servers MUST be able to act as 532 recursive resolvers that accept queries for records and domains 533 beyond those for which the servers are specifically designated. 535 4.1.1. Oblivious DoH Proxy 537 The DoH servers MUST be able to act as Oblivious Proxies. In this 538 function, they will proxy encrypted queries and answers between 539 clients and Oblivious Target DoH servers. 541 4.1.2. Oblivious DoH Target 543 The DoH servers MUST be able to act as Oblivious Targets. In this 544 function, they will accept encrypted proxied queries from clients via 545 Oblivious Proxy DoH servers, and provide encrypted answers using 546 client keys. 548 4.1.3. Keying Material 550 In order to support acting as an Oblivious Target, a DoH server needs 551 to provide a public HPKE [I-D.irtf-cfrg-hpke] key that can be used to 552 encrypt client queries. This key is advertised in the SVCB record 553 [I-D.pauly-dprive-oblivious-doh]. 555 DoH servers also SHOULD provide an ESNI [I-D.ietf-tls-esni] key to 556 encrypt the Server Name Indication field in TLS handshakes to the DoH 557 server. 559 4.2. Advertise the DoH Server 561 The primary mechanism for advertising a Designated DoH Server is a 562 SVCB DNS record (Section 3.1). This record MUST contain both the URI 563 Template of the DoH Server as well as the Oblivious DoH Public Key. 564 It MAY contain the ESNI key [I-D.ietf-tls-esni]. 566 Servers MUST ensure that any SVCB records are signed with DNSSEC 567 [RFC4033]. 569 4.3. Provide Extended Configuration as a Web PvD 571 Beyond providing basic DoH server functionality, server nodes SHOULD 572 provide a mechanism that allows clients to look up properties and 573 configuration for the server deployment. Amongst other information, 574 this configuration can optionally contain a list of some popular 575 domains for which this server is designated. Clients can use this 576 list to optimize lookups for common names. 578 This set of extended configuration information is referred to as a 579 Web Provisioning Domain, or a Web PvD. Provisioning Domains are sets 580 of consistent information that clients can use to access networks, 581 including rules for resolution and proxying. Generally, these PvDs 582 are provisioned directly, such as by a local router or a VPN. 583 [I-D.ietf-intarea-provisioning-domains] defines an extensible 584 configuration dictionary that can be used to add information to local 585 PvD configurations. Web PvDs share the same JSON configuration 586 format, and share the registry of keys defined as "Additional 587 Information PvD Keys". 589 If present, the PvD JSON configuration MUST be made available to 590 clients that request the "application/pvd+json" media type in a GET 591 request to the DoH server's URI 592 [I-D.ietf-intarea-provisioning-domains]. Clients MUST include this 593 media type as an Accept header in their GET requests, and servers 594 MUST mark this media type as their Content-Type header in responses. 595 If the PvD JSON format is not supported, the server MUST reply with 596 HTTP status code 415 [RFC7231]. 598 The "identifier" key in the JSON configuration SHOULD be the hostname 599 of the DoH Server itself. 601 For Web PvDs, the "prefixes" key within the JSON configuration SHOULD 602 contain an empty array. 604 The key "dnsZones", which contains an array of domains as strings 605 [I-D.ietf-intarea-provisioning-domains], indicates the zones that 606 belong to the PvD. Any zone that is listed in this array for a Web 607 PvD MUST have a corresponding SVCB record that defines the DoH server 608 as designated for the zone. Servers SHOULD include in this array any 609 names that are considered default or well-known for the deployment, 610 but is not required or expected to list all zones or domains for 611 which it is designated. The trade-off here is that zones that are 612 listed can be fetched and validated automatically by clients, thus 613 removing a bootstrapping step in discovering mappings from domains to 614 Designated DoH Servers. 616 Clients that retrieve the Web PvD JSON dictionary SHOULD perform an 617 SVCB record query for each of the entries in the "dnsZones" array in 618 order to populate the mappings of domains. These MAY be performed in 619 an oblivious fashion, but MAY also be queried directly on the DoH 620 server (since the information is not user-specific, but in response 621 to generic server-driven content). Servers can choose to 622 preemptively transfer the relevant SVCB records if the PvD 623 information retrieval is done with an HTTP version that supports PUSH 624 semantics. This allows the server to avoid a round trip in zone 625 validation even before the client has started requested SVCB records. 626 Once the client requests an SVCB record for one of the names included 627 in the "dnsZones" array, the server can also include the SVCB records 628 for the other names in the array in the Additionals section of the 629 DNS response. 631 This document also registers one new key in the Additional 632 Information PvD Keys registry, to identify the URI Template for the 633 DoH server Section 10. When included in Web PvDs, this URI MUST 634 match the template in the SVCB DNS Record. 636 Beyond providing resolution configuration, the Web PvD configuration 637 can be extended to offer information about proxies and other services 638 offered by the server deployment. Such keys are not defined in this 639 document. 641 5. Server Deployment Considerations 643 When servers designate DoH servers for their names, the specific 644 deployment model can impact the effective privacy and performance 645 characteristics. 647 5.1. Single Content Provider 649 If a name always resolves to server IP addresses that are hosted by a 650 single content provider, the name ought to designate a single DoH 651 server. This DoH server will be most optimal when it is designated 652 by many or all names that are hosted by the same content provider. 653 This ensures that clients can increase connection reuse to reduce 654 latency in connection setup. 656 A DoH server that corresponds to the content provider that hosts 657 content has an opportunity to tune the responses provided to a client 658 based on the location inferred by the client IP address. 660 5.2. Multiple Content Providers 662 Some hostnames may resolve to server IP addresses that are hosted by 663 multiple content providers. In such scenarios, the deployment may 664 want to be able to control the percentage of traffic that flows to 665 each content provider. 667 In these scenarios, there can either be: 669 o multiple designated DoH servers that are advertised via SVCB DNS 670 Records; or, 672 o a single designated DoH server that can be referenced by one or 673 more SVCB DNS Records, operated by a party that is aware of both 674 content providers and can manage splitting the traffic. 676 If a server deployment wants to easily control the split of traffic 677 between different content providers, it ought to use the latter model 678 of using a single designated DoH server that can better control which 679 IP addresses are provided to clients. Otherwise, if a client is 680 aware of multiple DoH servers, it might use a single resolver 681 exclusively, which may lead to inconsistent behavior between clients 682 that choose different resolvers. 684 5.3. Avoid Narrow Deployments 686 Using designated DoH servers can improve the privacy of name 687 resolution whenever a DoH server is designated by many different 688 names within one or more domains. This limits the amount of 689 information leaked to an attacker observing traffic between a client 690 and a DoH server: the attacker only learns that the client might be 691 resolving one of the many names for which the server is designated 692 (or might be performing an Oblivious query). 694 However, if a deployment designates a given DoH server for only one 695 name, or a very small set of names, then it becomes easier for an 696 attacker to infer that a specific name is being accessed by a client. 697 For this reason, deployments are encouraged to avoid deploying a DoH 698 server that is only designated by a small number of names. Clients 699 can also choose to only whitelist DoH servers that are associated 700 with many names. 702 Beyond the benefits to privacy, having a larger number of names 703 designate a given DoH server improves the opportunity for DoH 704 connection reuse, which can improve the performance of name 705 resolutions. 707 6. Local Resolver Deployment Considerations 709 A key goal of Adaptive DNS is that clients will be able to use 710 Designated DoH Servers to improve the privacy of queries, without 711 entirely bypassing local network authority and policy. For example, 712 if a client is attached to an enterprise Wi-Fi network that provides 713 access and resolution for private names not generally accessible on 714 the Internet, such names will only be usable when a local resolver is 715 used. 717 In order to achieve this, a local network can advertise itself as 718 authoritative for a domain, allowing it to be used prior to external 719 servers in the client resolution algorithm Section 3.3. 721 6.1. Designating Local DoH Servers 723 If a local network wants to have clients send queries for a set of 724 private domains to its own resolver, it needs to define an explicit 725 provisioning domain [I-D.ietf-intarea-provisioning-domains]. The PvD 726 RA option SHOULD set the H-flag to indicate that Additional 727 Information is available. This Additional Information JSON object 728 SHOULD include both the "dohTemplate" and "dnsZones" keys to define 729 the local DoH server and the domains over which it claims authority. 731 In order to validate that a local resolver is designated for a given 732 zone, the client SHOULD issue a SVCB record query for the names 733 specified in the PvD information, using the DoH server specified in 734 the PvD information. If there is no SVCB record for a name that 735 points to the DoH server that can be validated using DNSSEC, the 736 client SHOULD NOT automatically create a designation from the domain 737 name to DoH server. See specific use cases in Section 6.2 for cases 738 in which a local resolver may still be used. 740 Although local Designated DoH Servers MAY support proxying Oblivious 741 DoH queries, a client SHOULD NOT select one of these servers as an 742 Oblivious Proxy. Doing so might reveal the client's location to the 743 Target based on the address of the proxy, which could contribute to 744 deanonymizing the client. Clients can make an exception to this 745 behavior if the DoH server designated by the local network is known 746 to be a non-local service, such as when a local network configures a 747 centralized public resolver to handle its DNS operations. 749 6.2. Local Use Cases 751 The various use cases for selecting locally-provisioned resolvers 752 require different approaches for deployment and client resolution. 753 The following list is not exhaustive, but provides guidance on how 754 these scenarios can be achieved using the Adaptive DNS algorithm. 756 6.2.1. Accessing Local-Only Resolvable Content 758 Some names are not resolvable using generic DNS resolvers, but 759 require using a DNS server that can resolve private names. This is 760 common in enterprise scenarios, in which an enterprise can have a set 761 of private names that it allows to be resolved when connected to a 762 VPN or an enterprise-managed Wi-Fi network. In this case, clients 763 that do not use the locally-provisioned resolver will fail to resolve 764 private names. 766 In these scenarios, the local network SHOULD designate a local DoH 767 server for the domains that are locally resolvable. For example, an 768 enterprise that owns "private.example.org" would advertise 769 "private.example.org" in its PvD information along with a DoH URI 770 template. Clients could then use that locally-configured resolver 771 with names under "private.example.org" according to the rules in 772 Section 6.1. 774 In general, clients SHOULD only create designated DoH server 775 associations when they can validate a SVCB record using DNSSEC. 776 However, some deployments of private names might not want to sign all 777 private names within a zone. There are thus a few possible 778 deployment models: 780 o "private.example.org" does have a DNSSEC-signed SVCB record that 781 points to the local DoH server. The client requests the SVCB 782 record for "private.example.org" using the local DoH server that 783 is specified in the PvD information, and from that point on uses 784 the local DoH server for names under "private.example.org". 786 o Instead of signing "private.example.org", the deployment provides 787 a DNSSEC-signed SVCB record for "example.org", thus steering all 788 resolution under "example.org" to the local resolver. 790 o No DNSSEC-signed SVCB record designates the local server. In this 791 case, clients have a hint that the local network can serve names 792 under "private.example.org", but do not have a way to validate the 793 designation. Clients can in this case try to resolve names using 794 external servers (such as via Oblivious DoH), and then MAY fall 795 back to using locally-provisioned resolvers if the names do not 796 resolve externally. This approach has the risk of exposing 797 private names to public resolvers, which can be undesirable for 798 certain enterprise deployments. Alternatively, if the client 799 trusts the local network based on specific policy configured on 800 the client, it can choose to resolve these names locally first. 801 Note that this approach risks exposing names to a potentially 802 malicious network that is masquerading as an authority for private 803 names if the network cannot be validated in some other manner. 805 Deployments SHOULD use the one of the first two approaches (signing 806 their records) whenever possible; the case of providing unsigned 807 names is only described as a possibility for handling legacy 808 enterprise deployments. Clients SHOULD choose to ignore any locally 809 designated names that are not signed unless there is a specific 810 policy configuration on the client. 812 6.2.2. Accessing Locally Optimized Content 814 Other names may be resolvable both publicly and on the local 815 resolver, but have more optimized servers that are accessible only 816 via the local network. For example, a Wi-Fi provider may provide 817 access to a cache of video content that provides lower latency than 818 publicly-accessible caches. 820 Names that are hosted locally in this way SHOULD use a designation 821 with a DNSSEC-signed SVCB record for the name. If a client discovers 822 that a local resolver is designated for a given name, the client 823 SHOULD prefer using connections to this locally-hosted content rather 824 than names resolved externally. 826 Note that having a DNSSEC-signed designation to the local resolver 827 provides a clear indication that the entity that manages a given name 828 has an explicit relationship with the local network provider. 830 6.2.3. Walled-Garden and Captive Network Deployments 832 Some networks do not provide any access to the general Internet, but 833 host local content that clients can access. For example, a network 834 on an airplane can give access to flight information and in-flight 835 media, but will not allow access to any external hosts or DNS 836 servers. These networks are often described as "walled-gardens". 838 Captive networks [I-D.ietf-capport-architecture] are similar in that 839 they block access to external hosts, although they can provide 840 generic access after some time. 842 If a walled-garden or captive network defines a PvD with additional 843 information, it can define zones for names that it hosts, such as 844 "airplane.example.com". It can also provide a locally-hosted 845 encrypted DNS server. 847 However, if such a network does not support explicitly advertising 848 local names, clients that try to establish connections to DoH servers 849 will experience connection failures. In these cases, system traffic 850 that is used for connecting to captive portals SHOULD use local 851 resolvers. In addition, clients MAY choose to fall back to using 852 direct resolution without any encryption if they determine that all 853 connectivity is blocked otherwise. Note that this comes with a risk 854 of a network blocking connections in order to induce this fallback 855 behavior, so clients might want to inform users about this possible 856 attack where appropriate, or prefer to not fall back if there is a 857 concern about leaking user data. 859 6.2.4. Network-Based Filtering 861 Some networks currently rely on manipulating DNS name resolution in 862 order to apply content filtering rules to clients associated with the 863 network. Using encrypted DNS resolvers that are not participating in 864 this filtering can bypass such enforcement. However, simply blocking 865 connections for filtering is indistinguishable from a malicious 866 attack from a client's perspective. 868 In order to indicate the presence of filtering requirements, a 869 network deployment can add the "requireDNSFiltering" and 870 "dnsFilteredZones" keys to its PvD information. The 871 "dnsFilteredZones" entry can contain an array of strings, each of 872 which is a domain name that the network requires clients to resolve 873 using the local resolver. If the array contains the string ".", it 874 indicates the network requires filtering for all domains. If 875 "requireDNSFiltering" is present with a boolean value of true, the 876 network is indicating that it expects all client systems to send the 877 names indicated by "dnsFilteredZones" to the local resolver. If 878 "requireDNSFiltering" is not present or set to false, then the 879 filtering service is considered to be optional for clients that want 880 to use it as a service to enforce desired policy. 882 Clients that receive indication of filtering requirements SHOULD NOT 883 use any other resolver for the filtered domains, but treat the 884 network as claiming authority. However, since this filtering cannot 885 be authenticated, this behavior SHOULD NOT be done silently without 886 user consent. 888 Networks that try to interfere with connections to encrypted DNS 889 resolvers without indicating a requirement for filtering cannot be 890 distinguished from misconfigurations or network attacks. Clients MAY 891 choose to avoid sending any user-initiated connections on such 892 networks to prevent malicious interception. 894 7. Performance Considerations 896 One of the challenges of using non-local DNS servers (such as cloud- 897 based DoH servers) is that recursive queries made by these servers 898 will originate from an IP address that is not necessarily 899 geographically related to the client. Many DNS servers make 900 assumptions about the geographic locality of clients to their 901 recursive resolvers to optimize answers. To avoid this problem, the 902 client's subnet can be forwarded to the authoritative server by the 903 recursive using the EDNS0 Client Subnet feature. Oblivious DoH 904 discourages this practice for privacy reasons. However, sharing this 905 subnet, while detrimental to privacy, can result in better targeted 906 DNS resolutions. 908 Adaptive DNS splits DoH queries into two sets: those made to 909 Designated DoH Servers, and those made to Oblivious DoH servers. 910 Oblivious queries are sensitive for privacy, and can encounter 911 performance degradation as a result of not using the client subnet. 912 Queries to designated DoH servers, on the other hand, are sent 913 directly by clients, so the client IP address is made available to 914 these servers. Since these servers are designated by the authority 915 for the names, they can use the IP address subnet information to tune 916 DNS answers. 918 Based on these properties, clients SHOULD prefer lookups via 919 Designated DoH Servers over oblivious mechanisms whenever possible. 920 Servers can encourage this by setting large TTLs for SVCB records and 921 using longer TTLs for responses returned by their Designated DoH 922 Server endpoints which can be more confident they have accurate 923 addressing information. 925 8. Security Considerations 927 In order to avoid interception and modification of the information 928 retrieved by clients using Adaptive DNS, all exchanges between 929 clients and servers are performed over encrypted connections, e.g., 930 TLS. 932 Malicious adversaries may block client connections to all DoH or 933 Oblivious DoH services as a Denial-of-Service (DoS) measure. Clients 934 which cannot connect to any proxy may, by local policy, fall back to 935 unencrypted DNS if this occurs. 937 9. Privacy Considerations 939 Clients must be careful in determining to which DoH servers they send 940 queries directly without proxying. A malicious DoH server that can 941 direct queries to itself can track or profile client activity. In 942 order to avoid the possibility of a spoofed SVCB record designating a 943 malicious DoH server for a name, clients MUST ensure that such 944 records validate using DNSSEC [RFC4033]. 946 Even servers that are officially designated can risk leaking or 947 logging information about client lookups. Such risk can be mitigated 948 by further restricting the list of DoH servers that are whitelisted 949 for direct use based on client policy. 951 Using Oblivious DoH reduces the risk that a single DoH server can 952 track or profile a client. However, clients should exercise caution 953 when using Oblivious DoH responses from resolvers that do not carry 954 DNSSEC signatures. An adversarial Oblivious Target resolver that 955 wishes to learn the IP address of clients requesting resolution for 956 sensitive domains can redirect clients to unique addresses of its 957 choosing. Clients that use these answers when establishing TLS 958 connections may then leak their local IP address to chosen server. 959 Thus, when Oblivious DoH answers are returned without DNSSEC, 960 Privacy-Sensitive Connections concerned about this attack SHOULD 961 conceal their IP address via a TLS- or HTTP-layer proxy or some other 962 tunneling mechanism. 964 An adversary able to see traffic on each path segment of a DoH or 965 Oblivious DoH query (e.g., from client to proxy, proxy to target, and 966 target to an authoritative DNS server) can link queries to specific 967 clients with high probability. Failure to observe traffic on any one 968 of these path segments makes this linkability increasingly difficult. 969 For example, if an adversary can only observe traffic between a 970 client and proxy and egress traffic from a target, then it may be 971 difficult identify a specific client's query among the recursive 972 queries generated by the target. 974 10. IANA Considerations 976 10.1. DoH Template PvD Key 978 This document adds a key to the "Additional Information PvD Keys" 979 registry [I-D.ietf-intarea-provisioning-domains]. 981 +-------------+-------------+--------+------------------------------+ 982 | JSON key | Description | Type | Example | 983 | | | | | 984 +-------------+-------------+--------+------------------------------+ 985 | dohTemplate | DoH URI | String | "https://dnsserver.example | 986 | | Template | | .net/dns-query{?dns}" | 987 | | [RFC8484] | | | 988 +-------------+-------------+--------+------------------------------+ 990 10.2. DNS Filtering PvD Keys 992 This document adds a key to the "Additional Information PvD Keys" 993 registry [I-D.ietf-intarea-provisioning-domains]. 995 +---------------------+-------------------------+---------+---------+ 996 | JSON key | Description | Type | Example | 997 +---------------------+-------------------------+---------+---------+ 998 | requireDNSFiltering | A flag to indicate that | Boolean | true | 999 | | the network requires | | | 1000 | | filtering all DNS | | | 1001 | | traffic using the | | | 1002 | | provisioned resolver. | | | 1003 | | | | | 1004 | dnsFilteredZones | A list of DNS domains | Array | [ "." ] | 1005 | | as strings that | of | | 1006 | | represent domains that | Strings | | 1007 | | can be filtered by the | | | 1008 | | provisioned resolver. | | | 1009 +---------------------+-------------------------+---------+---------+ 1011 Any network that sets the "requireDNSFiltering" boolean to false but 1012 provides "dnsFilteredZones" advertises the optional service of 1013 filtering on the provisioned network. 1015 An "." in the "dnsFilteredZones" array represents a wildcard, which 1016 can be used to indicate that the network is requesting to filter all 1017 names. Any more specific string represents a domain that requires 1018 filtering on the network. 1020 10.3. DoH URI Template DNS Parameter 1022 If present, this parameters indicates the URI template of a DoH 1023 server that is designated for use with the name being resolved. This 1024 is a string encoded as UTF-8 characters. 1026 Name: dohuri 1028 SvcParamKey: 4 1030 Meaning: URI template for a designated DoH server 1032 Reference: This document. 1034 11. Acknowledgments 1036 Thanks to Erik Nygren, Lorenzo Colitti, Tommy Jensen, Mikael 1037 Abrahamsson, Ben Schwartz, Ask Hansen, Leif Hedstrom, Tim McCoy, 1038 Stuart Cheshire, Miguel Vega, Joey Deng, Ted Lemon, and Elliot Briggs 1039 for their feedback and input on this document. 1041 12. References 1043 12.1. Normative References 1045 [I-D.ietf-intarea-provisioning-domains] 1046 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 1047 Shao, "Discovering Provisioning Domain Names and Data", 1048 draft-ietf-intarea-provisioning-domains-07 (work in 1049 progress), September 2019. 1051 [I-D.ietf-tls-esni] 1052 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 1053 "Encrypted Server Name Indication for TLS 1.3", draft- 1054 ietf-tls-esni-04 (work in progress), July 2019. 1056 [I-D.irtf-cfrg-hpke] 1057 Barnes, R. and K. Bhargavan, "Hybrid Public Key 1058 Encryption", draft-irtf-cfrg-hpke-00 (work in progress), 1059 July 2019. 1061 [I-D.nygren-dnsop-svcb-httpssvc] 1062 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1063 and parameter specification via the DNS (DNS SVCB and 1064 HTTPSSVC)", draft-nygren-dnsop-svcb-httpssvc-00 (work in 1065 progress), September 2019. 1067 [I-D.pauly-dprive-oblivious-doh] 1068 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 1069 "Oblivious DNS Over HTTPS", draft-pauly-dprive-oblivious- 1070 doh (work in progress) , October 2019. 1072 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1073 Rose, "DNS Security Introduction and Requirements", 1074 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1075 . 1077 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1078 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1079 DOI 10.17487/RFC7231, June 2014, 1080 . 1082 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1083 and P. Hoffman, "Specification for DNS over Transport 1084 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1085 2016, . 1087 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1088 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1089 . 1091 12.2. Informative References 1093 [I-D.ietf-capport-architecture] 1094 Larose, K. and D. Dolson, "CAPPORT Architecture", draft- 1095 ietf-capport-architecture-04 (work in progress), June 1096 2019. 1098 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1099 Requirement Levels", BCP 14, RFC 2119, 1100 DOI 10.17487/RFC2119, March 1997, 1101 . 1103 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1104 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1105 . 1107 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1108 "IPv6 Router Advertisement Options for DNS Configuration", 1109 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1110 . 1112 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1113 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1114 May 2017, . 1116 Authors' Addresses 1118 Eric Kinnear 1119 Apple Inc. 1120 One Apple Park Way 1121 Cupertino, California 95014 1122 United States of America 1124 Email: ekinnear@apple.com 1126 Tommy Pauly 1127 Apple Inc. 1128 One Apple Park Way 1129 Cupertino, California 95014 1130 United States of America 1132 Email: tpauly@apple.com 1133 Chris Wood 1134 Apple Inc. 1135 One Apple Park Way 1136 Cupertino, California 95014 1137 United States of America 1139 Email: cawood@apple.com 1141 Patrick McManus 1142 Fastly 1144 Email: mcmanus@ducksong.com