idnits 2.17.1 draft-schwartz-httpbis-dns-alt-svc-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2018) is 2189 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 (-02) exists of draft-bishop-httpbis-sni-altsvc-01 == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-07 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group B. Schwartz 3 Internet-Draft Google 4 Intended status: Standards Track M. Bishop 5 Expires: October 25, 2018 Akamai Technologies 6 April 23, 2018 8 Finding HTTP Alternative Services via the Domain Name Service 9 draft-schwartz-httpbis-dns-alt-svc-02 11 Abstract 13 The HTTP Alternative Services (Alt-Svc) mechanism allows an HTTP 14 origin to be served from multiple network endpoints, and over 15 multiple protocols. However, the client must first contact the 16 origin server, in order to learn of the alternative services. This 17 draft proposes a straightforward mapping of Alt-Svc into DNS, 18 allowing clients to learn of these services before their first 19 contact with the origin. This arrangement offers potential benefits 20 to both performance and privacy. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 25, 2018. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The ALTSVC record type . . . . . . . . . . . . . . . . . . . 3 59 2.1. Comparison with alternatives . . . . . . . . . . . . . . 4 60 2.1.1. Differences from the SRV RRTYPE . . . . . . . . . . . 4 61 2.1.2. Differences from the TXT RRTYPE . . . . . . . . . . . 4 62 3. Differences from Alt-Svc as transmitted over HTTP . . . . . . 5 63 3.1. Omitting Max Age . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Interaction with other standards . . . . . . . . . . . . 5 65 3.3. Granularity and lifetime control . . . . . . . . . . . . 5 66 4. Client behaviors . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1. Cache interaction . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Optimizing for performance . . . . . . . . . . . . . . . 6 69 4.3. Optimizing for privacy . . . . . . . . . . . . . . . . . 7 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 The HTTP Alternative Services standard [AltSvc] defines 81 o an extensible data model for describing alternative network 82 endpoints that are authoritative for an origin 84 o the "Alt-Svc Field Value", a text format for representing this 85 information 87 o standards for sending information in this format from a server to 88 a client over HTTP/1.1 and HTTP/2. 90 Together, these components provide a toolkit that has proven useful 91 and effective for informing a client of alternative services for an 92 origin. However, making use of an alternative service requires 93 contacting the origin server first. This creates an obvious 94 performance cost: users wait for a full HTTP connection initiation 95 (multiple roundtrips) before learning of an alternative service that 96 is preferred by the origin. The first connection also publicly 97 reveals the user's intended destination to all entities along the 98 network path. 100 This draft proposes a straightforward mechanism to distribute the 101 Alt-Svc Field Value, in its standard text format, through the DNS. 102 If a client receives this information during DNS resolution, it can 103 skip the initial connection and proceed directly to an alternative 104 service. 106 1.1. Terminology 108 For consistency with [AltSvc], we adopt the following definitions 110 o An "origin" is an information source as in [RFC6454]. 112 o The "origin server" is the server that the client would reach when 113 accessing the origin in the absence of Alt-Svc. 115 o An "alternative service" is a different server that can serve the 116 origin. 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 2. The ALTSVC record type 126 The ALTSVC DNS resource record (RR) type (RRTYPE ???) is used to 127 associate an Alternative Service Field Value with an origin. 128 Abstractly, the origin consists of a scheme (typically "https"), a 129 host name, and a port (typically "443"). 131 In the case of the ALTSVC RR, the origin is represented by prefixing 132 the port and scheme with "_", then concatenating them with the host, 133 resulting in a domain name like "_443._https.www.example.com.". 135 The RDATA portion of an ALTSVC resource record contains an Alt-Svc 136 Field Value, exactly as defined in Section 4 of [AltSvc]. 138 For example, if the operator of https://www.example.com intends to 139 include an HTTP response header like 141 Alt-Svc: h2=":8000"; ma=60 143 They would also publish an ALTSVC DNS record like 144 _443._https.www.example.com. 60S IN ALTSVC "h2=\":8000\"" 146 This data type can be represented as an Unknown RR as described in 147 [RFC3597]: 149 _443._https.www.example.com. 60S IN TYPE??? \# 10 150 68323D223A3830303022 152 This construction is intended to be extensible in two ways. First, 153 any extensions that are made to the Alt-Svc format for transmission 154 over HTTPS are also applicable here, unless expressly mentioned 155 otherwise. Second, including the scheme in the DNS name allows for 156 ALTSVC to serve schemes other than HTTPS, such as HTTP with 157 Opportunistic Security [RFC8164] and any future schemes for which 158 Alt-Svc may be defined. 160 2.1. Comparison with alternatives 162 The ALTSVC record type closely resembles some existing record types. 164 2.1.1. Differences from the SRV RRTYPE 166 An SRV record can perform a similar function to the ALTSVC record, 167 informing a client to look in a different location for a service. 168 However, there are several differences: 170 o SRV records are typically mandatory, whereas clients will always 171 continue to function correctly without making use of Alt-Svc. 173 o SRV records cannot instruct the client to switch or upgrade 174 protocols, whereas Alt-Svc can signal such an upgrade (e.g. to 175 HTTP/2). 177 o SRV records are not extensible, whereas Alt-Svc can be extended 178 with new parameters. For example, this is what allows the privacy 179 improvements related to SNI selection in [AltSvcSNI]. 181 o Using SRV records would not allow a client to skip processing of 182 the Alt-Svc information in a subsequent connection, so it does not 183 confer a performance advantage. 185 2.1.2. Differences from the TXT RRTYPE 187 The ALTSVC record uses an identical format to a TXT record, and could 188 be implemented as such. However, we define a new record type for 189 clarity, and to respect the use of TXT for human-readable notes as 190 recommended in [RFC5507]. 192 3. Differences from Alt-Svc as transmitted over HTTP 194 Publishing an ALTSVC record in DNS is intended to be equivalent to 195 transmitting this field value over HTTP, and receiving an ALTSVC 196 record is intended to be equivalent to receiving this field value 197 over HTTP. However, there are some small differences in the intended 198 client and server behavior. 200 3.1. Omitting Max Age 202 When publishing an ALTSVC record in DNS, server operators MUST omit 203 the "ma" parameter, which encodes the "max age" (i.e. expiration 204 time) of an Alt-Svc Field Value. Instead, server operators SHOULD 205 encode the expiration time in the DNS TTL, and MUST NOT set a TTL 206 longer than the intended "max age". 208 Server operators MAY publish multiple ALTSVC records as an RRSET, 209 with semantics equivalent to other mechanisms of providing multiple 210 Alt-Svc values to the client. When publishing an RRSET with multiple 211 ALTSVC records, the server operator MUST set the overall TTL to the 212 minimum of the "max age" values (following Section 5.2 of [RFC2181]). 214 When receiving an ALTSVC record, clients MAY synthesize a new "ma" 215 parameter from the DNS TTL, in order to interoperate with Alt-Svc 216 processing subsystems. 218 3.2. Interaction with other standards 220 The purpose of this standard is to reduce connection latency and 221 improve user privacy. Server operators implementing this standard 222 SHOULD also implement TLS 1.3 [I-D.ietf-tls-tls13] and OCSP Stapling 223 [RFC6066], both of which confer substantial performance and privacy 224 benefits when used in combination with ALTSVC records. 226 To realize the greatest privacy benefits, this proposal is intended 227 for use with a privacy-preserving DNS transport (like DNS over TLS 228 [RFC7858] or DNS over HTTPS [DOH]), and with the "SNI" Alt-Svc 229 Parameter [AltSvcSNI]. However, performance improvements, and some 230 modest privacy improvements, are possible without the use of those 231 standards. 233 3.3. Granularity and lifetime control 235 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 236 Field Value specifically to the client. When using an ALTSVC DNS 237 record, groups of clients will necessarily receive the same Alt-Svc 238 Field Value. Therefore, this standard is not suitable for servers 239 that require single-client granularity in Alt-Svc. Server operators 240 that want to serve different Alt-Svc Field Values to different 241 geographic or network regions SHOULD configure their authoritative 242 DNS server to respect the EDNS0 Client Subnet extension [RFC7871]. 244 Some DNS caching systems incorrectly extend the lifetime of DNS 245 records beyond the stated TTL. Server operators MUST NOT rely on 246 ALTSVC records expiring on time, and MAY shorten the TTL to 247 compensate. 249 4. Client behaviors 251 4.1. Cache interaction 253 If the client has an Alt-Svc cache, and a usable Alt-Svc value is 254 present in that cache, then the client SHOULD NOT issue an ALTSVC DNS 255 query. Instead, the client SHOULD proceed with alternative service 256 connection as usual. 258 If the client has a cached Alt-Svc entry that is expiring, the client 259 MAY perform an ALTSVC query to refresh the entry. 261 4.2. Optimizing for performance 263 Clients that are optimizing for performance (i.e. minimum connection 264 setup time) SHOULD implement the following connection sequence: 266 1. Issue address (AAAA and/or A) queries, immediately followed by 267 the ALTSVC query. 269 2. If an ALTSVC response is received first, proceed with alternative 270 service connection and ignore the address responses if they are 271 no longer relevant. 273 3. Otherwise, initiate connection to the origin server. 275 4. As soon as an Alt-Svc field value is received, through the DNS or 276 over HTTP, proceed with alternative service connection. Do not 277 abort this connection if an Alt-Svc field value is received from 278 the other source later. 280 If the ALTSVC and address queries return approximately 281 simultaneously, this process typically saves three roundtrips on a 282 fresh connection that uses Alt-Svc: one each for TCP, TLS 1.3, and 283 HTTP. (On subsequent connections, the Alt-Svc information is 284 expected to be cached, so this procedure does not apply.) 286 If a client can cache Alt-Svc entries that were received over both 287 HTTP and DNS, the client MAY prefer entries that were received over 288 HTTP. These records may be more narrowly targeted for the specific 289 client. 291 As an additional optimization, when choosing among multiple Alt-Svc 292 values, clients MAY prefer those that will not require an address 293 query, either because the corresponding address record is already in 294 cache or because the host is an IP address. 296 Note that this procedure does not rely on recursive resolvers 297 handling the ALTSVC record type correctly. If ALTSVC queries receive 298 spurious NXDOMAIN responses, or even no response at all, connections 299 will proceed as usual without any delay. 301 4.3. Optimizing for privacy 303 Clients that are optimizing for privacy SHOULD implement [AltSvcSNI] 304 and DNS over a secure transport (e.g. [RFC7858] or [DOH]). Use of a 305 secure transport is important not only for privacy protection, but 306 also to ensure that queries for the new ALTSVC RRTYPE are handled 307 correctly. Additionally, these clients SHOULD implement the 308 following connection sequence: 310 1. Issue the ALTSVC DNS query first, immediately followed by the 311 address queries. 313 2. Wait for the ALTSVC record response. 315 3. If the response is nonempty, proceed with alternative service 316 connection and ignore the address query responses. 318 4. Otherwise, wait for the address queries and connect as usual. 320 Note that this process is also expected to be faster than Alt-Svc 321 over HTTP in the case of HTTP Opportunistic Upgrade Probing 322 (Section 2 of [RFC8164]). 324 5. Security Considerations 326 Alt-Svc Field Values are intended for distribution over untrusted 327 channels, and clients are REQUIRED to verify that the alternative 328 service is authoritative for the origin (Section 2.1 of [AltSvc]). 329 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 330 and using ALTSVC records. 332 6. IANA Considerations 334 This draft requires assignment of a new DNS RRTYPE value. 336 7. References 338 7.1. Normative References 340 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 341 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 342 April 2016, . 344 [AltSvcSNI] 345 Bishop, M., "The "SNI" Alt-Svc Parameter", draft-bishop- 346 httpbis-sni-altsvc-01 (work in progress), January 2018. 348 [DOH] Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 349 draft-ietf-doh-dns-over-https-07 (work in progress), April 350 2018. 352 [I-D.ietf-tls-tls13] 353 Rescorla, E., "The Transport Layer Security (TLS) Protocol 354 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 355 March 2018. 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 363 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 364 . 366 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 367 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 368 2003, . 370 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 371 Extensions: Extension Definitions", RFC 6066, 372 DOI 10.17487/RFC6066, January 2011, 373 . 375 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 376 DOI 10.17487/RFC6454, December 2011, 377 . 379 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 380 and P. Hoffman, "Specification for DNS over Transport 381 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 382 2016, . 384 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 385 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 386 May 2017, . 388 7.2. Informative References 390 [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, 391 Ed., "Design Choices When Expanding the DNS", RFC 5507, 392 DOI 10.17487/RFC5507, April 2009, 393 . 395 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 396 Kumari, "Client Subnet in DNS Queries", RFC 7871, 397 DOI 10.17487/RFC7871, May 2016, 398 . 400 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for 401 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, 402 . 404 Authors' Addresses 406 Ben Schwartz 407 Google 409 Email: bemasc@google.com 411 Mike Bishop 412 Akamai Technologies 414 Email: mbishop@evequefou.be