idnits 2.17.1 draft-pp-recursive-authoritative-opportunistic-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 : ---------------------------------------------------------------------------- ** 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 (19 November 2020) is 1247 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 19 November 2020 5 Expires: 23 May 2021 7 Recursive to Authoritative DNS with Opportunistic Encryption 8 draft-pp-recursive-authoritative-opportunistic-02 10 Abstract 12 This document describes a use case and a method for a DNS recursive 13 resolver to use opportunistic encryption when communicating with 14 authoritative servers. A motivating use case for this method is that 15 more encryption on the Internet is better, and opportunistic 16 encryption is better than no encryption at all. The method here is 17 optional for both the recursive resolver and the authoritative 18 server. Nothing in this method prevents use cases and methods that 19 require authenticated 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 23 May 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Use Case . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Method for Opportunistic Encryption . . . . . . . . . . . . . 3 58 3. Transport Caches . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 A recursive resolver using traditional DNS over port 53 may wish 69 instead to use encrypted communication with authoritative servers in 70 order to prevent passive snooping of its DNS traffic. The recursive 71 resolver can use opportunistic encryption (defined in [RFC7435] to 72 achieve this goal. 74 This document describes a use case and a method for recursive 75 resolvers to use opportunistic encryption. The use case is described 76 in Section 1.1. The method uses DNS-over-TLS [RFC7858] with 77 authoritative servers in an efficient manner. 79 1.1. Use Case 81 The use case in this document is recursive resolver operators who are 82 happy to use TLS [RFC8446] encryption with authoritative servers if 83 doing so doesn't significantly slow down getting answers, and 84 authoritative server operators that are happy to use encryption with 85 recursive resolvers if it doesn't cost much. 87 Both parties understand that using encryption costs something, but 88 are willing to absorb the costs for the benefit of more Internet 89 traffic being encrypted. The extra costs (compared to using 90 traditional DNS on port 53) include: 92 * Extra round trips to establish TCP for every session 94 * Extra round trips for TLS establishment 96 * Greater CPU use for TLS establishment 98 * Greater CPU use for encryption after TLS establishment 100 * Greater memory use for holding TLS state 102 1.2. Definitions 104 The terms "recursive resolver" and "authoritative server" are defined 105 in [RFC8499]. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 2. Method for Opportunistic Encryption 115 [RFC7435] defines opportunistic encryption. The method described 116 here uses DNS-over-TLS [RFC7858] between resolvers and authoritative 117 servers. 119 In this document, the only difference between normal TLS session 120 establishment and opportunistic encryption is that the the TLS client 121 (the recursive resolver) optionally authenticates the server. In 122 normal TLS, the client is required to authenticate the server and the 123 TLS connection fails if the authentication is not successful. 125 [[ The following might be changed. A possible use case to be added, 126 depending on WG discussion, would be optional authentication in order 127 for caches to promote parent-side NS records to a higher standing 128 than they currently have in the caches. ]] 130 In the opportunistic encryption described here, there is no need for 131 the recursive resolver to authenticate the authoritative server 132 because any certificate authentication failure does not cause the TLS 133 session from being set up. Note that other authentication failures 134 in TLS, such as incorrect algorithm choices or TLS record failures, 135 MUST cause the TLS session from being set up. If it is easier 136 programmatically for the recursive resolver to authenticate the 137 authoritative server and then ignore the negative result for 138 certificate authentication, than to just not authenticate, the 139 recursive resolver MAY do that. The recursive resolver MAY note a 140 certificate authentication failure and act on it (such as by logging 141 it or noting it in the cache), as long as the failure does not 142 prevent the TLS session from completing. 144 Note that later protocols for encrypted resolver-to-authoritative 145 communication might to require normal TLS authentication. Because of 146 this, authoritative servers SHOULD use TLS certificates that can be 147 used in authenticated TLS authentication, such as those issued by 148 trusted third parties or self-issued certificates that can be 149 authenticated with DANE [RFC6698] records. However, if an 150 authoritative server does not care about the use cases for such 151 future protocols, it MAY use self-issued certificates that cannot be 152 authenticated. 154 3. Transport Caches 156 [[ Because this section probably applies to use cases for 157 authenticated encryption as well, it should probably be moved to a 158 separate document. ]] 160 A recursive resolver that attempted to use encrypted transport every 161 time it connected to any authoritative server would inherently be 162 slower than one that did not. Similarly, a recursive resolver that 163 made an external lookup of what secure transports every authoritative 164 server supports each time it connected would also inherently be 165 slower than one that did not. Recursive resolver operators desire to 166 give answers to stub resolvers as quickly as possible, so neither of 167 these two strategies would make sense. 169 Instead, recursive resolvers following the method described in this 170 document MUST keep a cache of relevant information about how DNS- 171 over-TLS is supported by authoritative servers. This is called a 172 "transport cache" in this document. The relevant information could 173 include things such as support for encryption, authentication 174 information such as public keys discovered from TLSA records, which 175 records in a server's NS RRset support DNS-over-TLS, and so on. 176 Future specifications might describe how to use other secure DNS 177 transports for encryption, and thus would also have to describe ways 178 that a resolver could discover whether an authoritative server 179 supports them. 181 This document only DNS-over-TLS for encryption. Thus, a recursive 182 resolver can test whether an authoritative server supports DNS-over- 183 TLS by attempting to open a TLS session on port 853 or through 184 discovery of appropriate TLSA records (to be described later and/or 185 in different documents). The transport cache should store both 186 positive and negative information about whether the authoritative 187 server supports DNS-over-TLS and about authentication uses by 188 particular name servers. 190 The recursive resolver MUST look in its transport cache before 191 sending DNS queries to an authoritative server. If there is no entry 192 for an authoritative server in its transport cache, the recursive 193 resolver MUST use plain, unencrypted DNS over port 53. It MAY then 194 probe for encrypted transports, and cache that information for later 195 connections. 197 This document explicitly does not mandate the contents of the 198 transport cache. Different recursive resolver implementers are 199 likely to have different cache structures based on many factors, such 200 as research results, active measurements, secure protocols supported, 201 and customer feedback, There will likely be different strategies for 202 the time-to-live for parts of the transport cache, such as how often 203 to refresh the data in the cache, how often to refresh negative data, 204 whether to prioritize refreshing certain zones or types of zones, and 205 so on. 207 This document also explicitly doesn't mandate how the strategy for 208 filling transport caches. Some strategies might include one or more 209 of "try to send a refresh query over DoT", "use external data", 210 "trust a third-party service for filling the transport cache", and so 211 on. 213 There are no interoperability issues with different implementors 214 making different choices for the contents and fill strategies of 215 their transport caches, and having many different options available 216 will likely cause the cache designs to get better over time. 218 4. Security Considerations 220 The method described in this document explicitly allows a stub to 221 perform DNS communications over traditional unencrypted, 222 unauthenticated DNS on port 53. 224 The method described in this document explicitly allows a stub to 225 choose to allow unauthenticated TLS. In this case, the resulting 226 communication will be susceptible to obvious and well-understood 227 attacks from an attacker in the path of the communications. 229 5. Acknowledgements 231 Puneet Sood contributed many ideas to early drafts of this document. 233 6. References 235 6.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 243 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 244 December 2014, . 246 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 247 and P. Hoffman, "Specification for DNS over Transport 248 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 249 2016, . 251 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 252 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 253 May 2017, . 255 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 256 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 257 . 259 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 260 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 261 January 2019, . 263 6.2. Informative References 265 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 266 of Named Entities (DANE) Transport Layer Security (TLS) 267 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 268 2012, . 270 Author's Address 272 Paul Hoffman 273 ICANN 275 Email: paul.hoffman@icann.org