idnits 2.17.1 draft-lmo-dprive-phase2-requirements-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 28, 2019) is 1642 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 549 -- Looks like a reference, but probably isn't: '2' on line 551 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DPRIVE J. Livingood 3 Internet-Draft Comcast 4 Intended status: Informational A. Mayrhofer 5 Expires: April 30, 2020 nic.at GmbH 6 B. Overeinder 7 NLnetLabs 8 October 28, 2019 10 DNS Privacy Requirements for Exchanges between Recursive Resolvers and 11 Authoritative Servers 12 draft-lmo-dprive-phase2-requirements-00 14 Abstract 16 This document provides requirements for adding confidentiality to DNS 17 exchanges between recursive resolvers and authoritative servers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction & Scope . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Threat Model and Problem Statement . . . . . . . . . . . . . 3 56 4. Core Requirements . . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Prioritization of Requirements . . . . . . . . . . . . . 5 58 4.2. Opportunistic Upgrade to Encryption . . . . . . . . . . . 5 59 4.3. Detection of Availability . . . . . . . . . . . . . . . . 5 60 4.4. Resistance to Downgrade Attack . . . . . . . . . . . . . 6 61 4.5. End-User Policy Propagation . . . . . . . . . . . . . . . 6 62 5. Perspectives and Use Cases . . . . . . . . . . . . . . . . . 7 63 5.1. The User Perspective and Use Cases . . . . . . . . . . . 8 64 5.2. The Operator Perspective and Use Cases . . . . . . . . . 8 65 5.3. The Implementor / Software Vendor Perspective and Use 66 Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.4. Performance and Efficiency . . . . . . . . . . . . . . . 10 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. lmo-dprive-phase2-requirements-00 . . . . . . . . . . . . 11 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 79 1. Introduction & Scope 81 The 2018 approved charter of the IETF DPRIVE Working Group [1] 82 contains milestones related to confidentiality aspects of DNS 83 transactions between the iterative resolver and authoritative name 84 servers. 86 This is also reflected in the DPRIVE milestones [2], which (as of 87 October 2019) contains two relevant milestones: 89 Develop requirements for adding confidentiality to DNS exchanges 90 between recursive resolvers and authoritative servers (unpublished 91 document). 93 Investigate potential solutions for adding confidentiality to DNS 94 exchanges involving authoritative servers (Experimental). 96 This document intends to cover the first milestone for defining 97 requirements for adding confidentiality to DNS exchanges between 98 recursive resolvers and authoritative servers. This may in turn lead 99 to progress in investigating, developing and standardizing potential 100 experimental methods of meeting those requirements. 102 The motivation for this work is to extend the confidentiality methods 103 used between a user's stub resolver and a recursive resolver to the 104 recursive queries sent by recursive resolvers in response to a DNS 105 lookup (when a cache miss occurs and the server must perform 106 recursion to obtain a response to the query). A recursive resolver 107 will send queries to root servers, to Top Level Domain (TLD) servers, 108 to authoritative second level domain servers and potentially to other 109 authoritative DNS servers and each of these query/response 110 transactions presents an opportunity to extend the confidentiality of 111 user DNS queries. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 This document also makes use of DNS Terminology defined in [RFC8499] 123 3. Threat Model and Problem Statement 125 Currently, potentially privacy-protective protocols such as DoT 126 provide encryption between the user's stub resolver and a recursive 127 resolver. This provides (1) protection from observation of end user 128 DNS queries and responses as well as (2) protection from on-the-wire 129 modification DNS queries or responses. Of course, observation and 130 modification are still possible when performed by the recursive 131 resolver, which decrypts queries, serves a response from cache or 132 performs recursion to obtain a response (or synthesizes a response), 133 and then encrypts the response and sends it back to the user's stub 134 resolver. 136 But observation and modification threats still exist when a recursive 137 resolver must perform DNS recursion, from the root to TLD to 138 authoritative servers. This document specifies requirements for 139 filling those gaps. 141 4. Core Requirements 143 The requirements of different interested stakeholders are outlined 144 below. The parenthetical risks and priority levels are intended only 145 to spur discussion. But at a high level the requirements may be 146 summarized as follows: 148 o Implement DoT between a recursive resolver and the root servers 149 (low risk, low priority) 151 o Implement DoT between a recursive resolver and TLD servers (low 152 risk, low priority) 154 o Implement DoT between a recursive resolver and second level 155 authoritative servers (high risk, high priority) 157 o Implement DoT between a recursive resolver and other authoritative 158 servers 160 o Implement DoT in each case in a manner that enables operators to 161 perform appropriate performance and security monitoring, conduct 162 relevant research, and to comply with locally relevent law 163 enforcement or regulatory requirements (high risk, high priority) 165 o Implement QNAME minimisation in all steps of recursion (medium 166 risk, medium priority) 168 o Minimize the need for recursion through aggressive caching (medium 169 risk, medium priority) *NOTING THAT CACHING IS CONTINGENT ON AUTH 170 RR TTLs - SO IS THIS REALLY A REQUIREMENT?* 172 o Each implementing party should be able to independently take steps 173 to meet requirements without the need for close coordination (e.g. 174 loosely coupled) (low risk, high priority) 176 o The legacy unencrypted DNS protocol (e.g. UDP/TCP port 53) MUST 177 be supported in parallel to DoT (high risk, high priority) 179 o Recursive resolvers SHOULD opportunistically upgrade recursive 180 query transmissions to DoT when an authoritative server is 181 detected to support DoT (high risk, high priority) 183 WG DISCUSS: What about DNSSEC validation? WG DISCUSS: Risk levels 184 and prioritization (see also below) WG DISCUSS: Provisioning impacts 185 - operators and vendors say implementation must be zero-provisioning 187 4.1. Prioritization of Requirements 189 The core requirements above each have varying levels of risk and so 190 can be prioritized based on that risk. As a result, the highest risk 191 area is the one that involves the greatest potential for surveillance 192 and modification based on the details of the specific step of 193 recursion. This suggests the highest risk and thus highest priority 194 is between a recursive server and first level authoritative server. 195 Lower risks are to TLDs and root servers, with correspondingly lower 196 priority. Support for monitoring and compliance are also high risk 197 since this is operationally critical, and thus should also be 198 considered high priority. 200 4.2. Opportunistic Upgrade to Encryption 202 Opportunistically upgrading to use encryption when it is supported 203 has been the best practice for deploying encryption, such as when web 204 browsers upgrade to use TLS connections. This enables deployment to 205 occur incrementally and without tighly coupled coordination across a 206 diverse global group of very different potential implementors. As 207 such it is a good method to use here was well. 209 The exact method by which a recursive resolver determines whether an 210 authoritative server supports DoT has not been specified in this 211 document. But it seems reasonable to imagine that a recursive server 212 might be able to probe authoritative servers on TCP/853 using the DoT 213 protocol and then build a cached list of servers that support DoT so 214 that subsequent queries will upgrade to use DoT (and can fallback if 215 DoT connections subsequently fail). It seems also possible to 216 imagine a method might exist for an authoritative domain to use a TBD 217 resource record or other method to specify whether DoT is supported. 219 4.3. Detection of Availability 221 EDITORIAL NOTE: This section was just moved up. May need some better 222 integration later on. 224 Recursive resolvers typically communicate with many authoritative 225 nameservers. Not every authorititative nameserver will support DoT 226 and not every recursive resolver will support every requirement. How 227 should a recursive resolver determine whether DoT is supported for 228 example? (There may be multiple ways, or none) 230 What scope/granularity should such an availability marker have? 232 o by zone ("all authoritative nameservers in the "example.net" zone 233 support private queries from resolvers") 235 o by identified nameserver ("the nameserver "a.ns.example.net" 236 supports private queries from resolvers") 238 o by IP address ("any namservers that resolve to 192.0.2.13 support 239 private queries from resolvers") 241 Note that if there is no signal for availability, recursors could 242 still opportunistically try the DNS privacy mechanism, as this is 243 employed by some stub resolvers when they contact their designated 244 recursors. 246 Should a signal of availability also indicate a preference for 247 privacy over availability? i.e., are there distinct ways to signal 248 "DNS-privacy is available" separately from "Only contact this server 249 via DNS-privacy if you understand this signal (though we may continue 250 to support non-private DNS queries for clients that don't understand 251 it)". 253 4.4. Resistance to Downgrade Attack 255 When a connection is opportunistically upgraded to DoT, if a fallback 256 to unencrypted DNS can be possible via a downgrade attack by blocking 257 or modifying TCP/853 communications. In such cases, it may be best 258 to establish a mechanism whereby the authoritative domain can specify 259 their preferred behaviour. This may range from only use DoT and do 260 not fallback to unencrypted DNS, to opportunistically use DoT but 261 fallback in failure, to do not use DoT. The email application layer 262 protocols have similar methods for asserting how email from a 263 particular domain should be treated, so following some of the lessons 264 learned there is likely a good idea. Compare HSTS [RFC6797]? 266 4.5. End-User Policy Propagation 268 EDITORIAL NOTE: This section was just moved up. May need some better 269 integration later on. 271 Like any multi-party protocol (e.g. SMTP), the end user's 272 preferences or policies might or might not be respected by later hops 273 in the chain. But if we have a way to express those preferences, we 274 offer cooperating resolvers at least an opportunity to respect them. 276 WG DISCUSS: Is it better to let auth domains assert whether fallback 277 should be permitted or is that an end user preference or both? The 278 email world might suggest the former while the DNSSEC world the 279 latter. Or specify the standardization of the preferences and their 280 communication and leave it to implementors to decide whether or how 281 to treat those signals? 282 What sorts of preferences or policy might an end-user want to 283 express? for example: 285 o do not identify my general location (e.g. don't send my subnet 286 information (ECS) [RFC7871] data about me when talking to 287 authoritative servers), accepting that reduced localization may 288 result in less localized responses from authoritative Content 289 Delivery Network (CDN) servers and thus slower access to content 291 o prefer DNS privacy over reduced latency (i.e., do not try to do 292 speedups - try opportunistic privacy first and fall back to 293 cleartext only if that fails) 295 o never do non-private authoritative queries on my behalf (for any 296 external queries you need to do to resolve this request, require 297 strict, well-authenticated DNS privacy) 299 How specifically are these preferences be expressed by the client? 300 (e.g. new EDNS0 [RFC6891] options?) Should the recursor have a way 301 to indicate whether: 303 o they are capable of honoring them? 305 o they intend to honor them? 307 o they _did_ honor them over the course of a specific lookup? 309 If a resolver merely forwards a request to another recursor, should 310 it also propagate those preferences/policy? if so, how? 312 This seems similar to [I-D.ietf-uta-smtp-require-tls]. 314 5. Perspectives and Use Cases 316 The DNS resolving process involves several entities. These entities 317 have different interests/requirements, and hence it does make sense 318 to examine the interests of those entities separately - though in 319 many cases their interests are aligned. Four different entities can 320 be identified, and their interests are described in the following 321 sections: 323 o Users 325 o Operators 327 o Implementors / Software Developers 329 o Researchers 331 5.1. The User Perspective and Use Cases 333 The privacy and confidentiality of Users (that is, users as in 334 clients of recursive resolvers, which in turn forward/resolve the 335 user's DNS requests by contacting authoritative servers) can be 336 improved in several ways. We call this "minimisation of exposure", 337 and there are currently three ways to reduce that exposure: 339 o Qname minimisation [RFC7816], reducing the amount of information 340 which is absolutely necessary to resolve a query 342 o Aggressive NSEC/local auth cache [RFC8198], reducing the amount of 343 outgoing queries in the first place 345 o Encryption, removing exposure of information while in transit 347 As recursors typically forwards queries received from the user to 348 authoritative servers. This creates a transitive trust between the 349 user and the recursor, as well as the authoritive server, since 350 information created by the user is exposed to the authoritative 351 server. However, the user has never a chance to identify which data 352 was exposed to which authoritative party (via which path). 354 Also, Users would want to be informed about the status of the 355 connections which were made on their behalf, which adds a fourth 356 point 358 Encryption/privacy status signaling 360 *TODO*: Actual requirements - what do users "want"? Start below: 362 5.2. The Operator Perspective and Use Cases 364 Operators of authoritative services have to provide stable and fast 365 DNS services, and interact with a wide range of clients, not all of 366 them authoritative servers. The operator side actually consists of 367 two sides: 369 o The "upstream" facing side of recursive resolvers 371 o The "downstream" side of authoritative servers 373 Those two sides are typically operated by different entities, but 374 many entities operate "both sides". Even though that is discouraged 375 (*TODO* source), the two sides might even be operated on the same 376 nameserver. 378 o Maybe different technical perspectives for operators 379 * Intelligence (sharing information) 381 * SLD popularity for marketing 383 o Focus initially on Second Level Domains (SLDs) initially 385 * Is there a difference for TLDs vs. SLDs from a "protocol" 386 perspective? 388 o Monitoring and aggregated data analysis 390 o Signaling provisioning information 392 * New record type for finding authoritative server key and 393 authentication? Use SRV? (Being able to use different servers 394 for serving up DNS-over-{TCP,UDP} vs DNS-over-TLS responses may 395 be valuable. 397 * Signal secure transport details (DNS-over-TLS, DNS-over-QUIC, 398 EncryptedSNI, connectionless, etc.), perhaps in an extensible 399 manner? Minimize RTTs and reduce need for trials. 401 * Large provider use cases where the NS names are out of 402 bailiwick for the zone (e.g. small number of distinct NS 403 records serving 100k+ zones) 405 o EDNS client subnet (JL: Not sure ECS crosses the cost/benefit 406 threshold to be included as a requirement and many CDNs that run 407 auth servers will likely say ECS is quite operationally important) 409 o Decide between TLS and connectionless (such as COSE-based 410 messages) 412 o Costs of TLS connection vs. connectionless 414 * Technical solution, e.g. encryption of the DNS query, shouldn't 415 enable an attack vector for DDoS or resource exhaustion. For 416 example, only if the client uses DNS-over-TLS, the upstream 417 query to the authoritative will be over DNS-over-TLS also. If 418 the client uses UDP, the resolver won't invest resources in 419 DNS-over-TLS to prevent a potential resource exhaustion attack. 421 * Reuse connection state (if any) and examine resumption 422 considerations 424 * Minimize server-side state (eg, with session tickets) 426 * Need empirical studies on capacity, traffic, attack vectors 427 * Evaluate impact on architecture and footprint expansion 429 * Analyze optimal persistent connection time/time-out 431 * Analyze optimal number of persistent connections recursive 432 resolvers should maintain 434 * Consider operational concerns with respect to capabilities 435 signaling 437 * Develop a profile that has operational advantages for operators 439 *TODO*: Actual requirements - what do operators "want"? 441 5.3. The Implementor / Software Vendor Perspective and Use Cases 443 Implementer requirements follows requirements from user and operator 444 perspectives: 446 o Non-functional requirements, e.g. diversity of implementations 448 o Horizontal vs. vertical scaling, for example similar to http 449 servers 451 o Use of DANE [RFC6698] for authentication: strict vs. opportunistic 453 o Incremental deployment 455 o Cache reuse vs. downgrade? Does the cache need to be partitioned? 456 When can an in-cache answer retrieved via cleartext be served 457 encrypted to a recursive query? 459 o (Use of TCP fast open) - but this might be a requirement for the 460 actual encryption protocol 462 *TODO*: Actual requirements of implementors - essentially, they 463 follow what Operators need? 465 5.4. Performance and Efficiency 467 o Can authoritative server operators limit resource-exhaustion 468 attacks against private DNS mechanisms from having an impact on 469 traditional (non-private) authoritative DNS availability? (JL: 470 seems easy to implement per host connection limits and implement 471 other standard DDoS protections - again for a later BCP doc) 473 o What are best practices for authoritative server operators that 474 can minimize latency and unavailability? 476 o What are best practices for recursors? 478 6. Security Considerations 480 At this point of the document, the authors have not yet discussed 481 security considerations in detail, as the whole document tends to 482 deal with user privacy, which can be considered part of security. :) 484 7. IANA Considerations 486 This document has no actions for IANA. 488 8. Changelog 490 Note to RFC editor: Remove this entire section before publication. 492 8.1. lmo-dprive-phase2-requirements-00 494 Initial version 496 9. References 498 9.1. Normative References 500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 501 Requirement Levels", BCP 14, RFC 2119, 502 DOI 10.17487/RFC2119, March 1997, 503 . 505 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 506 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 507 May 2017, . 509 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 510 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 511 January 2019, . 513 9.2. Informative References 515 [I-D.ietf-uta-smtp-require-tls] 516 Fenton, J., "SMTP Require TLS Option", draft-ietf-uta- 517 smtp-require-tls-09 (work in progress), August 2019. 519 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 520 of Named Entities (DANE) Transport Layer Security (TLS) 521 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 522 2012, . 524 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 525 Transport Security (HSTS)", RFC 6797, 526 DOI 10.17487/RFC6797, November 2012, 527 . 529 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 530 for DNS (EDNS(0))", STD 75, RFC 6891, 531 DOI 10.17487/RFC6891, April 2013, 532 . 534 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 535 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 536 . 538 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 539 Kumari, "Client Subnet in DNS Queries", RFC 7871, 540 DOI 10.17487/RFC7871, May 2016, 541 . 543 [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of 544 DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, 545 July 2017, . 547 9.3. URIs 549 [1] https://datatracker.ietf.org/doc/charter-ietf-dprive/ 551 [2] https://datatracker.ietf.org/wg/dprive/about/ 553 Acknowledgments 555 TODO 557 Authors' Addresses 559 Jason Livingood 560 Comcast 562 Email: Jason_Livingood@comcast.com 564 Alexander Mayrhofer 565 nic.at GmbH 567 Email: alex.mayrhofer.ietf@gmail.com 568 Benno Overeinder 569 NLnetLabs 571 Email: benno@NLnetLabs.nl