idnits 2.17.1 draft-pp-recursive-authoritative-opportunistic-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 (September 10, 2020) is 1324 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) ** Downref: Normative reference to an Informational RFC: RFC 7435 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 P. Sood 5 Expires: March 14, 2021 Google 6 September 10, 2020 8 Recursive to Authoritative DNS with Opportunistic Encryption 9 draft-pp-recursive-authoritative-opportunistic-00 11 Abstract 13 This document describes a method for a DNS recursive resolver to use 14 opportunistic encryption when communicating with authoritative 15 servers. The method here is optional for both the recursive resolver 16 and the authoritative server. A motivating use case for this method 17 is that more encryption on the Internet is better, and opportunistic 18 encryption is better than no encryption at all. Nothing in this 19 method prevents use cases that require better encryption. 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 https://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 14, 2021. 38 Copyright Notice 40 Copyright (c) 2020 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 (https://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. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Use of Opportunistic Encryption . . . . . . . . . . . . . . . 3 59 3. Transport Caches . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Using AUTHINFO Responses for Filling the Transport Cache . . 5 61 4.1. Contacting This Resolver Using DoT . . . . . . . . . . . 5 62 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Registration for dot-ports in the IANA DNS Authoritative 65 Server Information Registry . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 7.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 A recursive resolver using traditional DNS over port 53 may wish 75 instead to use encrypted communication with authoritative servers in 76 order to prevent passive snooping of its DNS traffic. The recursive 77 resolver can use opportunistic encryption (defined in [RFC7435] to 78 achieve this goal. 80 This document describes a method for recursive resolvers to use 81 opportunistic encryption using TLS-based DNS transport such as DNS- 82 over-TLS (DoT, [RFC7858]) with authoritative servers in an efficient 83 manner. It also defines a way for recursive resolvers to get 84 information from authoritative servers about their features and 85 capabilities. 87 1.1. Use Case 89 The use case for the method in this document is recursive resolver 90 operators who are happy to use TLS [RFC8446] encryption with 91 authoritative servers if doing so doesn't significantly slow down 92 getting answers, and authoritative server operators that are happy to 93 use encryption with recursive resolvers if it doesn't cost much. 95 Both parties understand that using encryption costs something, but 96 are willing to absorb the costs for the benefit of more Internet 97 traffic being encrypted. The extra costs (compared to using 98 traditional DNS on port 53) include: 100 o Extra round trips to establish TCP for every session 102 o Extra round trips for TLS establishment 104 o Greater CPU use for TLS establishment 106 o Greater CPU use for encryption after TLS establishment 108 o Greater memory use for holding TLS state 110 1.2. Definitions 112 The terms "recursive resolver" and "authoritative server" are defined 113 in [RFC8499]. 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 2. Use of Opportunistic Encryption 123 [RFC7435] defines opportunistic encryption. In this document, the 124 only difference between normal TLS session establishment and 125 opportunistic encryption is that the the TLS client (the recursive 126 resolver) optionally authenticate the server. In normal TLS, the 127 client is required to authenticate the server and the TLS connection 128 fails if the authentication is not successful. 130 In the opportunistic encryption described here, there is no need for 131 the recursive resolver to authenticate the authoritative server 132 because any authentication failure MUST be ignored. If it is easier 133 programmatically for the recursive resolver to authenticate the 134 authoritative server and then ignore the result than to just not 135 authenticate, the recursive resolver MAY do that. 137 Note that different protocols for encrypted resolver-to-authoritative 138 communication might to require normal TLS authentication. Because of 139 this, authoritative servers SHOULD use TLS certificates that can be 140 used in normal TLS authentication, such as those issued by trusted 141 third parties or self-issued certificates that can be authenticated 142 in other ways, such as with DANE [RFC6698] records. However, if an 143 authoritative server does not care about the use cases for such 144 future protocols, it MAY use self-issued certificates that cannot be 145 authenticated. 147 3. Transport Caches 149 A recursive resolver that attempted to use encrypted transport every 150 time it connected to any authoritative server would inherently be 151 slower than one that did not. Similarly, a recursive resolver that 152 made an external lookup of what secure transports every authoritative 153 server supports each time it connected would also inherently be 154 slower than one that did not. Recursive resolver operators desire to 155 give answers to stub resolvers as quickly as possible, so neither of 156 these two strategies would make sense. 158 Instead, recursive resolvers following the method described in this 159 document MUST keep a cache of what they know about the secure 160 transports supported by authoritative servers. This is called a 161 "transport cache" in this document. 163 The recursive resolver MUST look in its transport cache before 164 sending DNS queries to an authoritative server. If there is no entry 165 for an authoritative server in its transport cache, the recursive 166 resolver MUST use plain, unencrypted DNS over port 53. 168 This document explicitly does not mandate the contents of the 169 transport cache. Different recursive resolver implementers are 170 likely to have different cache structures based on many factors, such 171 as research results, active measurements, and customer feedback, 172 There will likely be different strategies for the time-to-live for 173 parts of the transport cache, such as how often to refresh the data 174 in the cache, how often to refresh negative data, whether to 175 prioritize refreshing certain zones or types of zones, and so on. 177 This document also explicitly doesn't mandate how the strategy for 178 filling transport caches. Some strategies might include one or more 179 of "try to send a refresh query over DoT", "use external data", 180 "trust a third-party service for filling the transport cache", and so 181 on. 183 There are no interoperability issues with different implementors 184 making different choices for the contents and fill strategies of 185 their transport caches, and having many different options available 186 will likely cause the cache designs to get better over time. 188 4. Using AUTHINFO Responses for Filling the Transport Cache 190 As described above, one of the mechanisms that a recursive resolver 191 might use to fill its transport cache is to use external data that 192 might give the resolver relevant data about possible transports. 193 This section defines how to use AUTHINFO RRtypes (defined in 194 [I-D.pp-dnsop-authinfo]) for that purpose. This document defines two 195 entries for the IANA DNS Authoritative Server Information Registry 196 that is defined in [I-D.pp-dnsop-authinfo]. 198 4.1. Contacting This Resolver Using DoT 200 The "dot-ports" name is used to specify the port(s) that can be used 201 by the recursive resolver for DoT queries. The value MUST be an 202 array of port numbers. Each element of the array in the value is a 203 JSON number. 205 The value of "dot-ports" is an array of numbers instead of just one 206 number because an authoritative server might support DoT on more than 207 one port. The order of the elements in the array has no meaning; 208 that is, the array could instead be considered a set. 210 The array in the value can be empty, which indicates that the 211 authoritative server does not offer DoT service. An empty array and 212 the absence of a name/value pair for "dot-ports" have identical 213 meanings. 215 4.2. Examples 217 An authoritative server can be reached at "ns32.example.com" and the 218 IP address 192.0.2.222. It offers offers DoT service on the default 219 port. It's response to the AUTHINFO query might be: 221 { "dot-ports": [ 853 ] } 223 5. IANA Considerations 225 5.1. Registration for dot-ports in the IANA DNS Authoritative Server 226 Information Registry 228 Name: dot-ports 230 Value type: Array of numbers 232 Specification: This document, Section 4.1 234 6. Security Considerations 236 The method described in this document explicitly allows a stub to 237 perform DNS communications over traditional unencrypted, 238 unauthenticated DNS on port 53. 240 The method described in this document explicitly allows a stub to 241 choose to allow unauthenticated TLS. In this case, the resulting 242 communication will be susceptible to obvious and well-understood 243 attacks from an attacker in the path of the communications. 245 7. References 247 7.1. Normative References 249 [I-D.pp-dnsop-authinfo] 250 Hoffman, P. and P. Sood, "Reporting Information from DNS 251 Authoritative Servers", draft-pp-dnsop-authinfo-00 (work 252 in progress), September 2020. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 260 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 261 December 2014, . 263 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 264 and P. Hoffman, "Specification for DNS over Transport 265 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 266 2016, . 268 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 269 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 270 May 2017, . 272 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 273 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 274 . 276 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 277 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 278 January 2019, . 280 7.2. Informative References 282 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 283 of Named Entities (DANE) Transport Layer Security (TLS) 284 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 285 2012, . 287 Authors' Addresses 289 Paul Hoffman 290 ICANN 292 Email: paul.hoffman@icann.org 294 Puneet Sood 295 Google 297 Email: puneets@google.com