idnits 2.17.1 draft-pp-recursive-authoritative-opportunistic-04.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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 January 2021) is 1197 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 (-10) exists of draft-ietf-dnsop-rfc8499bis-01 ** Downref: Normative reference to an Informational RFC: RFC 7435 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-01 Summary: 2 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 P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track 13 January 2021 5 Expires: 17 July 2021 7 Recursive to Authoritative DNS with Opportunistic Encryption 8 draft-pp-recursive-authoritative-opportunistic-04 10 Abstract 12 This document describes a use case and a method for a DNS recursive 13 resolver to use opportunistic encryption (that is, encryption with 14 optional authentication) when communicating with authoritative 15 servers. The motivating use case for this method is that more 16 encryption on the Internet is better, and opportunistic encryption is 17 better than no encryption at all. The method here is optional for 18 both the recursive resolver and the authoritative server. Nothing in 19 this method prevents use cases and methods that can use, or require, 20 authenticated encryption. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 17 July 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Summary of Protocol . . . . . . . . . . . . . . . . . . . 3 58 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Method for Opportunistic Encryption . . . . . . . . . . . . . 4 60 2.1. Resolvers . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Authoritative Servers . . . . . . . . . . . . . . . . . . 5 62 3. Discovering Whether an Authoritative Server Uses 63 Encryption . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. The Transport Cache . . . . . . . . . . . . . . . . . . . . . 6 65 5. Authentication . . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 A recursive resolver using traditional DNS over port 53 may wish 76 instead to use encrypted communication with authoritative servers in 77 order to prevent passive snooping of its DNS traffic. The recursive 78 resolver can use opportunistic encryption (defined in [RFC7435] to 79 achieve this goal. 81 This document describes a use case and a method for recursive 82 resolvers to use opportunistic encryption. The use case is described 83 in Section 1.1. The method uses DNS-over-TLS [RFC7858] (DoT) with 84 authoritative servers in an efficient manner; it is called "ADoT", as 85 described in [I-D.ietf-dnsop-rfc8499bis]. (( A later version of this 86 document will probably also describe the use of DNS-over-QUIC 87 [I-D.ietf-dprive-dnsoquic] (DoQ). )) 89 Because opportunistic encryption means encryption with optional 90 authentication, a resolver using the mechanism described here could 91 achieve authenticated encryption with some authoritative servers, 92 depending on how authentication for ADoT is defined. To date, there 93 have been no definition of how a resolver can take advantage of DNS 94 features that require authentication of authoritative servers. If 95 those advantages are defined in the future, this document would need 96 to define the types of authentication for ADoT that would be allowed. 98 1.1. Use Case 100 The use case in this document is recursive resolver operators who are 101 happy to use TLS [RFC8446] encryption with authoritative servers if 102 doing so doesn't significantly slow down getting answers, and 103 authoritative server operators that are happy to use encryption with 104 recursive resolvers if it doesn't cost much. 106 Both parties understand that using encryption costs something, but 107 are willing to absorb the costs for the benefit of more Internet 108 traffic being encrypted. The extra costs (compared to using 109 traditional DNS on port 53) include: 111 * Extra round trips to establish TCP for every session 113 * Extra round trips for TLS establishment 115 * Greater CPU use for TLS establishment 117 * Greater CPU use for encryption after TLS establishment 119 * Greater memory use for holding TLS state 121 1.2. Summary of Protocol 123 This protocol has four main parts. This summary gives an overview of 124 how the work together. 126 * A resolver that uses this protocol has a cache that it uses to 127 know whether to attempt using ADoT with a particular authoritative 128 server, as described in Section 4. 130 * A resolver fills its transport cache by discovering whether any 131 authoritative server of interest uses encrypted DNS, as described 132 in Section 3. 134 * If there is no entry for that server in the cache, or the cache 135 says that the authoritative server doesn't support encrypted 136 transport, the resolver uses classic DNS; otherwise, the resolver 137 attempts to connect to the authoritative server with ADoT, as 138 described in Section 2. 140 * If the TLS session is authenticated and the resolver has use for 141 this authentication, the resolver can mark responses it gets as 142 authenticated, as described in Section 5. If the TLS session is 143 not authenticated, the resolver treats the answers it receives as 144 if they were received over classic DNS. 146 1.3. Definitions 148 The terms "recursive resolver", "authoritative server", "ADoT", and 149 "classic DNS" are defined in [I-D.ietf-dnsop-rfc8499bis]. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 2. Method for Opportunistic Encryption 159 [RFC7435] defines opportunistic encryption. In this document, the 160 only difference between normal TLS session establishment and 161 opportunistic encryption is that the the TLS client (the recursive 162 resolver) optionally authenticates the server. See Section 5 for a 163 fuller description of the use of authentication. 165 2.1. Resolvers 167 A resolver following this protocol uses its transport cache 168 (described in Section 4) to decide whether to use classic DNS or this 169 protocol to contact authoritative servers. If the transport cache 170 indicates that the authoritative server is known to support encrypted 171 DNS, the resolver attempts to connect to it with ADoT on port 853. 173 The resolver is configured with a set of timeouts that it uses when 174 it is setting up ADoT. This document does has suggested values for 175 those timeouts; they are marked here with (( timeout_ )). Resolver 176 software might use these suggested values for defaults, or might 177 choose their own default values. 179 (( The proposed default values here are based on research that I have 180 done but not published. The research is expected to be published 181 before IETF 110. )) 183 The resolver MUST fall back to using classic DNS with a server if any 184 of the following happens when using ADoT: 186 * The resolver receives a TCP RST response 188 * The resolver does not receive a reply to the TCP SYN message 189 within timeout "timeout_syn"; the suggested default is .6 seconds 191 * The resolver does not receive a reply to its first TLS message 192 within timeout "timeout_tls_start"; the suggested default (which 193 includes the TCP startup time) is 2.3 seconds 195 * The TLS handshake gets a definitive failure 197 * The TLS session is set up, but the resolver does not receive a 198 response to its first DNS query in the TLS session within timeout 199 "timeout_dns_answ"; the suggested default is 5 seconds (which 200 includes the TCP and TLS startup times) 202 * The TLS session fails for reasons other than for authentication, 203 such as incorrect algorithm choices or TLS record failures 205 In any of those cases, the resolver needs to update its transport 206 cache to indicate that the server is not currently available over 207 DoT. The time-to-live value for that entry, "timeout_ttl", could be 208 as long as the TTL on the NS RRset. 210 A resolver SHOULD keep a TLS session to a particular server open if 211 it expects to send additional queries to that server in a short 212 period of time, "timeout_hold_open". If the server closes the TLS 213 session, the resolver can re-establish a TLS session of the version 214 of TLS in use allows for session resumption. 216 2.2. Authoritative Servers 218 An authoritative server following this protocol SHOULD support an 219 ADoT service at port 853 for each IP address on which it offers 220 service for classic DNS on port 53. 222 A server MAY close a TLS connection at any time. For example, it can 223 close the TLS session if it has not received a DNS query in a defined 224 length of time, "timeout_dns_query". It can also close the TLS 225 session after it sends a DNS response; however, it might also want to 226 keep the TLS session open waiting for another DNS query from the 227 resolver. 229 3. Discovering Whether an Authoritative Server Uses Encryption 231 A recursive resolver can discover whether an authoritative server 232 supports ADoT by attempting to open a TLS session to port 853 of an 233 IP address for the server. If the server completes the TLS 234 handshake, the resolver can be fairly confident that the server 235 supports ADoT. 237 (( Note that there are likely better ways to do discovery. The 238 DPRIVE WG requested that this version of this draft only specify 239 port-probing. Future drafts might describe other methods, and how to 240 use multiple methods at the same time for discovery, depending on 241 what the WG chooses for discovery. )) 242 The following are indications of failure for the ability to use ADoT 243 with the server: 245 * The resolver receives a TCP RST response 247 * The resolver does not receive a reply to the TCP SYN message 248 within timeout "timeout_syn" 250 * The resolver does not receive a reply to its first TLS message 251 within timeout "timeout_tls_start" 253 * The TLS handshake gets a definitive failure 255 4. The Transport Cache 257 A recursive resolver that attempted to use encrypted transport every 258 time it connected to any authoritative server would inherently be 259 slower than one that did not. Similarly, a recursive resolver that 260 made an external lookup of what secure transports every authoritative 261 server supports each time it connected would also inherently be 262 slower than one that did not. Recursive resolver operators desire to 263 give answers to stub resolvers as quickly as possible, so neither of 264 these two strategies would make sense. 266 Instead, recursive resolvers following the method described in this 267 document MUST keep a cache of relevant information about how DNS- 268 over-TLS is supported by authoritative servers. This is called a 269 "transport cache" in this document. The relevant information could 270 include things such as support for encryption, expected round-trip 271 times, authentication mechanisms, and so on. The transport cache is 272 likely to store both positive and negative information about a 273 server's ability to support encrypted DNS. 275 The recursive resolver MUST look in its transport cache before 276 sending DNS queries to an authoritative server. If there is no entry 277 for an authoritative server in its transport cache, the recursive 278 resolver MUST use classic DNS over port 53. It MAY then probe for 279 encrypted transports, and cache that information for later 280 connections. 282 This document explicitly does not mandate the contents of the 283 transport cache. Different recursive resolver implementers are 284 likely to have different cache structures based on many factors, such 285 as research results, active measurements, secure protocols supported, 286 and customer feedback, There will likely be different strategies for 287 the time-to-live for parts of the transport cache, such as how often 288 to refresh the data in the cache, how often to refresh negative data, 289 whether to prioritize refreshing certain zones or types of zones, and 290 so on. 292 This document also explicitly doesn't mandate the strategy for 293 filling transport caches. Some strategies might include one or more 294 of "test NS entries from the main cache", "try to send a refresh 295 query over ADoT", "use external data", "trust a third-party service 296 for filling the transport cache", and so on. 298 There are no interoperability issues with different implementors 299 making different choices for the contents and fill strategies of 300 their transport caches, and having many different options available 301 will likely cause the cache designs to get better over time. 303 5. Authentication 305 In the opportunistic encryption described here, there is no 306 requirement, and no advantage, for the recursive resolver to 307 authenticate the authoritative server because any certificate 308 authentication failure does not prevent the TLS session from being 309 set up. If it is easier programmatically for the recursive resolver 310 to authenticate the authoritative server and then ignore the negative 311 result for certificate authentication, than to just not authenticate, 312 the recursive resolver MAY do that. 314 This document does not describe what to do with successful 315 authentication of a ADoT TLS session. Some suggestions have been 316 floated in the DPRIVE WG, but none have been written into drafts. If 317 there later are reasons to note authentication of the server, 318 resolvers following this protocol MAY use that authenticated data. (( 319 Change this paragraph if the WG later defines DNS-related reasons to 320 authenticate. )) 322 Later protocols for encrypted resolver-to-authoritative communication 323 might to require normal TLS authentication. Because of this, 324 authoritative servers SHOULD use TLS certificates that can be used in 325 authenticated TLS authentication, such as those issued by trusted 326 third parties or self-issued certificates that can be authenticated 327 with DANE [RFC6698] records. However, if an authoritative server 328 does not care about the use cases for such future protocols, it MAY 329 use self-issued certificates that cannot be authenticated. 331 6. Security Considerations 333 The method described in this document explicitly allows a stub to 334 perform DNS communications over traditional unencrypted, 335 unauthenticated DNS on port 53. 337 The method described in this document explicitly allows a stub to 338 choose to allow unauthenticated TLS. In this case, the resulting 339 communication will be susceptible to obvious and well-understood 340 attacks from an attacker in the path of the communications. 342 7. Acknowledgements 344 Puneet Sood and Peter van Dijk contributed many ideas to early drafts 345 of this document. 347 8. References 349 8.1. Normative References 351 [I-D.ietf-dnsop-rfc8499bis] 352 Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 353 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-01, 354 20 November 2020, . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 363 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 364 December 2014, . 366 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 367 and P. Hoffman, "Specification for DNS over Transport 368 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 369 2016, . 371 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 372 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 373 May 2017, . 375 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 376 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 377 . 379 8.2. Informative References 381 [I-D.ietf-dprive-dnsoquic] 382 Huitema, C., Mankin, A., and S. Dickinson, "Specification 383 of DNS over Dedicated QUIC Connections", Work in Progress, 384 Internet-Draft, draft-ietf-dprive-dnsoquic-01, 20 October 385 2020, . 388 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 389 of Named Entities (DANE) Transport Layer Security (TLS) 390 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 391 2012, . 393 Author's Address 395 Paul Hoffman 396 ICANN 398 Email: paul.hoffman@icann.org