idnits 2.17.1 draft-ietf-dprive-unauth-to-authoritative-01.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 (19 May 2021) is 1074 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-00 == 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-05 == 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: 20 November 2021 PowerDNS 6 19 May 2021 8 Recursive to Authoritative DNS with Unauthenticated Encryption 9 draft-ietf-dprive-unauth-to-authoritative-01 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 20 November 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 . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 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 [COMMON]. A resolver MAY also use port probing, 177 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 for some or all of the zone's 182 authoritative servers and wait for a positive response so that the 183 resolver can use DNS with encryption for the original query. In this 184 situation, the resolver MAY instead just use classic DNS for the 185 original query but simultaneously queue queries for the SVCB records 186 for some or all of the zone's authoritative servers so that future 187 queries might be able to use DNS with encryption. 189 DNSSEC validation of SVCB RRsets used strictly for this discovery 190 mechanism is not mandated. 192 3. Resolving with Encryption 194 A resolver following this protocol processes the discovery response 195 using the processing mechanism described in [COMMON]. 197 A resolver following this protocol does not need to authenticate TLS 198 servers. Thus, when setting up a TLS connection, if the server's 199 authentication credentials do not match those expected by the 200 resolver, the resolver continues with the TLS connection. Privacy- 201 oriented resolvers (defined in [PRIVACY-REC]) following this protocol 202 MUST NOT indicate that they are using encryption because this 203 protocol is susceptible to on-path attacks. 205 3.1. Resolver Session Failures 207 The following are some of the reasons that a DNS with encryption 208 session might fail to be set up: 210 * The resolver receives a TCP RST response 212 * The resolver does not receive replies to TCP or TLS setup (such as 213 getting the TCP SYN message, the first TLS message, or completing 214 TLS handshakes) 216 * The TLS handshake gets a definitive failure 218 * The encrypted session fails for reasons other than for 219 authentication, such as incorrect algorithm choices or TLS record 220 failures 222 4. Serving with Encryption 224 An authoritative server following this protocol publishes the 225 discovery records using the serving mechanism described in [COMMON]. 227 5. IANA Considerations 229 Relevant IANA considerations are covered in [COMMON]. 231 6. Security Considerations 233 The method described in this document explicitly allows a resolver to 234 perform DNS communications over traditional unencrypted, 235 unauthenticated DNS on port 53, if it cannot find an authoritative 236 server that advertises that it supports encryption. The method 237 described in this document explicitly allows a resolver using 238 encryption to choose to allow unauthenticated encryption. In either 239 of these cases, the resulting communication will be susceptible to 240 obvious and well-understood attacks from an attacker in the path of 241 the communications. 243 7. Acknowledgements 245 Puneet Sood contributed many ideas to early drafts of this document. 247 The DPRIVE Working Group has contributed many ideas that keep 248 shifting the focus and content of this document. 250 8. References 252 8.1. Normative References 254 [COMMON] Dijk, P. V. and P. Hoffman, "Common Features for Encrypted 255 Recursive to Authoritative DNS", Work in Progress, 256 Internet-Draft, draft-pp-dprive-common-features-00, 2 May 257 2021, . 260 [DNS-SVCB] Schwartz, B., "Service Binding Mapping for DNS Servers", 261 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 262 03, 19 April 2021, . 265 [DNS-TERM] Hoffman, P. and K. Fujiwara, "DNS Terminology", Work in 266 Progress, Internet-Draft, draft-ietf-dnsop-rfc8499bis-01, 267 20 November 2020, . 270 [FULL-AUTH] 271 Pauly, T., Rescorla, E., Schinazi, D., and C. A. Wood, 272 "Signaling Authoritative DNS Encryption", Work in 273 Progress, Internet-Draft, draft-rescorla-dprive-adox- 274 latest-00, 26 February 2021, 275 . 278 [MUSTSHOULD1] 279 Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 [MUSTSHOULD2] 285 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 287 May 2017, . 289 [OPPORTUN] Dukhovni, V., "Opportunistic Security: Some Protection 290 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 291 December 2014, . 293 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 294 and parameter specification via the DNS (DNS SVCB and 295 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 296 dnsop-svcb-https-05, 21 April 2021, 297 . 300 8.2. Informative References 302 [DNSOHTTPS] 303 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 304 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 305 . 307 [DNSOQUIC] Huitema, C., Mankin, A., and S. Dickinson, "Specification 308 of DNS over Dedicated QUIC Connections", Work in Progress, 309 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 310 2021, . 313 [DNSOTLS] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 314 and P. Hoffman, "Specification for DNS over Transport 315 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 316 2016, . 318 [PRIVACY-REC] 319 Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and 320 A. Mankin, "Recommendations for DNS Privacy Service 321 Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, 322 October 2020, . 324 [RSO_STATEMENT] 325 "Statement on DNS Encryption", 2021, . 328 Authors' Addresses 330 Paul Hoffman 331 ICANN 333 Email: paul.hoffman@icann.org 335 Peter van Dijk 336 PowerDNS 338 Email: peter.van.dijk@powerdns.com