idnits 2.17.1 draft-ietf-dprive-unauth-to-authoritative-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 abstract seems to contain references ([FULL-AUTH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (16 June 2021) is 1045 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-pp-dprive-common-features-01 == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-03 == Outdated reference: A later version (-10) exists of draft-ietf-dnsop-rfc8499bis-01 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-06 == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 Summary: 1 error (**), 0 flaws (~~), 7 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: Experimental P. van Dijk 5 Expires: 18 December 2021 PowerDNS 6 16 June 2021 8 Recursive to Authoritative DNS with Unauthenticated Encryption 9 draft-ietf-dprive-unauth-to-authoritative-02 11 Abstract 13 This document describes a use case and a method for a DNS recursive 14 resolver to use unauthenticated encryption when communicating with 15 authoritative servers. The motivating use case for this method is 16 that more encryption on the Internet is better, and some resolver 17 operators believe that unauthenticated encryption is better than no 18 encryption at all. The method described here is optional for both 19 the recursive resolver and the authoritative server. This method 20 supports unauthenticated encryption using the same mechanism for 21 discovery of encryption support for the server as [FULL-AUTH]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 18 December 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Use Case for Unauthenticated Encryption . . . . . . . . . 3 58 1.2. Summary of Protocol . . . . . . . . . . . . . . . . . . . 3 59 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Discovering Whether an Authoritative Server Uses 61 Encryption . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Resolving with Encryption . . . . . . . . . . . . . . . . . . 5 63 3.1. Resolver Session Failures . . . . . . . . . . . . . . . . 5 64 4. Serving with Encryption . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 limit snooping of its DNS traffic by passive or on-path 78 attackers. The recursive resolver can use unauthenticated encryption 79 (defined in [OPPORTUN]) to achieve this goal. 81 This document describes the use case for unauthenticated encryption 82 in recursive resolvers in Section 1.1. The encryption method with 83 authoritative servers can be DNS-over-TLS [DNSOTLS] (DoT), DNS-over- 84 HTTPS [DNSOHTTPS] (DoH), and/or DNS-over-QUIC [DNSOQUIC] (DoQ), as 85 described in Section 3. 87 The document also describes a discovery method that shows if an 88 authoritative server supports encryption in Section 2. 90 See [FULL-AUTH] for a description of the use case and a proposed 91 mechanism for fully-authenticated encryption. See [COMMON] for a 92 definition of the features that are in common between this document 93 and [FULL-AUTH]. 95 NOTE: The draft uses the SVCB record as a discovery mechanism for 96 encryption by a particular authoritative server. Any record type 97 that can show multiple types of encryption (currently DoT, DoH, and 98 DoQ) can be used for discovery. Thus, this record type might change 99 in the future, depending on the discussion in the DPRIVE WG. 101 1.1. Use Case for Unauthenticated Encryption 103 The use case in this document for unauthenticated encryption is 104 recursive resolver operators who are happy to use encryption with 105 authoritative servers if doing so doesn't significantly slow down 106 getting answers, and authoritative server operators that are happy to 107 use encryption with recursive resolvers if it doesn't cost much. In 108 this use case, resolvers do not want to return an error for requests 109 that were sent over an encrypted channel if they would have been able 110 to give a correct answer using unencrypted transport. 112 Resolvers and authoritative servers understand that using encryption 113 costs something, but are willing to absorb the costs for the benefit 114 of more Internet traffic being encrypted. The extra costs (compared 115 to using traditional DNS on port 53) include: 117 * Extra round trips to establish TCP for every session (but not 118 necessarily for every query) 120 * Extra round trips for TLS establishment 122 * Greater CPU use for TLS establishment 124 * Greater CPU use for encryption after TLS establishment 126 * Greater memory use for holding TLS state 128 This use case is not expected to apply to all resolvers or 129 authoritative servers. For example, according to [RSO_STATEMENT], 130 some root server operators do not want to be the early adopters for 131 DNS with encryption. The protocol in this document explicitly allows 132 authoritative servers to signal when they are ready to begin offering 133 DNS with encryption. 135 1.2. Summary of Protocol 137 This summary gives an overview of how the parts of the protocol work 138 together. 140 * The resolver discovers whether any authoritative server of 141 interest supports DNS with encryption by querying for the SVCB 142 records [SVCB]. As described in [DNS-SVCB], SVCB records can 143 indicate that a server supports encrypted transport of DNS 144 queries. 146 NOTE: In this document, the term "SVCB record" is used _only_ for 147 SVCB records that indicate encryption as described in [DNS-SVCB]. 148 SVCB records that do not have these indicators in the RDATA are 149 not included in the term "SVCB record" in this document. 151 * The resolver uses any authoritative server with a SVCB record that 152 indicates encryption to perform unauthenticated encryption. 154 * The resolver does not fail to set up encryption if the 155 authentication in the TLS session fails. 157 1.3. Definitions 159 The terms "recursive resolver", "authoritative server", and "classic 160 DNS" are defined in [DNS-TERM]. 162 "DNS with encryption" means transport of DNS over any of DoT, DoH, or 163 DoQ. A server that supports DNS with encryption supports transport 164 over one or more of DoT, DoH, or DoQ. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in BCP 169 14 [MUSTSHOULD1] [MUSTSHOULD2] when, and only when, they appear in 170 all capitals, as shown here. 172 2. Discovering Whether an Authoritative Server Uses Encryption 174 A recursive resolver discovers whether an authoritative server 175 supports DNS with encryption by using the discovery mechanism 176 described in Section 2.1 of [COMMON]. A resolver MAY also use port 177 probing, although the mechanism for that is not described here. 179 If the cache has no positive or negative answers for any SVCB record 180 for any of a zone's authoritative servers, the resolver MAY send 181 queries for the SVCB records (and for the A/AAAA records of names 182 mentioned in those SVCB records) for some or all of the zone's 183 authoritative servers and wait for a positive response so that the 184 resolver can use DNS with encryption for the original query. In this 185 situation, the resolver MAY instead just use classic DNS for the 186 original query but simultaneously queue queries for the SVCB (and 187 subsequent A/AAAA) records for some or all of the zone's 188 authoritative servers so that future queries might be able to use DNS 189 with encryption. 191 DNSSEC validation of SVCB RRsets used strictly for this discovery 192 mechanism is not mandated. 194 3. Resolving with Encryption 196 A resolver following this protocol processes the discovery response 197 using the processing mechanism described in [COMMON]. 199 A resolver following this protocol does not need to authenticate TLS 200 servers. Thus, when setting up a TLS connection, if the server's 201 authentication credentials do not match those expected by the 202 resolver, the resolver continues with the TLS connection. Privacy- 203 oriented resolvers (defined in [PRIVACY-REC]) following this protocol 204 MUST NOT indicate that they are using encryption because this 205 protocol is susceptible to on-path attacks. 207 3.1. Resolver Session Failures 209 The following are some of the reasons that a DNS with encryption 210 session might fail to be set up: 212 * The resolver receives a TCP RST response 214 * The resolver does not receive replies to TCP or TLS setup (such as 215 getting the TCP SYN message, the first TLS message, or completing 216 TLS handshakes) 218 * The TLS handshake gets a definitive failure 220 * The encrypted session fails for reasons other than for 221 authentication, such as incorrect algorithm choices or TLS record 222 failures 224 4. Serving with Encryption 226 An authoritative server following this protocol publishes the 227 discovery records using the serving mechanism described in [COMMON]. 229 5. IANA Considerations 231 Relevant IANA considerations are covered in [COMMON]. 233 6. Security Considerations 235 The method described in this document explicitly allows a resolver to 236 perform DNS communications over traditional unencrypted, 237 unauthenticated DNS on port 53, if it cannot find an authoritative 238 server that advertises that it supports encryption. The method 239 described in this document explicitly allows a resolver using 240 encryption to choose to allow unauthenticated encryption. In either 241 of these cases, the resulting communication will be susceptible to 242 obvious and well-understood attacks from an attacker in the path of 243 the communications. 245 7. Acknowledgements 247 Puneet Sood contributed many ideas to early drafts of this document. 249 The DPRIVE Working Group has contributed many ideas that keep 250 shifting the focus and content of this document. 252 8. References 254 8.1. Normative References 256 [COMMON] Dijk, P. V. and P. Hoffman, "Common Features for Encrypted 257 Recursive to Authoritative DNS", Work in Progress, 258 Internet-Draft, draft-pp-dprive-common-features-01, 19 May 259 2021, . 262 [DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers", 263 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 264 03, 19 April 2021, . 267 [DNS-TERM] Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 268 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-01, 269 20 November 2020, . 272 [FULL-AUTH] 273 Pauly, T., Rescorla, E., Schinazi, D., and C. A. Wood, 274 "Signaling Authoritative DNS Encryption", Work in 275 Progress, Internet-Draft, draft-rescorla-dprive-adox- 276 latest-00, 26 February 2021, 277 . 280 [MUSTSHOULD1] 281 Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, 284 . 286 [MUSTSHOULD2] 287 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 [OPPORTUN] Dukhovni, V., "Opportunistic Security: Some Protection 292 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 293 December 2014, . 295 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 296 and parameter specification via the DNS (DNS SVCB and 297 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 298 dnsop-svcb-https-06, 16 June 2021, 299 . 302 8.2. Informative References 304 [DNSOHTTPS] 305 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 306 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 307 . 309 [DNSOQUIC] Huitema, C., Mankin, A., and S. Dickinson, "Specification 310 of DNS over Dedicated QUIC Connections", Work in Progress, 311 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 312 2021, . 315 [DNSOTLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 316 and P. Hoffman, "Specification for DNS over Transport 317 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 318 2016, . 320 [PRIVACY-REC] 321 Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 322 A. Mankin, "Recommendations for DNS Privacy Service 323 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 324 October 2020, . 326 [RSO_STATEMENT] 327 "Statement on DNS Encryption", 2021, . 330 Authors' Addresses 332 Paul Hoffman 333 ICANN 335 Email: paul.hoffman@icann.org 337 Peter van Dijk 338 PowerDNS 340 Email: peter.van.dijk@powerdns.com