idnits 2.17.1 draft-rescorla-dprive-adox-latest-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 445 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- 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 == Line 222 has weird spacing: '...cursive x.roo...' -- The document date (23 February 2021) is 1157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-02 -- Obsolete informational reference (is this intentional?): RFC 7816 (ref. 'QMIN') (Obsoleted by RFC 9156) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational E. Rescorla 5 Expires: 27 August 2021 Mozilla 6 D. Schinazi 7 Google LLC 8 C.A. Wood 9 Cloudflare 10 23 February 2021 12 Signaling Authoritative DNS Encryption 13 draft-rescorla-dprive-adox-latest-00 15 Abstract 17 This document defines a mechanism for signaling that a given 18 authoritative DNS server is reachable by encrypted DNS. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Discussion of this document takes place on the DNS PRIVate Exchange 25 Working Group mailing list (dns-privacy@ietf.org), which is archived 26 at https://mailarchive.ietf.org/arch/browse/dns-privacy/. 28 Source for this draft and an issue tracker can be found at 29 https://github.com/ekr/draft-rescorla-dprive-adox. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 27 August 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction 65 2. Conventions and Definitions 66 3. Overview of Operation 67 4. Use of SVCB Records to Signal Encrypted Transport 68 4.1. Caching and lifetime 69 4.2. Authenticating the Server 70 5. Example 71 6. Security Considerations 72 7. IANA Considerations 73 8. References 74 8.1. Normative References 75 8.2. Informative References 76 Acknowledgments 77 Authors' Addresses 79 1. Introduction 81 The IETF has defined a number of mechanisms for carrying DNS queries 82 over encrypted transport [DOH] [DOT] [DOQ]. However, there is no 83 scalable way for a recursive resolver to know that a given 84 authoritative resolver supports encrypted transport, which inhibits 85 the deployment of encrypted DNS for queries from recursive resolvers. 86 This specification defines a mechanism for carrying that signal, 87 using the DNS SVCB [SVCB] record. 89 2. Conventions and Definitions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in BCP 94 14 [RFC2119] [RFC8174] when, and only when, they appear in all 95 capitals, as shown here. 97 3. Overview of Operation 99 The mechanism defined in this document works by using the DNS SVCB 100 [SVCB] record to indicate that a given server supports TLS. The 101 recursive resolver can obtain these records in two distinct ways: 103 * In the additional data block of the response that referred the 104 recursive to the target authoritative server. 106 * By directly resolving a SVCB query for the target authoritative 107 resolver. 109 As a practical matter, the first of these options is preferred as it 110 allows the recursive to learn that the authoritative server supports 111 encrypted transport without an additional round trip, as shown below: 113 Recursive .com ns.example.example 114 Authoritative Server (Authoritative for example.com) 115 NS example.com? ------------> 117 <----- example.com NS ns.example.example 118 ns.example.example A 192.0.2.1 119 _dns.ns.example.example SVCB alpn=dot 121 <-------------- TLS connection to ns.example ------------> 122 A example.com? -------------------------------------------> 124 The recursive resolver starts by contacting the authoritative server 125 for .com and asks for the NS records for example.com. Note that .com 126 is not authoritative for the example.com apex, and will not sign the 127 NS RRset; see [RFC4035], Section 2.2, and Section 6 for details. The 128 authoritative returns the NS record pointing at ns.example.example 129 and also returns a glue records for ns.example.example indicating 130 that it supports DNS over TLS (DoT), in much the same way as it might 131 have sent an IP address for that server. This additional record is 132 the only difference from the current situation, and allows the 133 recursive resolver to know that it can reach ns.example.example over 134 encrypted transport. 136 Note: SVCB is not presently permitted at the root [REGISTRY]. In the 137 interim, recursive resolvers may be preconfigured with the TLS status 138 of the resolvers for TLDs. [[OPEN ISSUE: Do we want to invent some 139 other sentinel as a temporary measure?]] 141 4. Use of SVCB Records to Signal Encrypted Transport 143 Any given authoritative server name can have one or more DNS Server 144 SVCB records, as defined in [I-D.schwartz-svcb-dns]. 146 For instance, the following records would indicate that 147 ns.example.example could be reached by either DoT or DoH (over both 148 TCP and QUIC). 150 _dns.ns.example.example. 7200 IN SVCB 1 ns.example.example. alpn=dot,h2,h3 dohpath=/dns-query{?dns} 152 Upon determining that a given nameserver supports a compatible 153 encrypted transport, an implementation MUST only use encrypted 154 transport for the rest of the cache lifetime for that information and 155 MUST hard fail with error if it is unable to establish a connection. 156 If multiple encrypted transports are available, an implementation 157 SHOULD try all of them before declaring failure. 159 [[OPEN ISSUE: figure out error details]] 161 4.1. Caching and lifetime 163 Note that in the common case where the name of the target 164 authoritative server is out-of-bailiwick [RFC7719] for the referring 165 resolver, then the SVCB record may not be retained for future 166 queries. This can create a situation in which a given authoritative 167 server will be queried over encrypted transport for one name and over 168 unencrypted transport for another. This is not the end of the world 169 (HTTPS has historically operated in this way, with the security 170 properties being attached to the reference), but is also not ideal. 171 In order to prevent this, resolvers which are also authoritative for 172 their own name SHOULD send SVCB glue records in the additional data 173 section so that they can be properly cached, and the TTL for these 174 SVCB records SHOULD match that of the corresponding NS records in the 175 same RRset. 177 [[OPEN ISSUE: How often is the case where ns.example.example is not 178 authoritative for itself? Should we encourage people to accept out- 179 of-bailiwick responses in that case?]] 181 4.2. Authenticating the Server 183 Recursive servers MUST authenticate the authoritative server using 184 the procedures associated with the relevant protocol, [RFC6125] and 185 [RFC2818] for DoT and DoH respectively. This is in principle 186 compatible with having the server authenticated either with the 187 WebPKI or with TLSA records [DANE], or both. In order for this to 188 work properly, however, the recursive resolver must know at the time 189 it connects whether it will be willing to accept the authoritative 190 server's credentials. 192 This can be addressed in several ways: 194 1. Require a particular form of authentication (e.g., the WebPKI or 195 TLSA records) as mandatory. 197 2. Have the SVCB record indicate what kind(s) of authentication the 198 authoritative server supports, allowing the recursive to filter 199 out incompatible advertisements. For instance, the SVCB record 200 could contain a key that stated that it only had a WebPKI 201 certificate, in which case the resolver could ignore that entry. 203 [[OPEN ISSUE: If we have the kind of advertisement indicated in (2) 204 above, is not necessary to have an MTI, but it might be desirable to 205 promote interoperability.]] 207 One challenge with TLSA records in this context is that they may not 208 be in the recursive resolver's cache at the time when it wants to 209 connect to the authoritative. This can create added latency if the 210 recursive resolver must then first retrieve TLSA records for the 211 authoritative. If we wish for servers to authenticate with DANE, we 212 will also probably want some mechanism to carry the TLSA records in 213 the TLS handshake, as, for instance defined in 214 [I-D.ietf-tls-dnssec-chain-extension]. 216 [[OPEN ISSUE: Resolve this.]] 218 5. Example 220 A complete example is shown below. 222 Recursive x.root-servers.org ns.a.example ns.example.example 223 (Auth. for .) (Auth for .example) (Auth for .example.example) 225 <== TLS handshake ==> 226 NS .example? -------> 227 <- .example NS ns.op.example 228 ns.op.example A 198.51.100.1 229 _dns.ns.op.example SVCB alpn=dot 231 <============ TLS handshake ===========> 232 NS example.example? -------------------> 233 <----- example.example NS ns.example.example 234 ns.example.example A 203.0.113.1 235 _dns.ns.example.example SVCB alpn=dot 237 <====================== TLS Handshake ======================> 238 A www.example.example? -------------------------------------> 239 <---------------------------- www.example.example A 192.0.2.1 241 In this case, the recursive wants to resolve www.example.example. 243 Resolution proceeds in three phases. 245 Initially, the recursive connects to the root server. We assume that 246 the recursive knows that the root server is able to do DoT, either 247 because it has been preconfigured with his information or because it 248 has connected to that root server before. It performs an NS query 249 for ".example" (we are assuming QMIN) and receives: 251 * An NS record pointing to ns.op.example 253 * A glue A record for ns.op.example = 198.51.100.1 255 * A SVCB record stating that ns.op.example speaks DoT 257 Next, the recursive resolver forms a TLS connection to ns.op.example 258 and requests an NS record for example.example. It receives: 260 * An NS record pointing to ns.example.example 262 * A glue A record for ns.example.example = 203.0.113.1 264 * A SVCB record stating that ns.example.example speaks DoT 266 Finally, the recursive resolver forms a TLS connection to 267 ns.example.example and request an A record for www.example.example 268 and receives the A record of 192.0.2.1. 270 6. Security Considerations 272 The primary security property delivered by this mechanism is 273 confidentiality of the query and response. As long as (1) all 274 queries in the resolution chain, including to the authoritative 275 server are encrypted and (2) all resolvers in the resolution chain 276 are trustworthy, then even an on-path attacker cannot discover the 277 name being resolved or its response. However, if either of these 278 conditions is violated, then an attack is possible: 280 * If the connection to the authoritative server is not encrypted, 281 then the request and response can be read directly. 283 * If one of the earlier connections is not encrypted, then the 284 attacker can substitute their own NS records. records from the 285 additional_data, forcing the resolution back to unencrypted mode. 287 * If one of the resolvers is untrustworthy, then they can substitute 288 their own NS records. 290 DNSSEC signing only partly mitigates these issues because delegations 291 at top-level zones are not signed, as per [RFC4035], Section 2.2. In 292 practice, this means a recursive resolver attempting to resolve a 293 zone apex query, such as example.com in Section 3, cannot assume the 294 NS answer is authentic. While NS records received from the 295 authoritative server may be signed, in order to retrieve them, the 296 recursive resolver will have to contact the servers listed by the 297 unverified NS records received from the referring server, at which 298 point it has leaked the zone apex to the (potentially fake) 299 authoritative server (as well as to the referring server). 301 If the recursive resolver is attempting to resolve a specific 302 subdomain from the resolver (e.g., server-1234.example.com), then it 303 may be able to protect against this attack by (1) using query 304 minimization [QMIN] and (2) querying the (alleged) authoritative for 305 its DNSSEC-signed NS and SVCB records and only once it has received 306 those, attempting to retrieve the actual subdomain. If the domain is 307 DNSSEC signed, then this prevents a malicious referring resolver from 308 redirecting the recursive resolver to their own authoritative and 309 learning the true subdomain. However, if, as is common, the 310 recursive is just trying to resolve the apex name or one of the 311 common "service" names such as "www.example.com", then this procedure 312 does not provide additional protection. 314 Encryption does not mitigate all leakage. In some circumstances, an 315 on-path attacker may learn the identity of the authoritative server 316 if, for example, that server only serves a small number of domains. 317 The attacker can learn information about what is being resolved by 318 observing whether or not server is queried. 320 As a secondary property, the mechanism in this document can provide 321 some level of integrity for DNS responses, again under the condition 322 that each resolver in the chain is trustworthy. By contrast, DNSSEC 323 provides integrity even if the resolvers are untrustworthy. 325 7. IANA Considerations 327 This document has no IANA actions. 329 8. References 331 8.1. Normative References 333 [DANE] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 334 of Named Entities (DANE) Transport Layer Security (TLS) 335 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 336 2012, . 338 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 339 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 340 . 342 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 343 and P. Hoffman, "Specification for DNS over Transport 344 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 345 2016, . 347 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 348 Requirement Levels", BCP 14, RFC 2119, 349 DOI 10.17487/RFC2119, March 1997, 350 . 352 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 353 DOI 10.17487/RFC2818, May 2000, 354 . 356 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 357 Verification of Domain-Based Application Service Identity 358 within Internet Public Key Infrastructure Using X.509 359 (PKIX) Certificates in the Context of Transport Layer 360 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 361 2011, . 363 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 364 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 365 May 2017, . 367 8.2. Informative References 369 [DOQ] Huitema, C., Mankin, A., and S. Dickinson, "Specification 370 of DNS over Dedicated QUIC Connections", Work in Progress, 371 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 372 2021, . 375 [I-D.ietf-tls-dnssec-chain-extension] 376 Shore, M., Barnes, R., Huque, S., and W. Toorop, "A DANE 377 Record and DNSSEC Authentication Chain Extension for TLS", 378 Work in Progress, Internet-Draft, draft-ietf-tls-dnssec- 379 chain-extension-07, 21 March 2018, 380 . 383 [I-D.schwartz-svcb-dns] 384 Schwartz, B., "Service Binding Mapping for DNS Servers", 385 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 386 02, 17 February 2021, 387 . 390 [QMIN] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 391 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 392 . 394 [REGISTRY] ICANN, "ICANN Registry Agreement", July 2017, 395 . 398 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 399 Rose, "Protocol Modifications for the DNS Security 400 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 401 . 403 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 404 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 405 2015, . 407 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 408 and parameter specification via the DNS (DNS SVCB and 409 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 410 dnsop-svcb-https-03, 17 February 2021, 411 . 414 Acknowledgments 416 TODO acknowledge. 418 Authors' Addresses 420 Tommy Pauly 421 Apple Inc. 423 Email: tpauly@apple.com 425 Eric Rescorla 426 Mozilla 428 Email: ekr@rtfm.com 430 David Schinazi 431 Google LLC 433 Email: dschinazi.ietf@gmail.com 435 Christopher A. Wood 436 Cloudflare 438 Email: caw@heapingbits.net