idnits 2.17.1 draft-nottingham-doh-digests-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 (July 02, 2018) is 2118 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-12 == Outdated reference: A later version (-06) exists of draft-ietf-httpbis-http2-secondary-certs-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft July 02, 2018 4 Intended status: Informational 5 Expires: January 3, 2019 7 DOH Digests 8 draft-nottingham-doh-digests-00 10 Abstract 12 The lack of flexible configuration and selection mechanisms for DOH 13 servers is identified as suboptimal for privacy and performance in 14 some applications. 16 This document makes a straw-man proposal for an improvement. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 3, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. DOH's Additional Benefits for Associated Services . . . . 2 54 1.2. Achieving DOH's Privacy Goals through Diversity . . . . . 3 55 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 56 3. DOH Digests . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Using DOH Digests . . . . . . . . . . . . . . . . . . . . 4 58 3.2. The DOH Digest Format . . . . . . . . . . . . . . . . . . 5 59 3.3. Hostname Normalisation . . . . . . . . . . . . . . . . . 5 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 64 6.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 One of the core motivations for DOH [I-D.ietf-doh-dns-over-https] is 70 to improve end-user privacy by obfuscating the stream of DNS requests 71 that the DOH client makes. It does this by mixing DOH requests into 72 a stream of "normal" HTTP requests to a configured Web server; for 73 example, a large Web site or a Content Delivery Network. 75 However, DOH intentionally avoids defining a mechanism for 76 configuring a particular DOH server for a given application or host. 77 So far, the most common way to do so is to select one from a pre- 78 configured list of services in an application, such as a Web browser. 80 Typically, the list of available DOH services is vetted by the 81 application's vendor to assure that they will honour the 82 application's requirements for handling of sensitive data (i.e., the 83 client's DNS request stream) and similar concerns. 85 This document proposes a means of selecting a DOH server that 86 encourages the deployment of DOH servers by sharing some of its 87 additional benefits with servers that are good candidates for serving 88 DOH traffic. 90 1.1. DOH's Additional Benefits for Associated Services 92 When a DOH server is colocated with (or closely coordinated with) 93 other network services - especially HTTP services - those associated 94 services enjoy a few additional benefits beyond those seen by 95 adopting DOH in the first place. 97 o Associated services have an additional privacy benefit; there is 98 one less party involved in the interaction, whereas "normal" DNS 99 and DOH to an unassociated HTTP server require a third party to 100 resolve names. 102 o Removing a third party also removes a separate point of potential 103 failure, improving control over service quality and availability. 104 See [fragile] for further discussion. 106 o Finally, the DOH server can use DNS to optimise the provision of 107 associated services. For example, DNS results can be optimised 108 based on the client's request stream with a higher degree of 109 certainty. 111 In the future, a DOH server might might use Secondary Certificates 112 [I-D.ietf-httpbis-http2-secondary-certs] to further optimise 113 performance of associated services, by using the information in the 114 DNS request stream to aggregate all of its traffic into a small 115 number of connections (possibly only one), thereby allowing greater 116 coordination of congestion control and avoiding connection setup 117 costs. 119 1.2. Achieving DOH's Privacy Goals through Diversity 121 Overall, a major goal for deployment of DOH is to assure that DNS 122 connectivity is robust and private. Arguably, this is best served by 123 having a diverse set of available DOH servers that are colocated with 124 popular HTTP content, so that it's more difficult to discriminate DOH 125 from "regular" HTTP, and so the it's more difficult to block DOH 126 services, due to the high impact of blocking a popular site. 128 One way to encourage the development of such a set is to offer the 129 additional benefits above to parties that are good candidates for 130 serving such traffic. When clients can direct their DOH queries to 131 the HTTP server which will eventually serve their traffic, it 132 provides both better privacy properties and better performance and 133 availability to a broader set of servers. 135 This is a marked improvement over the static configuration mechanism 136 commonly in place now; accruing such privacy, availability, and 137 performance benefits to whatever DOH server the application or user 138 selects means that only parties who have a relationship with that 139 service will realise these benefits. 141 This document proposes one way to achieve this. 143 2. Conventions and Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. DOH Digests 153 A DOH Digest is a Bloom filter indicating the set of hosts a given 154 DOH server should be used for. 156 3.1. Using DOH Digests 158 When an application has a valid DOH digest for a given DOH server, it 159 tests the digest for each DNS request it makes by hostname; if the 160 hostname (after normalisation) is found in the digest, all DNS 161 requests regarding that hostname SHOULD be sent to the corresponding 162 DOH server. If multiple DOH digests match a given hostname, any 163 matching DOH server MAY be used; the client SHOULD select one of the 164 candidates randomly. 166 If the DOH service is unavailable, produces errors (HTTP or DNS), or 167 the application otherwise fails to obtain an answer from it, the 168 application MAY (but is not required to) fall back to using another 169 configured DOH server, or to using "normal" DNS. 171 Likewise, hosts that do not match any configured bloom filter SHOULD 172 be sent to a randomly selected DOH server that is available. 174 The means of discovering a DOH digest for a given DOH server is out 175 of scope for this document, but generally it will be pre-arranged 176 between the application and the DOH server. 178 The nature of this arrangment is highly dependent upon the 179 application and its desired properties. That said, a number of 180 requirements are placed upon this arrangement. 182 o The digest MUST be conveyed in a manner that is secure and 183 authenticated; e.g., TLS with appropriate certificate checks. 184 Clients MUST enforce this. 186 o The application MUST consider the DOH service as meeting whatever 187 criteria it deems fit for configuring a "catch-all" DOH service 188 (e.g., in terms of privacy, service availability, etc.), since 189 false positives might be sent to the service, and hosts not 190 matched by any configured bloom filter might be sent to it. 192 o The digest MUST be updated on a periodic basis; e.g., once a day. 193 Clients SHOULD NOT use stale digests. 195 3.2. The DOH Digest Format 197 TBD - likely just a bloom filter. 199 3.3. Hostname Normalisation 201 TBD 203 4. Security Considerations 205 Because a DOH digest allows a DOH server to claim traffic from an 206 arbitrary hostname, applications need to take extreme care in 207 selecting the DOH servers they will be accepted from, as well as 208 assuring that their integrity and authentication have not been 209 compromised. 211 Applications might mitigate this by monitoring DOH servers for such 212 abuse and terminating their ability to use DOH digests when it is 213 found. 215 TBD - more advanced mitigations 217 A hostname is effectively captured by a DOH server until the digest 218 that reflects any change in its status is updated in the application. 219 This delay should not result in any loss of functionality, since the 220 "old" configuration will still direct requests to a functional DOH 221 server. 223 5. IANA Considerations 225 This document currently has no IANA actions, but may grow some as the 226 document progresses. 228 6. References 230 6.1. Normative References 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 238 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 239 May 2017, . 241 6.2. Informative References 243 [fragile] Kashaf, A., Zarate, C., Wang, H., Agarwal, Y., and V. 244 Sekar, "Oh, What a Fragile Web We Weave: Third-party 245 Service Dependencies In Modern Webservices and 246 Implications", June 2018, 247 . 249 [I-D.ietf-doh-dns-over-https] 250 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 251 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 252 progress), June 2018. 254 [I-D.ietf-httpbis-http2-secondary-certs] 255 Bishop, M., Sullivan, N., and M. Thomson, "Secondary 256 Certificate Authentication in HTTP/2", draft-ietf-httpbis- 257 http2-secondary-certs-02 (work in progress), June 2018. 259 Author's Address 261 Mark Nottingham 263 Email: mnot@mnot.net 264 URI: https://www.mnot.net/