idnits 2.17.1 draft-schwartz-svcb-dns-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 February 2021) is 1164 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) == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 add B. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Standards Track 17 February 2021 5 Expires: 21 August 2021 7 Service Binding Mapping for DNS Servers 8 draft-schwartz-svcb-dns-02 10 Abstract 12 The SVCB DNS record type expresses a bound collection of endpoint 13 metadata, for use when establishing a connection to a named service. 14 DNS itself can be such a service, when the server is identified by a 15 domain name. This document provides the SVCB mapping for named DNS 16 servers, allowing them to indicate support for new transport 17 protocols. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the ADD Working Group 24 mailing list (add@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/add/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/bemasc/svcb-dns. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 21 August 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 3. Name form . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Applicable existing SvcParamKeys . . . . . . . . . . . . . . 3 67 4.1. alpn and no-default-alpn . . . . . . . . . . . . . . . . 3 68 4.2. port . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.3. Other applicable SvcParamKeys . . . . . . . . . . . . . . 4 70 5. New SvcParamKeys . . . . . . . . . . . . . . . . . . . . . . 4 71 5.1. dohpath . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 6. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 7. Relationship to DNS URIs . . . . . . . . . . . . . . . . . . 5 74 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 9.1. Adversary on the query path . . . . . . . . . . . . . . . 5 77 9.2. Adversary on the transport path . . . . . . . . . . . . . 6 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 81 11.2. Informative References . . . . . . . . . . . . . . . . . 8 82 Appendix A. Mapping Summary . . . . . . . . . . . . . . . . . . 8 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 The SVCB record type [SVCB] provides clients with information about 89 how to reach alternative endpoints for a service, which may have 90 improved performance or privacy properties. The service is 91 identified by a "scheme" indicating the service type, a hostname, and 92 optionally other information such as a port number. A DNS server is 93 often identified only by its IP address (e.g. in DHCP), but in some 94 contexts it can also be identified by a hostname (e.g. "NS" records, 95 manual resolver configuration) and sometimes also a non-default port 96 number. 98 Use of the SVCB record type requires a mapping document for each 99 service type, indicating how a client for that service can interpret 100 the contents of the SVCB SvcParams. This document provides the 101 mapping for the "dns" service type, allowing DNS servers to offer 102 alternative endpoints and transports, including encrypted transports 103 like DNS over TLS and DNS over HTTPS. 105 2. Conventions and Definitions 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 3. Name form 115 Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For 116 example, a DNS service identified by the name "dns1.example.com" and 117 (unusually) the non-default port number 5353 would be represented as 118 "_5353._dns.dns1.example.com.". 120 4. Applicable existing SvcParamKeys 122 4.1. alpn and no-default-alpn 124 These keys indicate the set of supported protocols ([SVCB] 125 Section 6.1). The default protocol is "dot", indicating support for 126 DNS over TLS [DOT]. 128 If the protocol set contains any HTTP versions (e.g. "h2", "h3"), 129 then the record indicates support for DNS over HTTPS [DOH], and the 130 "dohpath" key MUST be present (Section 5.1). All keys specified for 131 use with the HTTPS record are also permissible, and apply to the 132 resulting HTTP connection. 134 If the protocol set contains protocols with different default ports, 135 and no port key is specified, then protocols are contacted separately 136 on their default ports. Note that in this configuration, ALPN 137 negotiation does not defend against cross-protocol downgrade attacks. 139 These keys are automatically mandatory if present. (See Section 7 of 140 [SVCB] for the definition of "automatically mandatory".) 142 4.2. port 144 This key is used to indicate the target port for connection (([SVCB] 145 Section 6.2)). If omitted, the client SHALL use the default port for 146 each transport protocol (853 for DNS over TLS, 443 for DNS over 147 HTTPS). 149 This key is automatically mandatory if present. 151 4.3. Other applicable SvcParamKeys 153 These SvcParamKeys apply to the "dns" scheme without modification: 155 * echconfig 157 * ipv4hint 159 * ipv6hint 161 5. New SvcParamKeys 163 5.1. dohpath 165 "dohpath" is a single-valued SvcParamKey whose value (both in 166 presentation and wire format) is a relative URI Template [RFC6570], 167 normally starting with "/". If the "alpn" SvcParamKey indicates 168 support for HTTP, clients MAY construct a DNS over HTTPS URI Template 169 by combining the prefix "https://", the service name, the port from 170 the "port" key if present, and the "dohpath" value. (The DNS 171 service's original port number MUST NOT be used.) 173 Clients SHOULD NOT query for any "HTTPS" RRs when using the 174 constructed URI Template. Instead, the SvcParams and address records 175 associated with this SVCB record SHOULD be used for the HTTPS 176 connection, with the same semantics as an HTTPS RR. However, for 177 consistency, service operators SHOULD publish an equivalent HTTPS RR, 178 especially if clients might learn this URI Template through a 179 different channel. 181 6. Limitations 183 This document is concerned exclusively with the DNS transport, and 184 does not affect or inform the construction or interpretation of DNS 185 messages. For example, nothing in this document indicates whether 186 the service is intended for use as a recursive or authoritative DNS 187 server. Clients must know the intended use in their context. 189 7. Relationship to DNS URIs 191 The "dns:" URI scheme [DNSURI] describes a way to represent DNS 192 queries as URIs. This scheme optionally includes an authority, 193 comprised of a host and port number (with a default of 53). DNS URIs 194 normally omit the authority, or specify an IP address, but a hostname 195 is allowed, in which case it is suitable for use with this mapping. 197 8. Examples 199 * A resolver at "resolver.example" that supports 201 - DNS over TLS on "resolver.example", port 853 and 8530, with 202 "resolver.example" as the Authentication Domain Name, 204 - DNS over HTTPS at "https://resolver.example/dns-query{?dns}", 205 and 207 - an experimental protocol on "fooexp.resolver.example:5353": 209 $ORIGIN example. 210 _dns.resolver 7200 IN SVCB 1 resolver ( 211 alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) 212 _dns.resolver 7200 IN SVCB 2 resolver ( 213 port=8530 echconfig=... ) 214 _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353 215 echconfig=... alpn=foo no-default-alpn foo-info=... ) 217 * A nameserver at "ns.example" whose service configuration is 218 published on a different domain: 220 $ORIGIN example. 221 _dns.ns 7200 IN SVCB 0 _dns.ns.nic 223 9. Security Considerations 225 9.1. Adversary on the query path 227 This section considers an adversary who can add or remove responses 228 to the SVCB query. 230 Clients MUST authenticate the server to its name during secure 231 transport establishment. This name is the hostname used to construct 232 the original SVCB query, and cannot be influenced by the SVCB record 233 contents. Accordingly, this draft does not mandate the use of 234 DNSSEC. This draft also does not specify how clients authenticate 235 the name (e.g. selection of roots of trust), which might vary 236 according to the context. 238 Although this adversary cannot alter the authentication name of the 239 service, it does have control of the port number and "dohpath" value. 240 As a result, the adversary can direct DNS queries for $HOSTNAME to 241 any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if 242 $HOSTNAME is not actually a DNS server. If the DNS client uses 243 shared TLS or HTTP state, the client could be correctly authenticated 244 (e.g. using a TLS client certificate or HTTP cookie). 246 This behavior creates a number of possible attacks for certain server 247 configurations. For example, if "https://$HOSTNAME/upload" accepts 248 any POST request as a public file upload, the adversary could forge a 249 SVCB record containing "dohpath=/upload". This would cause the 250 client to upload and publish every query, resulting in unexpected 251 storage costs for the server and privacy loss for the client. 253 To mitigate this attack, a client of this SVCB mapping MUST NOT 254 provide client authentication for DNS queries, except to servers that 255 it specifically knows are not vulnerable to such attacks, and a DoH 256 service operator MUST ensure that all unauthenticated DoH requests to 257 its origin maintain the DoH service's privacy guarantees, regardless 258 of the path. Also, if an alternative service endpoint sends an 259 invalid response to a DNS query, the client SHOULD NOT send more 260 queries to that endpoint. 262 9.2. Adversary on the transport path 264 This section considers an adversary who can modify network traffic 265 between the client and the SvcDomainName (i.e. the destination 266 server). 268 For a SVCB-reliant client ([SVCB] Section 3), this adversary can only 269 cause a denial of service. However, because DNS is unencrypted by 270 default, this adversary can execute a downgrade attack against SVCB- 271 optional clients. Accordingly, when use of this specification is 272 optional, clients SHOULD switch to SVCB-reliant behavior if SVCB 273 resolution succeeds. Specifications making using of this mapping MAY 274 adjust this fallback behavior to suit their requirements. 276 10. IANA Considerations 278 Per [SVCB] IANA would be directed to add the following entry to the 279 SVCB Service Parameters registry. 281 +========+=========+==============================+=================+ 282 | Number | Name | Meaning | Reference | 283 +========+=========+==============================+=================+ 284 | TBD | dohpath | DNS over HTTPS path template | (This | 285 | | | | document) | 286 +--------+---------+------------------------------+-----------------+ 288 Table 1 290 Per [Attrleaf], IANA would be directed to add the following entry to 291 the DNS Underscore Global Scoped Entry Registry: 293 +=========+============+===============+=================+ 294 | RR TYPE | _NODE NAME | Meaning | Reference | 295 +=========+============+===============+=================+ 296 | SVCB | _dns | DNS SVCB info | (This document) | 297 +---------+------------+---------------+-----------------+ 299 Table 2 301 11. References 303 11.1. Normative References 305 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 306 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 307 . 309 [DOT] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 310 and P. Hoffman, "Specification for DNS over Transport 311 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 312 2016, . 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 320 and D. Orchard, "URI Template", RFC 6570, 321 DOI 10.17487/RFC6570, March 2012, 322 . 324 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 325 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 326 May 2017, . 328 [SVCB] Schwartz, B. M., Bishop, M., and E. Nygren, "Service 329 binding and parameter specification via the DNS (DNS SVCB 330 and HTTPS RRs)", Work in Progress, Internet-Draft, draft- 331 ietf-dnsop-svcb-https-02, 2 November 2020, 332 . 335 11.2. Informative References 337 [Attrleaf] Crocker, D., "Scoped Interpretation of DNS Resource 338 Records through "Underscored" Naming of Attribute Leaves", 339 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 340 . 342 [DNSURI] Josefsson, S., "Domain Name System Uniform Resource 343 Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, 344 . 346 Appendix A. Mapping Summary 348 This table serves as a non-normative summary of the DNS mapping for 349 SVCB. 351 +=================+========================================+ 352 +=================+========================================+ 353 | *Mapped scheme* | "dns" | 354 +-----------------+----------------------------------------+ 355 | *RR type* | SVCB (64) | 356 +-----------------+----------------------------------------+ 357 | *Name prefix* | "_dns" for port 53, else "_$PORT._dns" | 358 +-----------------+----------------------------------------+ 359 | *Automatically | "port", "no-default-alpn" | 360 | Mandatory Keys* | | 361 +-----------------+----------------------------------------+ 362 | *SvcParam | "alpn": ["dot"] | 363 | defaults* | | 364 +-----------------+----------------------------------------+ 365 | *Special | Supports all HTTPS RR SvcParamKeys | 366 | behaviors* | | 367 +-----------------+----------------------------------------+ 368 | | Overrides the HTTPS RR for DoH | 369 +-----------------+----------------------------------------+ 370 | | Default port is per-transport | 371 +-----------------+----------------------------------------+ 372 | | No encrypted -> cleartext fallback | 373 +-----------------+----------------------------------------+ 375 Table 3 377 Acknowledgments 379 TODO acknowledge. 381 Author's Address 383 Benjamin Schwartz 384 Google LLC 386 Email: bemasc@google.com