idnits 2.17.1 draft-hallambaker-dnse-02.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 == Line 342 has weird spacing: '...closure of re...' == Line 346 has weird spacing: '...closure of re...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 7, 2014) is 3458 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) == Missing Reference: 'U-LOCAL' is mentioned on line 203, but not defined == Missing Reference: 'U-PRIVATE' is mentioned on line 259, but not defined == Missing Reference: 'U-HYBRID' is mentioned on line 271, but not defined == Missing Reference: 'U-A-BULK' is mentioned on line 296, but not defined == Missing Reference: 'U-A-TAIL' is mentioned on line 299, but not defined == Missing Reference: 'R-C-PASSIVE' is mentioned on line 341, but not defined == Missing Reference: 'R-C-AFIRST' is mentioned on line 345, but not defined == Missing Reference: 'R-C-ACTIVE' is mentioned on line 349, but not defined == Missing Reference: 'R-C-LINK' is mentioned on line 380, but not defined == Missing Reference: 'R-C-TRAFFIC' is mentioned on line 358, but not defined == Missing Reference: 'R-C-PROFILE' is mentioned on line 362, but not defined == Missing Reference: 'R-C-AUTHOR' is mentioned on line 365, but not defined == Missing Reference: 'R-ONESPOOF' is mentioned on line 397, but not defined == Missing Reference: 'R-QUERYSPOOF' is mentioned on line 402, but not defined == Missing Reference: 'R-CANON' is mentioned on line 408, but not defined == Missing Reference: 'R-CAUTH' is mentioned on line 411, but not defined == Missing Reference: 'R-AMP' is mentioned on line 415, but not defined == Missing Reference: 'R-DDOS' is mentioned on line 418, but not defined == Missing Reference: 'R-PSPOOF' is mentioned on line 425, but not defined == Missing Reference: 'R-ASPOOF' is mentioned on line 426, but not defined == Missing Reference: 'RCAUTH' is mentioned on line 426, but not defined Summary: 0 errors (**), 0 flaws (~~), 25 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track November 7, 2014 4 Expires: May 11, 2015 6 DNS Privacy and Censorship: Use Cases and Requirements. 7 draft-hallambaker-dnse-02 9 Abstract 11 This document describes use cases and requirements arising from 12 privacy an free speech concerns in the DNS. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 Copyright Notice 31 Copyright (c) 2014 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Table of Contents 46 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3 48 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.3. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 3 51 2.1. Core Use Cases . . . . . . . . . . . . . . . . . . . . . 4 52 2.1.1. Client/Resolver Communications . . . . . . . . . . . 5 53 2.1.2. Resolver/Authoritative Communications . . . . . . . 7 54 2.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.2.1. Legacy Deployment . . . . . . . . . . . . . . . . . 7 56 2.2.2. Integrity Attacks . . . . . . . . . . . . . . . . . 8 57 2.2.3. Limited message size . . . . . . . . . . . . . . . . 8 58 2.2.4. Confidentiality Requirements . . . . . . . . . . . . 8 59 2.2.5. Integrity Requirements . . . . . . . . . . . . . . . 9 60 2.2.6. Access Requirements . . . . . . . . . . . . . . . . 9 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 5. Acnowledgementsts . . . . . . . . . . . . . . . . . . . . . . 10 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction. 70 Recent events have required urgent consideration of privacy concerns 71 in Internet protocols. In particular the lack of confidentiality 72 controls in the DNS [RFC1035] protocol is of considerable concern. 74 This document illustrates the privacy and related concerns raised 75 with a set of use cases which in turn give rise to a set of 76 requirements. 78 1.1. Related Work 80 DNS Security (DNSSEC), [RFC4033] is an existing standard that 81 protects the integrity of data between a DNS authoritative server and 82 the party making a request. DNSSEC does not provide confidentiality 83 and only permits blocking of integrity checks to be detcted. Since 84 the only action available to the client in this circumstance is to 85 block access to the possibly compromized site or accept a downgrade 86 attack, this is not a sufficient countermeasure against a denial of 87 service attack. 89 It is anticipated that the proposals developed to address the use 90 cases and requirements specified in this document will compliment 91 rather than replace the existing mechanisms provided in DNSSEC. 93 1.2. Terminology 95 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 96 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 97 document, are to be interpreted as described in [RFC2119] 99 1.3. Defined Terms 101 [[These terms are deliberately left blank here or else we will spend 102 time wordsmithing the defined term definitions rather than looking at 103 the protocol.] 105 Authoritative DNS Server 107 Caching Recursive Resolver 109 DNS 111 DNS Client 113 Recursive Resolver 115 Stub Resolver 117 2. Use Cases and Requirements 119 The immediate motivation for considering a DNS transport layer 120 security protocol is the desire to improve the privacy of Internet 121 communications by allowing encryption of DNS requests and responses. 123 A closely related concern that is directly affected by 125 2.1. Core Use Cases 127 The DNS is the Internet infrastructure that makes authoritative 128 statements about DNS names. In particular the DNS is used to support 129 discovery of Internet services by mapping DNS names onto IP 130 addresses. 132 In the conventional configuration, a client requiring information 133 from the DNS does not access DNS authoritative servers directly and 134 instead makes requests through a resolver. The resolver in turn 135 determines which requests to make to answer the query and forwards 136 the request to the authoritative server. 138 +-------------+ +-------------+ +-------------+ 139 | Client |--->| Resolver |--->|Authoritative| 140 +-------------+ +-------------+ +-------------+ 142 Due to the distributed and hierarchical nature of the DNS, answering 143 a DNS query typically requires queries to multiple Authoritative 144 servers. This process is known as Recursive Resolution of the DNS 145 Query. In the typical configuration the Resolver is a 'Caching 146 Recursive Resolver' capable of making Recursive Queries and caching 147 the result to answer future queries. The client is typically a 'Stub 148 Client' that is not capable of making recursive queries itself and 149 must rely on a Recursive Resolver to do this for it. 151 One of the major security weaknesses in the DNS infrastructure as 152 currently deployed is that by default most Internet enabled devices 153 accept DNS service from the servers offered to it by DHCP when a 154 connection is established. Since the DNS is a naming service and thus 155 a trusted service, DNS services SHOULD be trustworthy. The practice 156 of relying on a the 'local' DNS resolver advertised in the DHCP 157 connection is therefore highly unsatisfactory. 159 In real world circumstances this configuration is further complicated 160 by firewalls, NAT devices and other middleboxes. Many of which filter 161 or in some cases modify DNS protocol packets whether or not they are 162 addressed to that device. 164 For the purposes of considering the privacy of the DNS protocol, 165 there are two important protocol interactions to consider: 167 * Communications between a Client and a Resolver 169 * Communications between a Resolver and an Authoritative Server 171 The DNS protocol supports both modes of interaction without special 172 provision for either case. From a security point of view, the two 173 interactions have different characteristics and give rise to 174 different use cases. 176 2.1.1. Client/Resolver Communications 178 Communications between the client and the resolver reveal a lot of 179 privacy sensitive information about the user. A DNS query for the 180 address of a controversial Web Site indicates with high probability 181 that a user is viewing material from the site. 183 In the typical configuration a DNS client makes use of the DNS 184 resolution server(s) advertised by DHCP when a network configuration 185 is established or server(s) that are configured manually by an 186 administrator. 188 In either case the relationship between the client and the resolver 189 is at minimum persistent for the length of time the network 190 association is active. In the case that the DNS service is selected 191 and confinugred manually, the security relationship might last for 192 years or the entire life of the device. 194 2.1.1.1. Local Resolver 196 For the sake of completeness, we state the case in which a client 197 obtains DNS service from a local DNS server advertised at the time 198 the network connection is established as a use case. Note however 199 that the privacy concerns that can be protected in such circumstances 200 are necessarily limited as the user has no idea where the service is 201 being provided from. 203 [U-LOCAL]: User connects to untrusted local network and wishes to use 204 the locally provided DNS service. 206 While a user may not intend to use the local DNS service, there are 207 many real world network configurations that attempt to impose this on 208 the user for a variety of reasons. In particular hotels and other 209 providers of local wireless Internet often make use of a 'captive DNS 210 resolver' to direct users to a portal for a variety of business 211 purposes that include limiting use of the wireless network to 212 particular parties. 214 While it is clearly impossible to provide robust privacy protections 215 to users who accept core network functions from random untrustworthy 216 sources, the ability to establish network connections in such 217 circumstances is essential. 219 2.1.1.2. Selected Public Resolver 221 A public resolver allows users to avoid the numerous security 222 vulnerabilities inherent in the local resolver model. Instead of 223 taking trusted services from random, anonymous providers, the user 224 selects a particular DNS resolution provider to be used regardless of 225 which network is in use. 227 Many Public DNS resolution services are for-profit commercial 228 ventures. The business models supporting such services include 229 advertising and data-mining the DNS log file data. 231 [[U-PUBLIC] The user takes DNS resolution service from a selected 232 provider offering a public DNS resolution service. 234 2.1.1.3. Selected Subscriber Resolver 236 In an alternative business model the DNS resolution service is 237 visible to the public Internet but only answers requests from paying 238 subscribers. While such a service might not be considered 239 sufficiently attractive for it to be offered as a stand-alone 240 service, an ISP or security provider might offer a privacy enhanced 241 DNS as part of a more general offering. 243 [[U-SUBSCRIBER] The user takes DNS resolution service from a selected 244 provider offering the service on a subscription model of some form. 246 2.1.1.4. Selected Private Resolver 248 Most medium to large enterprises run their own DNS services as part 249 of their trusted network infrastructure. 251 Although the DNS is conceptually a single uniform namespace, many 252 Internet sites regard the DNS names of their internal network 253 machines to be secret. Protecting the secrecy of such names being one 254 of the principle attractions of a DNS privacy protocol to such 255 enterprises. this leads to the widespread use of 'split-horizon' DNS 256 in which different views of the DNS namespace are visible depending 257 on whether a machine is inside or outside the enterprise. 259 [U-PRIVATE] A device takes DNS resolution service from a private 260 service restricted to authorized use. 262 2.1.1.5. Hybrid Resolver 264 To reduce equipment costs and in response to employee demand, many 265 enterprises now support a Bring Your Own Device (BYOD) model in which 266 a device that is the property of the owner. Such a device requires 267 access to a private DNS service to access enterprise resources within 268 a hidden split-horizon DNS. But the owner might not wish their 269 private use of the device to be visible to their employer. 271 [U-HYBRID] A user makes use of different DNS resolution services for 272 different portions of the DNS namespace. 274 2.1.2. Resolver/Authoritative Communications 276 Communications between a Resolver and an Authoritative Server can 277 also leak privacy sensitive data. Such leakage is mitigated at 278 resolvers with a large number of users and a high traffic load. 280 Unlike clients which typically direct DNS requests to a single 281 resolver or a small number of resolvers, resolvers typically interact 282 with a large number of authoritative servers. Some of which service a 283 large number of DNS domains and others service are restricted to a 284 publishing data for a specific enterprise. 286 Although these use cases are not distinguished in the DNS protocol, 287 the privacy implications and protocol constraints of interactions 288 with the two types of server are very different. Any interaction 289 between a resolver and an authoritative server that responds to 290 requests for a single domain with a single host effectively discloses 291 the nature of the request regardless of whether encryption is used. 292 At the other extreme, traffic analysis of interactions with 293 authoritative services serving a large number of domains revealls 294 much less. 296 [U-A-BULK] Interaction between a resolver and an authoritative server 297 supporting a large number of domains. 299 [U-A-TAIL] Interaction between a resolver and an authoritative server 300 supporting a small number of domains such that the interaction is 301 effectively disclosure of the nature of the communication. 303 2.2. Constraints 305 Any proposal to address the use cases must operate within the 306 constraints set by existing DNS infrastructure and administration 307 practices. 309 2.2.1. Legacy Deployment 311 The DNS protocol specification was first published in 1987 and has 312 evolved significantly over time. While the vast majority of deployed 313 DNS servers support modern features such as EDN(0) and DNSSEC, many 314 do not. Likewise, most DNS clients and servers accept messages longer 315 than the 500 byte minimum implementation requirement. 317 Regretably, while most DNS clients and servers are capable of 318 supporting features introduced since [RFC1035], many middle-box 319 devices including firewalls and residential network gateway devices 320 do not. 322 2.2.2. Integrity Attacks 324 One of the core security vulnerabilities of the original DNS protocol 325 is that responses are only weakly bound to requests, thus enabling an 326 attack known as 'DNS-Spoofing'. 328 While DNSSEC is intended to provide a long term solution to the 329 problem of DNS spoofing, deployment of DNSSEC is currently the rare 330 exception rather than the rule. 332 2.2.3. Limited message size 334 One of the chief performance limitations of the DNS as currently 335 deployed is that most DNS servers will only accept a single request 336 per DNS message. Th despite support for multiple queries in a single 337 request in the DNS protocol, 339 2.2.4. Confidentiality Requirements 341 [R-C-PASSIVE] 342 Prevent or mitigate disclosure of request and response data 343 against a passive attacker. 345 [R-C-AFIRST] 346 Prevent or mitigate disclosure of request and response data 347 against an active attacker after first contact. 349 [R-C-ACTIVE] 350 Prevent or mitigate disclosure of request and response data 351 against an active attacker on every contact. 353 [R-C-LINK] 354 Prevent or mitigate transaction linking that would disclose 355 communications made in different network contexts as 356 originating from the same soure.. 358 [R-C-TRAFFIC] 359 Prevent or mitigate disclosure from the pattern of 360 communications. 362 [R-C-PROFILE] 363 Protect the client against profiling by a resolver. 365 [R-C-AUTHOR] 366 Protect the confidentiality of messages against profiling by 367 authoritative servers. 369 Any form of disclosure could potentially be damaging. It is not the 370 potential for harm but rather the likelihood of harm and the 371 difficulty of mounting an attack that distinguishes these 372 requirements in practice. 374 As with any security concern, confidentiality is a property of a 375 system and not a particular component in that system. In particular 376 any protocol that employs end-to-end IP transport (i.e. not via TOR) 377 will leak indentifiable information about the client in the source IP 378 address of a request. While such disclosure will inevitably limit the 379 degree to which a technology that is built on end-to-end IP can 380 protect privacy, this does not mean that the requirements such as [R- 381 C-LINK] should be abandoned: A careless proposal could make matters 382 much worse. 384 For example consider the case in which a protocol proposal uses a 385 static identifier that is never changed to specify an encryption key 386 to a resolver. For a static machine with a fixed IP address, such an 387 identifier would leak no more information than the IP address. But 388 used on a mobile device, the static identifier would allow a passive 389 observer to determine that a collection of communications to the 390 resolver from different IP addresses all came from the same machine. 391 Since the IP address effectively discloses location, such entries 392 would essentially disclose the travelling history of the device and 393 thus allow the user's travel pattern to be inferred. 395 2.2.5. Integrity Requirements 397 [R-ONESPOOF] 398 Prevent spoofing of DNS responses by active attack that is only 399 possible within a narrow window of opportunity. For example 400 during a one-time key exchange. 402 [R-QUERYSPOOF] 403 Prevent spoofing of DNS responses by active attack on any query 404 transaction. 406 2.2.6. Access Requirements 408 [R-CANON] 409 Support anonymous access to a DNS resolution service 411 [R-CAUTH] 412 Support authentication of the client requesting access to a DNS 413 resolution service 415 [R-AMP] 416 Prevent Message amplification attack 418 [R-DDOS] 419 Prevent Denial of Service attack on the service 421 Note that [[R-CANON] and [[RCAUTH] are mutually exclusive. While it 422 is desirable for a solution to be capable of supporting both it is 423 not possible for a request to be anonymous and authenticated at the 424 same time by definition. The access requirement [[RCAUTH] is also 425 distinct from the spoofing countermeasure requirements [R-PSPOOF] and 426 [R-ASPOOF]. The access requirement [[RCAUTH] requires that the 427 service identify the source of a request. The anti-spoofing 428 requirements require that responses be authenticated against the 429 requests made. 431 3. Security Considerations 433 The use cases set out above give rise to the following requirements. 435 The term 'requirement' is used to refer to protocol features that 436 might be considered desirable without taking a position as to whether 437 they are necessary or desirable in practice. A proposal that is 438 simpler or more performant may be considered to be superior to one 439 that satisfies every requirement. 441 4. IANA Considerations 443 None 445 5. Acnowledgementsts 447 6. References 449 6.1. Normative References 451 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [RFC4033] Arends, R.,Austein, R.,Larson, M.,Massey, D.,Rose, S., 455 "DNS Security Introduction and Requirements", RFC 4033, 456 March 2005. 458 [RFC1035] Mockapetris, P., "Domain names - implementation and 459 specification", STD 13, RFC 1035, 1 November 1987. 461 Author's Address 463 Phillip Hallam-Baker 464 Comodo Group Inc. 466 philliph@comodo.com