idnits 2.17.1 draft-hardaker-dprive-add-doh-dnsop-filter-request-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3. The filter list returned by the URL must be of type text/plain, and must be a simple list of domain names that are to be blocked as requested. Names encode in the list MUST domain names, as encoded in printed zone-format names including any required internationalization support. The names MUST not include a leading or trailing dot. For simplicity, no wild-carding is supported and a prefix of "*." is assumed. Partial end-matches MUST NOT but considered a match. For example, a domain "horrible.football.example.org" will match a filter entry of "football.example.com" but MUST NOT match an entry of "ball.example.org". See Section 5.1 for an example of what a filter list may look like. If the client's request matches a filter in the requested filter list, a response is sent to the client with an REFUSED RCODE and a EDE error code of "errfiltered (18)". -- The document date (September 26, 2019) is 1673 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. 'HTTPS') (Obsoleted by RFC 9113) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Hardaker 3 Internet-Draft USC/ISI 4 Intended status: Standards Track September 26, 2019 5 Expires: March 29, 2020 7 Client DNS Filtering Profile Request 8 draft-hardaker-dprive-add-doh-dnsop-filter-request-00 10 Abstract 12 This document defines a mechanism under which a client can request 13 that an upstream recursive resolver perform DNS filtering on behalf 14 of a client-requested policy. This is may be done, for example, 15 under a subscription model, where the client wishes not to get 16 redirected to domains known to host malware or malicious content. 17 This request is sent as an EDNS0 option with every DNS request, or 18 potentially to just the first DNS request in a stream when using DNS 19 over TLS, DNS over DTLS or DNS over DOH for example. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 29, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Purpose of this document . . . . . . . . . . . . . . . . 2 57 1.2. Real Introduction . . . . . . . . . . . . . . . . . . . . 3 58 1.3. Requirements notation . . . . . . . . . . . . . . . . . . 4 59 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Extension Packet Format . . . . . . . . . . . . . . . . . 4 61 3. Filter Record Overview . . . . . . . . . . . . . . . . . . . 4 62 4. ISP signalling . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Resolver processing . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Example Filter List . . . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 8. Informative References . . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 [DOCUMENT STATUS NOTE: this specification is VERY INCOMPLETE and is 74 at the stage of "discuss whether this is a good or bad idea in 75 general", and not at the stage of "your processing steps are broken" 76 or, worse "you mispelled misspelled". Keep reading for further 77 background.] 79 1.1. Purpose of this document 81 Right now, the DNS ecosystem is being used in a multitude of ways 82 that are intricately bound together based on its evolution over time. 83 DNS resolvers today are acting as both a DNS resolution service, as 84 originally intended, and as a control point by offering filtering 85 (and rewriting) services on behalf of the client, the ISP, and 86 policies imposed by enterprises/organizations and governments. One 87 significant issue that has arisen under some proposed deployment 88 architectures for [DOH] in which Applications Doing DNS (in the ADD 89 pseudo-WG) may bypass traditional DNS resolvers within ISPs, 90 alleviating those ISPs from offering DNS-based filtering and 91 protection services. 93 This document is an attempt to see if those two roles can be safely 94 severed, so users in an [DOH] world can select a resolver that best 95 suits their resolution policies and separately select filtering 96 policies that best suit their access requirements. 98 There are many other ways such a policy transmission feature could be 99 implemented. DNS real-time blacklist (DNSRBL) like techniques could 100 be used, ISPs could publish policy pointers under the DNS reverse 101 tree, DoH clients could publish policies within HTTP headers 102 (limiting its use to just DoH), ... I selected the one below as the 103 "most out of the box" to promote thinking, not because I expect it to 104 be the best option. Specifically, I have doubts that public large 105 scale DoH providers will want to memorize large numbers of published 106 policy lists (and hence, DNSRBL may actually be a better choice). 108 [There are other ways to implement what is described below, but I 109 wanted to pick a more novel idea to promote wider thinking than "use 110 an RBL like pointer" or "use a HTTPS header for just DOH because 111 that's really what triggered the filtering discussions in the first 112 place."] 114 1.2. Real Introduction 116 DNS today provides a distributed name resolution database that serves 117 as the basis for many technologies, and is the starting point for 118 nearly all communication that occurs on the Internet. Because of 119 this, it frequently serves as a filtering mechanism by Network 120 Providers who which to deploy DNS filtering or data modification 121 technologies, for better or worse. As DNS is pushing further into 122 being encrypted from client to recursive resolver by technologies 123 such as [DNSTLS] and [DOH], clients are increasingly using encrypted 124 communication to DNS resolvers that may have different or no 125 filtering policies and mechanisms (protective or otherwise), than 126 intended by the networking configuration distributed from their 127 Internet Service Provider (ISP) or other access point. This document 128 puts the selection of a selective DNS filtering service back in the 129 hands of the user, since DNS centralization threatens to remove 130 client ability to do so. 132 Specifically, this document defines a mechanism under which a client 133 can request that its upstream recursive resolver perform DNS 134 filtering on behalf of a client-requested policy. This is may be 135 done, for example, under a subscription model, where the client 136 wishes not to get redirected to domains known to host malware or 137 malicious content. This request is sent as an EDNS0 [EDNS0] option 138 with every DNS request, or potentially to just the first DNS request 139 in a stream when using DNS over TLS, DNS over DTLS or DNS over DOH 140 for example. 142 One could argue that clients could accomplish these goals by simply 143 using a different resolver. However, this specifications allows 144 decoupling of resolvers and filtering such that a default resolver 145 configured in an operating system or application can still use a 146 system-level configured filtering mechanism acting independently of 147 resolution. A client can then select the best resolver to support 148 resolution services which can be independent from the best source of 149 malicious content or other filtering. 151 1.3. Requirements notation 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119] 157 2. Extension Overview 159 2.1. Extension Packet Format 161 The EDNS0 option format for passing a Filter Request (FR) list to the 162 upstream DNS resolver using the following format: 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 166 0: | OPTION-CODE | 167 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 2: | OPTION-LENGTH | 169 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 170 4: / FILTER-NAME ... / 171 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 173 The FILTER-NAME field is a normally encoded DNS NAME that is expected 174 to point to a publicly published DNS record from the filtering 175 service a client wishes to make use of. Details of this record are 176 documented in Section 3. 178 XXX: better text for normally encoded, and compression, etc 180 3. Filter Record Overview 182 Filtering services that wish to publish a DNS domain filter list may 183 publish a DNS record containing a URI from which a resolver may fetch 184 the current filter list. This published name MUST be of type TXT and 185 MUST begin with _dnsfilter but otherwise may be published at any 186 point in the DNS tree. Multiple records SHOULD be considered as 187 alternate fetch points and recursive resolvers supporting this 188 specification should fetch the first one available and then continue 189 with the steps outlined in Section 5. 191 Example: 193 _dnsfilter.example.com 86400 IN TXT "https://dnsfilter.example.org/" 194 The name "_dnsfilter.example.com" may then be referred to by clients 195 in the FR extension packet. 197 4. ISP signalling 199 ISPs offering filtering service to their clients may signal suggested 200 filtering lists to their clients via ... DHCP? (because starting one 201 fight in this document wasn't enough) 203 Maybe a DNS request hosted by the dhcp configured resolver? 205 (aka: ideas welcome here.) 207 5. Resolver processing 209 Recursive resolvers supporting this specification should perform the 210 following steps upon receiving a request with a FILTER-NAME option. 212 1. If the recursive resolver does not support filtering, it should 213 process the DNS request as normal and return an Extended DNS 214 Error (EDE) error of "filteringNotSupported" along with the 215 response. Stop. 217 2. If the FILTER-NAME is not currently in its cached set of DNS 218 filters, it should attempt to resolver the name pointed to by the 219 FILTER-NAME record. The list of returned URLs should attempted 220 to be fetched, and the first successful download should be stored 221 in a filter cache along with the FILTER-NAME and the cache length 222 returned by the URL server [XXX: what's the HTTP field; I 223 forget]. If no URL can be successfully retrieved, then the 224 resolver should continue to process the DNS request without 225 applying a filter and return an EDE error of 226 "filteringUnavailable". 228 3. The filter list returned by the URL must be of type text/plain, 229 and must be a simple list of domain names that are to be blocked 230 as requested. Names encode in the list MUST domain names, as 231 encoded in printed zone-format names including any required 232 internationalization support. The names MUST not include a 233 leading or trailing dot. For simplicity, no wild-carding is 234 supported and a prefix of "*." is assumed. Partial end-matches 235 MUST NOT but considered a match. For example, a domain 236 "horrible.football.example.org" will match a filter entry of 237 "football.example.com" but MUST NOT match an entry of 238 "ball.example.org". See Section 5.1 for an example of what a 239 filter list may look like. If the client's request matches a 240 filter in the requested filter list, a response is sent to the 241 client with an REFUSED RCODE and a EDE error code of "errfiltered 242 (18)". 244 4. The resolver should continue normal resolution of the client's 245 request. 247 XXX: should we add a 'stop' or 'continue' on error bit to the EDNS0 248 option? 250 5.1. Example Filter List 252 An example filter list might include the following name list: 254 example.com 255 malware.example.org 256 notforchildren.subdomain.example.org 257 example 258 [need an internationalization example here] 260 Note that the last example matches everything under the 'example' TLD 262 6. Security Considerations 264 Modification, addition or removal of the EDNS0 option by device-in- 265 the-middle attackers may cause unintended consequences for clients 266 hoping to apply (or avoid) filtering. It is advisable that DNS 267 requests that make use of this option send it over an authenticated 268 transport such as [DNSTLS] or [DOH]. 270 Similarly, providers of DNS FILTERING lists SHOULD published their 271 FILTER-NAME within a DNSSEC signed zone. They SHOULD offer (and 272 require) URLs that make use of protected transports, such as [HTTPS]. 274 7. IANA Considerations 276 This document adds two new EDE codes to the EDE (xxx: ref) 277 specification: filteringNotSupported and filteringUnavailable. 279 8. Informative References 281 [DNSTLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 282 and P. Hoffman, "Specification for DNS over Transport 283 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 284 2016, . 286 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 287 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 288 . 290 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 291 RFC 2671, DOI 10.17487/RFC2671, August 1999, 292 . 294 [HTTPS] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 295 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 296 DOI 10.17487/RFC7540, May 2015, . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, . 304 Appendix A. Acknowledgments 306 peeps that help out will go here 308 Author's Address 310 Wes Hardaker 311 USC/ISI 313 Email: ietf@hardakers.net