idnits 2.17.1 draft-nygren-httpbis-httpssvc-03.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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1747 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 (-18) exists of draft-ietf-tls-esni-03 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-20 -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'DNSTerm') (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-04) exists of draft-ietf-dnsop-aname-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). 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: January 9, 2020 E. Nygren 6 Akamai Technologies 7 July 8, 2019 9 HTTPSSVC service location and parameter specification via the DNS (DNS 10 HTTPSSVC) 11 draft-nygren-httpbis-httpssvc-03 13 Abstract 15 This document specifies an "HTTPSSVC" DNS resource record type to 16 facilitate the lookup of information needed to make connections for 17 HTTPS URIs. The HTTPSSVC DNS RR mechanism allows an HTTPS origin 18 hostname to be served from multiple network services, each with 19 associated parameters (such as transport protocol and keying material 20 for encrypting TLS SNI). It also provides a solution for the 21 inability of the DNS to allow a CNAME to be placed at the apex of a 22 domain name. Finally, it provides a way to indicate that the origin 23 supports HTTPS without having to resort to redirects, allowing 24 clients to remove HTTP from the bootstrapping process. 26 By allowing this information to be bootstrapped in the DNS, it allows 27 for clients to learn of alternative services before their first 28 contact with the origin. This arrangement offers potential benefits 29 to both performance and privacy. 31 TO BE REMOVED: This proposal is inspired by and based on recent DNS 32 usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long 33 standing desires to have SRV or a functional equivalent implemented 34 for HTTP). These proposals each provide an important function but 35 are potentially incompatible with each other, such as when an origin 36 is load-balanced across multiple hosting providers (multi-CDN). 37 Furthermore, these each add potential cases for adding additional 38 record lookups in-addition to AAAA/A lookups. This design attempts 39 to provide a unified framework that encompasses the key functionality 40 of these proposals, as well as providing some extensibility for 41 addressing similar future challenges. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at https://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on January 9, 2020. 60 Copyright Notice 62 Copyright (c) 2019 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (https://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4 79 1.2. Goals of the HTTPSSVC RR . . . . . . . . . . . . . . . . 4 80 1.3. Overview of the HTTPSSVC RR . . . . . . . . . . . . . . . 5 81 1.4. Additional Alt-Svc parameters . . . . . . . . . . . . . . 6 82 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 83 2. The HTTPSSVC record type . . . . . . . . . . . . . . . . . . 7 84 2.1. HTTPSSVC RDATA Wire Format . . . . . . . . . . . . . . . 7 85 2.2. RRNames . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 2.3. SvcRecordType . . . . . . . . . . . . . . . . . . . . . . 8 87 2.4. HTTPSSVC records: alias form . . . . . . . . . . . . . . 9 88 2.5. HTTPSSVC records: alternative service form . . . . . . . 9 89 3. Differences from Alt-Svc as transmitted over HTTP . . . . . . 10 90 3.1. Omitting Max Age and Persist . . . . . . . . . . . . . . 10 91 3.2. Multiple records and preference ordering . . . . . . . . 11 92 3.3. Constructing Alt-Svc equivalent headers . . . . . . . . . 11 93 3.4. Granularity and lifetime control . . . . . . . . . . . . 12 94 4. Client behaviors . . . . . . . . . . . . . . . . . . . . . . 12 95 4.1. Client resolution . . . . . . . . . . . . . . . . . . . . 12 96 4.2. HTTP Strict Transport Security . . . . . . . . . . . . . 13 97 4.3. Cache interaction . . . . . . . . . . . . . . . . . . . . 14 98 5. DNS Server Behaviors . . . . . . . . . . . . . . . . . . . . 14 99 6. Performance optimizations . . . . . . . . . . . . . . . . . . 14 100 7. Extensions to enhance privacy . . . . . . . . . . . . . . . . 15 101 7.1. Alt-Svc parameter for ESNI keys . . . . . . . . . . . . . 15 102 7.2. Interaction with other standards . . . . . . . . . . . . 15 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 10. Acknowledgements and Related Proposals . . . . . . . . . . . 17 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 107 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 108 11.2. Informative References . . . . . . . . . . . . . . . . . 19 109 Appendix A. Additional examples . . . . . . . . . . . . . . . . 20 110 A.1. Equivalence to Alt-Svc records . . . . . . . . . . . . . 20 111 Appendix B. Comparison with alternatives . . . . . . . . . . . . 20 112 B.1. Differences from the SRV RRTYPE . . . . . . . . . . . . . 20 113 B.2. Differences from the proposed HTTP record . . . . . . . . 21 114 B.3. Differences from the proposed ANAME record . . . . . . . 21 115 B.4. Differences from the proposed ESNI record . . . . . . . . 21 116 B.5. SNI Alt-Svc parameter . . . . . . . . . . . . . . . . . . 22 117 Appendix C. Design Considerations and Open Issues . . . . . . . 22 118 C.1. Record Name . . . . . . . . . . . . . . . . . . . . . . . 22 119 C.2. Applicability to other schemes . . . . . . . . . . . . . 22 120 C.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 22 121 C.4. Extensibility of SvcRecordType . . . . . . . . . . . . . 22 122 C.5. Where to include Priority . . . . . . . . . . . . . . . . 22 123 C.6. Whether to include Weight . . . . . . . . . . . . . . . . 23 124 Appendix D. Change history . . . . . . . . . . . . . . . . . . . 23 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 127 1. Introduction 129 The HTTPSSVC RR is intended to address a number of challenges facing 130 HTTPS clients and services, while also providing an extensible model 131 to handle similar use-cases without forcing clients to perform 132 additional DNS lookups and without forcing them to first make 133 connections to a default service for the origin. 135 When clients need to make a connection to fetch resources associated 136 with an HTTPS URI, they must first resolve A and/or AAAA address 137 resource records for the origin hostname. This is adequate when 138 clients default to TCP port 443, do not support Encrypted SNI [ESNI], 139 and where the origin service operator does not have a desire to put 140 an CNAME at a zone apex (such as for "https://example.com"). 141 Handling situations beyond this within the DNS requires learning 142 additional information, and it is highly desirable to minimize the 143 number of round-trip and lookups required to learn this additional 144 information. 146 1.1. Introductory Example 148 As an introductory example, a set of example HTTPSSVC and associated 149 A+AAAA records might be: 151 www.example.com. 2H IN CNAME svc.example.net. 152 example.com. 2H IN HTTPSSVC 0 0 svc.example.net. 153 svc.example.net. 2H IN HTTPSSVC 1 2 svc3.example.net. "h3=\":8003\"; \ 154 esnikeys=\"...\"" 155 svc.example.net. 2H IN HTTPSSVC 1 3 svc2.example.net. "h2=\":8002\"; \ 156 esnikeys=\"...\"" 157 svc2.example.net. 300 IN A 192.0.2.2 158 svc2.example.net. 300 IN AAAA 2001:db8::2 159 svc3.example.net. 300 IN A 192.0.2.3 160 svc3.example.net. 300 IN AAAA 2001:db8::3 162 In the preceding example, both of the "example.com" and 163 "www.example.com" origin names are aliased to use service endpoints 164 offered as "svc.example.net" (with "www.example.com" continuing to 165 use a CNAME alias). HTTP/2 is available on a cluster of machines 166 located at svc2.example.net with TCP port 8002 and HTTP/3 is 167 available on a cluster of machines located at svc3.example.net with 168 UDP port 8003. An ESNI key is specified which allows the SNI values 169 of "example.com" and "www.example.com" to be encrypted in the 170 handshake with these service endpoints. When connecting, clients 171 will continue to treat the authoritative origins as 172 "https://example.com" and "https://www.example.com", respectively. 174 1.2. Goals of the HTTPSSVC RR 176 The goal of the HTTSSVC RR is to allow clients to resolve a single 177 additional DNS RR in a way that: 179 o Provides service endpoints authoritative for an origin, along with 180 parameters associated with each of these endpoints. In 181 particular: 183 * to support connecting directly to [HTTP3] (QUIC transport) 184 service endpoints 186 * to obtain the [ESNI] keys associated with a service endpoint 188 o Does not assume that all service endpoints have the same 189 parameters (such as ESNI keys) or capabilities (such as [HTTP3]) 190 or are even operated by the same entity. This is important as DNS 191 does not provide any way to tie together multiple RRs for the same 192 name. For example, if www.example.com is a CNAME alias that 193 switches between one of three CDNs or hosting enviroments, records 194 (such as A and AAAA) for that name may have been sourced from 195 different environments. 197 o Enables the functional equivalent of a CNAME at a zone apex (such 198 as "example.com") for HTTPS traffic, and generally enables 199 delegation of operational authority for an HTTPS origin within the 200 DNS to an alternate name. This addresses a set of long-standing 201 issues due to HTTP(S) clients not implementing support for SRV 202 records, as well as due to a limitation that a DNS name can not 203 have both a CNAME record as well as NS RRs (as is the case for 204 zone apex names) 206 1.3. Overview of the HTTPSSVC RR 208 This subsection briefly describes the HTTPSSVC RR in a non-normative 209 manner. 211 The HTTPSSVC RR has four primary fields: 213 1. SvcRecordType: A numeric flag indicating how to interpret the 214 subsequent fields. When "0", it indicates that the RR contains 215 an alias. When "1", it indicates that the RR contains an 216 alternative service definition. 218 2. SvcFieldPriority: The priority of this record (relative to 219 others, with lower values preferred). Applicable when 220 SvcRecordType is "1", and otherwise has value "0". (Described in 221 Section 3.2.) 223 3. SvcDomainName: The domain name of either the alias target (when 224 SvcRecordType is "0") or the uri-host domain name of the 225 alternative service endpoint (when SvcRecordType is "1"). 227 4. SvcFieldValue: An Alternative Service field value describing the 228 alternative service endpoint for the domain name specified in 229 SvcDomainName (only when SvcRecordType is "1" and otherwise 230 empty). 232 Cooperating DNS recursive resolvers will perform subsequent record 233 resolution (for HTTPSSVC, A, and AAAA records) and return them in the 234 Additional Section of the response. Clients must either use 235 responses included in the additional section returned by the 236 recursive resolver or perform necessary HTTPSSVC, A, and AAAA record 237 resolutions. DNS authoritative servers may attach in-bailiwick 238 HTTPSSVC, A, AAAA, and CNAME records in the Additional Section to 239 responses for an HTTPSSVC query. 241 When SvcRecordType is "1", the HTTPSSVC RR extends the concept 242 introduced in the HTTP Alternative Services proposed standard 243 [AltSvc]. Alt-Svc defines: 245 o an extensible data model for describing alternative network 246 endpoints that are authoritative for an origin 248 o the "Alt-Svc Field Value", a text format for representing this 249 information 251 o standards for sending information in this format from a server to 252 a client over HTTP/1.1 and HTTP/2. 254 Together, these components provide a toolkit that has proven useful 255 and effective for informing a client of alternative services for an 256 origin. However, making use of an alternative service requires 257 contacting the origin server first. This creates an obvious 258 performance cost: users wait for a full HTTP connection initiation 259 (multiple roundtrips) before learning of an alternative service that 260 is preferred by the origin. The first connection also publicly 261 reveals the user's intended destination to all entities along the 262 network path. 264 The SvcFieldValue includes the Alt-Svc Field Value through the DNS. 265 This is in its standard text format, with the uri-host portion of the 266 alt-authority component moved into the SvcDomainName field of the 267 HTTPSSVC RR. A client receiving this information during DNS 268 resolution can skip the initial connection and proceed directly to an 269 alternative service. 271 1.4. Additional Alt-Svc parameters 273 This document also defines one additional Alt-Svc parameter that can 274 be used within SvcFieldValue: 276 o esnikeys (Section 7.1): The ESNIKeys structure from Section 4.1 of 277 [ESNI] for use in encrypting the actual origin hostname in the TLS 278 handshake. 280 1.5. Terminology 282 For consistency with [AltSvc], we adopt the following definitions: 284 o An "origin" is an information source as in [RFC6454]. 286 o The "origin server" is the server that the client would reach when 287 accessing the origin in the absence of Alt-Svc. 289 o An "alternative service" is a different server that can serve the 290 origin. 292 Abstractly, the origin consists of a scheme (typically "https"), a 293 host name, and a port (typically "443"). 295 Additional DNS terminology intends to be consistent with [DNSTerm]. 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 299 "OPTIONAL" in this document are to be interpreted as described in BCP 300 14 [RFC2119] [RFC8174] when, and only when, they appear in all 301 capitals, as shown here. 303 2. The HTTPSSVC record type 305 The HTTPSSVC DNS resource record (RR) type (RRTYPE ???) is used to 306 locate endpoints that can service an "https" origin. The 307 presentation format of the record is: 309 RRName TTL Class HTTPSSVC SvcRecordType SvcFieldPriority \ 310 SvcDomainName SvcFieldValue 312 where SvcRecordType is a numeric value of either "0" or "1", 313 SvcFieldPriority is a number in the range 0-65535, SvcDomainName is a 314 domain name, and SvcFieldValue is a string present when SvcRecordType 315 is "1". 317 The algorithm for resolving HTTPSSVC records and associated address 318 records is specified in Section 4.1. 320 2.1. HTTPSSVC RDATA Wire Format 322 The RDATA for the HTTPSSVC RR consists of: 324 o a 1 octet flag field for SvcRecordType, interpreted as an unsigned 325 numeric value (0 to 255, with only values "0" and "1" defined 326 here) 328 o a 2 octet field for SvcFieldPriority as an integer in network byte 329 order. If SvcRecordType is "0", SvcFieldPriority MUST be 0. 331 o the uncompressed SvcDomainName, represented as a sequence of 332 length-prefixed labels as in Section 3.1 of [RFC1035]. 334 o the SvcFieldValue byte string, consuming the remainder of the 335 record (so smaller than 65535 octets and constrained by the RRDATA 336 and DNS message sizes). 338 When SvcRecordType is "0", the SvcFieldValue SHOULD be empty ("") and 339 clients MUST ignore the contents of non-empty SvcFieldValue fields. 341 2.2. RRNames 343 In the case of the HTTPSSVC RR, an origin is translated into the 344 RRName in the following manner: 346 1. If the scheme is "https" and the port is 443, then the RRName is 347 equal to the origin host name. Otherwise the RRName is 348 represented by prefixing the port and scheme with "_", then 349 concatenating them with the host name, resulting in a domain name 350 like "_8443._https.www.example.com.". 352 2. When a prior CNAME or HTTPSSVC record has aliased to an HTTPSSVC 353 record, RRName shall be the name of the alias target. 355 Note that none of these forms alter the HTTPS origin or authority. 356 For example, clients MUST continue to validate TLS certificate 357 hostnames based on the origin host. 359 As an example for schemes and ports other than "https" and port 443: 361 _8443._wss.api.example.com. 2H IN HTTPSSVC 0 0 svc4.example.net. 362 svc4.example.net. 2H IN HTTPSSVC 1 3 svc4.example.net. "h2=\":8004\"; \ 363 esnikeys=\"...\"" 365 would indicate that "wss://api.example.com:8443" is aliased to use 366 HTTP/2 service endpoints offered as "svc4.example.net" on port 8004. 368 2.3. SvcRecordType 370 The SvcRecordType field is a numeric value defined to be either "0" 371 or "1". Within an HTTPSSVC RRSet, all RRs must have the same value 372 for SvcRecordType. Clients and recursive servers MUST ignore 373 HTTPSSVC resource records with other SvcRecordType values. If an 374 RRSet contains a record with type "0", the client MUST ignore any 375 records in the set with type "1". 377 When SvcRecordType is "0", the HTTPSSVC is defined to be in "alias 378 form". 380 When SvcRecordType is "1", the HTTPSSVC is defined to be in 381 "alternative service form". 383 2.4. HTTPSSVC records: alias form 385 When SvcRecordType is "0", the HTTPSSVC record is to be treated 386 similar to a CNAME alias pointing to the domain name specified in 387 SvcDomainName. HTTPSSVC RRSets MUST only have a single resource 388 record in this form. If multiple are present, clients or recursive 389 resolvers SHOULD pick one non-determinstically. 391 The common use-case for this form of the HTTPSSVC record is as an 392 alternative to CNAMEs at the zone apex where they are not allowed. 393 For example, if an operator of https://example.com wanted to point 394 HTTPS requests to a service operating at svc.example.net, they would 395 publish a record such as: 397 example.com. 3600 IN HTTPSSVC 0 0 svc.example.net. 399 The SvcDomainName MUST point to a domain name that contains another 400 HTTPSSVC record and/or address (AAAA and/or A) records. 402 Note that the RRName and the SvcDomainName MAY themselves be CNAMEs. 403 Clients and recursive resolvers MUST follow CNAMEs as normal. 405 Due to the risk of loops, clients and recursive resolvers MUST 406 implement loop detection. Chains of consecutive HTTPSSVC and CNAME 407 records SHOULD be limited to (8?) prior to reaching terminal address 408 records. 410 The SvcFieldValue in this form SHOULD be an empty string and clients 411 MUST ignore its contents. 413 As legacy clients will not know to use this record, service operators 414 will likely need to retain fallback AAAA and A records alongside this 415 HTTPSSVC record, although in a common case the target of the HTTPSSVC 416 record might have better performance, and therefore would be 417 preferable for clients implementing this specification to use. 419 2.5. HTTPSSVC records: alternative service form 421 When SvcRecordType is "1", the combination of SvcDomainName and 422 SvcFieldValue within each resource record associates an Alternative 423 Service Field Value with an origin. 425 The SvcFieldValue of the HTTPSSVC resource record contains an Alt-Svc 426 Field Value, exactly as defined in Section 4 of [AltSvc], but with 427 the uri-host moved to the SvcDomainName field. 429 For example, if the operator of https://www.example.com intends to 430 include an HTTP response header like 431 Alt-Svc: h3="svc.example.net:8003"; ma=3600, \ 432 h2="svc.example.net:8002"; ma=3600 434 they could also publish an HTTPSSVC DNS RRSet like 436 www.example.com. 3600 IN HTTPSSVC 1 2 svc.example.net. "h3=\":8003\"" 437 HTTPSSVC 1 3 svc.example.net. "h2=\":8002\"" 439 This data type can be represented as an Unknown RR as described in 440 [RFC3597]: 442 www.example.com. 3600 IN TYPE??? \\# TBD:WRITEME 444 This construction is intended to be extensible in two ways. First, 445 any extensions that are made to the Alt-Svc format for transmission 446 over HTTPS are also applicable here, unless expressly mentioned 447 otherwise. 449 Second, by defining a way to map non-HTTPS schemes and non-default 450 ports (Section 2.2), we provide a way for the HTTPSSVC to be used for 451 them as needed. However, by using the origin name for the RRName for 452 scheme https and port 443 we allow HTTPSSVC records to be included at 453 the end of CNAME chains for existing site implementations without 454 requiring changes in the zone containing the origin. 456 3. Differences from Alt-Svc as transmitted over HTTP 458 Publishing an alternative services form HTTPSSVC record in DNS is 459 intended to be equivalent to transmitting this field value over 460 HTTPS, and receiving an HTTPSSVC record is intended to be equivalent 461 to receiving this field value over HTTPS. However, there are some 462 small differences in the intended client and server behavior. 464 3.1. Omitting Max Age and Persist 466 When publishing an HTTPSSVC record in DNS, server operators MUST omit 467 the "ma" parameter, which encodes the "max age" (i.e. expiration 468 time) of an Alt-Svc Field Value. Instead, server operators SHOULD 469 encode the expiration time in the DNS TTL, and MUST NOT set a TTL 470 longer than the intended "max age". 472 When receiving an HTTPSSVC record, clients SHOULD synthesize a new 473 "ma" parameter from the DNS TTL if the resulting alt-value is being 474 passed to a subsystem that might employ caching. 476 When publishing an HTTPSSVC record, server operators MUST omit the 477 "persist" parameter, which indicates whether the client should use 478 this record on other network paths. When receiving an HTTPSSVC 479 record, clients MUST discard any records that contain a "persist" 480 flag. Disabling persistence is important to prevent a local 481 adversary in one network from implanting a forged DNS record that 482 allows them to track users or hinder their connections after they 483 leave that network. 485 3.2. Multiple records and preference ordering 487 Server operators MAY publish multiple SvcRecordType "1" HTTPSSVC 488 records as an RRSET. When converting a collection of alt-values into 489 an HTTPSSVC RRSET, the server operator MUST set the overall TTL to a 490 value no larger than the minimum of the "max age" values (following 491 Section 5.2 of [RFC2181]). 493 Each RR MUST contain exactly one alt-value, as described in Section 3 494 of [AltSvc]. 496 As RRs within an RRSET are explicitly unordered collections, the 497 SvcFieldPriority value is introduced to indicate priority. HTTPSSVC 498 RRs with a smaller SvcFieldPriority value SHOULD be given preference 499 over RRs with a larger SvcFieldPriority value. 501 Alt-values received via HTTPS are preferred over any Alt-value 502 received via DNS. 504 When receiving an RRSET containing multiple HTTPSSVC records with the 505 same SvcFieldPriority value, clients SHOULD apply a random shuffle 506 within a priority level to the records before using them, to ensure 507 randomized load-balancing. 509 3.3. Constructing Alt-Svc equivalent headers 511 For a client to construct the equivalent of an Alt-Svc HTTP response 512 header: 514 1. For each RR, the SvcDomainName MUST be inserted as the uri-host. 515 If SvcDomainName is has the value "." then the RRNAME for the 516 final HTTPSSVC record MUST be inserted as the uri-host. (In the 517 case of a CNAME or a HTTPSSVC SvcRecordType "0" record pointing 518 to an HTTPSSVC record with SvcRecordType "1" and SvcDomainName 519 "." then it is the RRNAME for the terminal HTTPSSVC record that 520 must be inserted as the uri-host.) 522 2. The RRs SHOULD be ordered by increasing SvcFieldPriority, with 523 shuffling for equal SvcFieldPriority values. Clients MAY choose 524 to further prioritize alt-values where address records are 525 immediately available for the alt-value's SvcDomainName. 527 3. The client SHOULD concatenate the thus-transformed-and-ordered 528 SvcFieldValues in the RRSET, separated by commas. (This is 529 semantically equivalent to receiving multiple Alt-Svc HTTP 530 response headers, according to Section 3.2.2 of [HTTP]). 532 3.4. Granularity and lifetime control 534 Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc 535 Field Value specifically to the client. When using an HTTPSSVC DNS 536 record, groups of clients will necessarily receive the same Alt-Svc 537 Field Value. Therefore, this standard is not suitable for uses that 538 require single-client granularity in Alt-Svc. 540 Some DNS caching systems incorrectly extend the lifetime of DNS 541 records beyond the stated TTL. Server operators MUST NOT rely on 542 HTTPSSVC records expiring on time, and MAY shorten the TTL to 543 compensate. 545 4. Client behaviors 547 4.1. Client resolution 549 When attempting to resolve a name HOST, clients should follow in- 550 order: 552 1. Issue parallel AAAA/A and HTTPSSVC queries for the name HOST. 553 The answers for these may or may not include CNAME pointers 554 before reaching one or more of these records. 556 2. If an HTTPSSVC record of SvcRecordType "0" is returned for HOST, 557 clients should loop back to step 1 replacing HOST with 558 SvcDomainName, subject to loop detection heuristics. 560 3. If one or more HTTPSSVC record of SvcRecordType "1" is returned 561 for HOST, clients should synthesize equivalent Alt-Svc Field 562 Values based on the SvcDomainName and SvcFieldValue. If one of 563 these alt-values is selected to be used in a connection, the 564 client will need to resolve AAAA and/or A records for 565 SvcDomainName. 567 4. If only AAAA and/or A records are present for HOST (and no 568 HTTPSSVC), clients should make a connection to one of the IP 569 addresses contained in these records and proceed normally. 571 When selecting between AAAA and A records to use, clients may use an 572 approach such as [HappyEyeballsV2] 573 Some possible optimizations are discussed in Section 6 to reduce 574 latency impact in comparison to ordinary AAAA/A lookups. 576 4.2. HTTP Strict Transport Security 578 By publishing an HTTPSSVC record, the server operator indicates that 579 all useful HTTP resources on that origin are reachable over HTTPS, 580 similar to HTTP Strict Transport Security [HSTS]. When an HTTPSSVC 581 record is present for an origin, all "http" scheme requests for that 582 origin SHOULD logically be redirected to "https". 584 Prior to making an "http" scheme request, the client SHOULD perform a 585 lookup to determine if an HTTPSSVC record is available for that 586 origin. To do so, the client SHOULD construct a corresponding 587 "https" URL as follows: 589 1. Replace the "http" scheme with "https". 591 2. If the "http" URL explicitly specifies port 80, specify port 443. 593 3. Do not alter any other aspect of the URL. 595 This construction is equivalent to Section 8.3 of [HSTS] , point 5. 597 If an HTTPSSVC record is present for this "https" URL, the client 598 should treat this as the equivalent of receiving an HTTP "307 599 Temporary Redirect" redirect to the "https" URL. Because HTTPSSVC is 600 received over an often insecure channel (DNS), clients MUST NOT place 601 any more trust in this signal than if they had received a 307 602 redirect over cleartext HTTP. 604 If the HTTPSSVC query results in a SERVFAIL error, and the connection 605 between the client and the recursive resolver is cryptographically 606 protected (e.g. using TLS [RFC7858] or HTTPS [RFC8484]), the client 607 SHOULD abandon the connection attempt and display an error message. 608 A SERVFAIL error can occur if the domain is DNSSEC-signed, the 609 recursive resolver is DNSSEC-validating, and an active attacker 610 between the recursive resolver and the authoritative DNS server is 611 attempting to prevent the upgrade to HTTPS. 613 Similarly, if the client enforces DNSSEC validation on A/AAAA RRs, it 614 SHOULD abandon the connection attempt if the HTTPSSVC RR fails to 615 validate. 617 4.3. Cache interaction 619 If the client has an Alt-Svc cache, and a usable Alt-Svc value is 620 present in that cache, then the client SHOULD NOT issue an HTTPSSVC 621 DNS query. Instead, the client SHOULD proceed with alternative 622 service connection as usual. 624 If the client has a cached Alt-Svc entry that is expiring, the client 625 MAY perform an HTTPSSVC query to refresh the entry. 627 5. DNS Server Behaviors 629 Recursive DNS servers SHOULD resolve SvcDomainName records and 630 include them in the Additional Section (along with any relevant CNAME 631 records). For SvcRecordType=0, recursive DNS servers SHOULD attempt 632 to resolve and include A, AAAA, and HTTPSSVC records. For 633 SvcRecordType=1, recursive DNS servers SHOULD attempt to resolve and 634 include A and AAAA records. 636 Authoritative DNS servers SHOULD return A, AAAA, and HTTPSSVC records 637 (as well as any relevant CNAME records) in the Additional Section for 638 any in-bailiwick SvcDomainNames. 640 6. Performance optimizations 642 For optimal performance (i.e. minimum connection setup time), clients 643 SHOULD issue address (AAAA and/or A) and HTTPSSVC queries 644 simultaneously, and SHOULD implement a client-side DNS cache. With 645 these optimizations in place, and conforming DNS servers, using 646 HTTPSSVC does not add network latency to connection setup. 648 A nonconforming recursive resolver might return an HTTPSSVC response 649 with a nonempty SvcDomainName, without the corresponding address 650 records. If all the HTTPSSVC RRs in the response have nonempty 651 SvcDomainName values, and the client does not have address records 652 for any of these values in its DNS cache, the client SHOULD perform 653 an additional address query for the selected SvcDomainName. 655 The additional DNS query in this case introduces a delay. To avoid 656 causing a delay for clients using a nonconforming recursive resolver, 657 domain owners SHOULD choose the SvcDomainName to be a name in the 658 origin hostname's CNAME chain if possible. This will ensure that the 659 required address records are already present in the client's DNS 660 cache as part of the responses to the address queries that were 661 issued in parallel. 663 Highly performance-sensitive clients MAY implement the following 664 special- case shortcut to avoid increased connection time: if (1) one 665 of the HTTPSSVC records returned has SvcRecordType=0, (2) its 666 SvcDomainName is not in the DNS cache, and (3) the address queries 667 for the origin domain return usable IP addresses, then the client MAY 668 ignore the HTTPSSVC records and connect directly to the origin 669 domain. When the SvcDomainNames and any needed HTTPSSVC records are 670 available, the client SHOULD make subsequent requests over 671 connections specified by the HTTPSSVC records. 673 Server operators can therefore expect that publishing HTTPSSVC 674 records with SvcRecordType=0 should not cause an additional DNS query 675 for performance-sensitive clients. Server operators who wish to 676 prevent this optimization should use SvcRecordType=1. 678 7. Extensions to enhance privacy 680 7.1. Alt-Svc parameter for ESNI keys 682 An Alt-Svc "esnikeys" parameter is defined for specifying ESNI keys 683 corresponding to an alternative service. The value of the parameter 684 is an ESNIKeys structure [ESNI] encoded in [base64], or the empty 685 string. ESNI-aware clients SHOULD prefer alt-values with nonempty 686 esnikeys. 688 This parameter MAY also be sent in Alt-Svc HTTP response headers and 689 HTTP/2 ALTSVC frames. 691 The Alt-Svc specification states that "the client MAY fall back to 692 using the origin" in case of connection failure [AltSvc]. This 693 behavior is not suitable for ESNI, because fallback would negate the 694 privacy benefits of ESNI. 696 Accordingly, any connection attempt that uses ESNI MUST fall back 697 only to another alt-value that also has the esnikeys parameter. If 698 the parameter's value is the empty string, the client SHOULD connect 699 as it would in the absence of any ESNIKeys information. 701 For example, suppose a server operator has two alternatives. 702 Alternative A is reliably accessible but does not support ESNI. 703 Alternative B supports ESNI but is not reliably accessible. The 704 server operator could include a full esnikeys value in Alternative B, 705 and mark Alternative A with esnikeys="" to indicate that fallback 706 from B to A is allowed. 708 7.2. Interaction with other standards 710 The purpose of this standard is to reduce connection latency and 711 improve user privacy. Server operators implementing this standard 712 SHOULD also implement TLS 1.3 [RFC8446] and OCSP Stapling [RFC6066], 713 both of which confer substantial performance and privacy benefits 714 when used in combination with HTTPSSVC records. 716 To realize the greatest privacy benefits, this proposal is intended 717 for use with a privacy-preserving DNS transport (like DNS over TLS 718 [RFC7858] or DNS over HTTPS [RFC8484]). However, performance 719 improvements, and some modest privacy improvements, are possible 720 without the use of those standards. 722 This RRType could be extended to support schemes other than "https". 723 Any such scheme MUST have an entry under the HTTPSSVC RRType in the 724 IANA DNS Underscore Global Scoped Entry Registry [Attrleaf] The 725 scheme SHOULD have an entry in the IANA URI Schemes Registry 726 [RFC7595]. The scheme SHOULD be one for which Alt-Svc is defined. 728 8. Security Considerations 730 Alt-Svc Field Values are intended for distribution over untrusted 731 channels, and clients are REQUIRED to verify that the alternative 732 service is authoritative for the origin (Section 2.1 of [AltSvc]). 733 Therefore, DNSSEC signing and validation are OPTIONAL for publishing 734 and using HTTPSSVC records. 736 TBD: expand this section in more detail. In particular: * Just as 737 with [AltSvc], clients must validate the TLS server certificate 738 against hostname associated with the origin. Clients MUST NOT use 739 the SvcDomainName as any part of the server TLS certificate 740 validation. * ... 742 9. IANA Considerations 744 Per [RFC6895], please add the following entry to the data type range 745 of the Resource Record (RR) TYPEs registry: 747 +----------+------------------------+-----------------+ 748 | TYPE | Meaning | Reference | 749 +----------+------------------------+-----------------+ 750 | HTTPSSVC | HTTPS Service Location | (This document) | 751 +----------+------------------------+-----------------+ 753 Per [Attrleaf], please add the following entries to the DNS 754 Underscore Global Scoped Entry Registry: 756 +----------+------------+-------------------+-----------------+ 757 | RR TYPE | _NODE NAME | Meaning | Reference | 758 +----------+------------+-------------------+-----------------+ 759 | HTTPSSVC | _https | Alt-Svc for HTTPS | (This document) | 760 +----------+------------+-------------------+-----------------+ 762 Per [AltSvc], please add the following entries to the HTTP Alt-Svc 763 Parameter Registry: 765 +-------------------+--------------------+-----------------+ 766 | Alt-Svc Parameter | Meaning | Reference | 767 +-------------------+--------------------+-----------------+ 768 | esnikeys | Encrypted SNI keys | (This document) | 769 +-------------------+--------------------+-----------------+ 771 10. Acknowledgements and Related Proposals 773 There have been a wide range of proposed solutions over the years to 774 the "CNAME at the Zone Apex" challenge proposed. These include 775 [I-D.draft-bellis-dnsop-http-record-00], 776 [I-D.draft-ietf-dnsop-aname-03], and others. 778 Thank you to Ian Swett, Ralf Weber, Jon Reed, Martin Thompson, Lucas 779 Pardue, Ilari Liusvaara, and others for their feedback and 780 suggestions on this draft. 782 11. References 784 11.1. Normative References 786 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 787 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 788 April 2016, . 790 [AltSvcSNI] 791 Bishop, M., "The "SNI" Alt-Svc Parameter", draft-bishop- 792 httpbis-sni-altsvc-02 (work in progress), May 2018. 794 [Attrleaf] 795 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 796 of Attribute Leaves", draft-ietf-dnsop-attrleaf-16 (work 797 in progress), November 2018. 799 [base64] Josefsson, S., "The Base16, Base32, and Base64 Data 800 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 801 . 803 [ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 804 "Encrypted Server Name Indication for TLS 1.3", draft- 805 ietf-tls-esni-03 (work in progress), March 2019. 807 [HappyEyeballsV2] 808 Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 809 Better Connectivity Using Concurrency", RFC 8305, 810 DOI 10.17487/RFC8305, December 2017, 811 . 813 [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 814 Transport Security (HSTS)", RFC 6797, 815 DOI 10.17487/RFC6797, November 2012, 816 . 818 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 819 (HTTP/3)", draft-ietf-quic-http-20 (work in progress), 820 April 2019. 822 [RFC1035] Mockapetris, P., "Domain names - implementation and 823 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 824 November 1987, . 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 . 831 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 832 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 833 . 835 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 836 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 837 2003, . 839 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 840 Extensions: Extension Definitions", RFC 6066, 841 DOI 10.17487/RFC6066, January 2011, 842 . 844 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 845 DOI 10.17487/RFC6454, December 2011, 846 . 848 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 849 and Registration Procedures for URI Schemes", BCP 35, 850 RFC 7595, DOI 10.17487/RFC7595, June 2015, 851 . 853 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 854 and P. Hoffman, "Specification for DNS over Transport 855 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 856 2016, . 858 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 859 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 860 May 2017, . 862 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 863 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 864 . 866 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 867 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 868 . 870 11.2. Informative References 872 [DNSTerm] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 873 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 874 January 2019, . 876 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 877 Protocol (HTTP/1.1): Message Syntax and Routing", 878 RFC 7230, DOI 10.17487/RFC7230, June 2014, 879 . 881 [I-D.draft-bellis-dnsop-http-record-00] 882 Bellis, R., "A DNS Resource Record for HTTP", draft- 883 bellis-dnsop-http-record-00 (work in progress), November 884 2018. 886 [I-D.draft-ietf-dnsop-aname-03] 887 Finch, T., Hunt, E., Dijk, P., Eden, A., and W. Mekking, 888 "Address-specific DNS aliases (ANAME)", draft-ietf-dnsop- 889 aname-03 (work in progress), April 2019. 891 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 892 specifying the location of services (DNS SRV)", RFC 2782, 893 DOI 10.17487/RFC2782, February 2000, 894 . 896 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 897 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 898 April 2013, . 900 Appendix A. Additional examples 902 A.1. Equivalence to Alt-Svc records 904 The following: 906 www.example.com. 2H IN CNAME svc.example.net. 907 example.com. 2H IN HTTPSSVC 0 0 svc.example.net. 908 svc.example.net. 2H IN HTTPSSVC 1 2 svc3.example.net. "h3=\":8003\"; \ 909 esnikeys=\"ABC...\"" 910 svc.example.net. 2H IN HTTPSSVC 1 3 . "h2=\":8002\"; \ 911 esnikeys=\"123...\"" 913 is equivalent to the Alt-Svc record: 915 Alt-Svc: h3="svc3.example.net:8003"; esnikeys="ABC..."; ma=7200, \ 916 h2="svc.example.net:8002"; esnikeys="123..."; ma=7200 918 for the origins of both "https://www.example.com" and 919 "https://example.com". 921 Appendix B. Comparison with alternatives 923 The HTTPSSVC record type closely resembles some existing record types 924 and proposals. A complaint with all of the alternatives is that web 925 clients have seemed unenthusiastic about implementing them. The hope 926 here is that by providing an extensible solution that solves multiple 927 problems we will overcome the inertia and have a path to achieve 928 client implementation. 930 B.1. Differences from the SRV RRTYPE 932 An SRV record [RFC2782] can perform a similar function to the 933 HTTPSSVC record, informing a client to look in a different location 934 for a service. However, there are several differences: 936 o SRV records are typically mandatory, whereas clients will always 937 continue to function correctly without making use of Alt-Svc or 938 HTTPSSVC. 940 o SRV records cannot instruct the client to switch or upgrade 941 protocols, whereas Alt-Svc can signal such an upgrade (e.g. to 942 HTTP/2). 944 o SRV records are not extensible, whereas Alt-Svc and thus HTTPSSVC 945 can be extended with new parameters. For example, this is what 946 allows the incorporation of ESNI keys in HTTPSSVC. 948 o Using SRV records would not allow a client to skip processing of 949 the Alt-Svc information in a subsequent connection, so it does not 950 confer a performance advantage. 952 B.2. Differences from the proposed HTTP record 954 Unlike [I-D.draft-bellis-dnsop-http-record-00], this approach is 955 extensible to cover Alt-Svc and ESNIKeys use-cases. Like that 956 proposal, this addresses the zone apex CNAME challenge. 958 Like that proposal it remains necessary to continue to include 959 address records at the zone apex for legacy clients. 961 B.3. Differences from the proposed ANAME record 963 Unlike [I-D.draft-ietf-dnsop-aname-03], this approach is extensible 964 to cover Alt-Svc and ESNIKeys use-cases. This approach also does not 965 require any changes or special handling on either authoritative or 966 master servers, beyond optionally returning in-bailiwick additional 967 records. 969 Like that proposal, this addresses the zone apex CNAME challenge for 970 clients that implement this. 972 However with this HTTPSSVC proposal it remains necessary to continue 973 to include address records at the zone apex for legacy clients. If 974 deployment of this standard is successful, the number of legacy 975 clients will fall over time. As the number of legacy clients 976 declines, the operational effort required to serve these users 977 without the benefit of HTTPSSVC indirection should fall. Server 978 operators can easily observe how much traffic reaches this legacy 979 endpoint, and may remove the apex's address records if the observed 980 legacy traffic has fallen to negligible levels. 982 B.4. Differences from the proposed ESNI record 984 Unlike [ESNI], this approach is extensible and covers the Alt-Svc 985 case as well as addresses the zone apex CNAME challenge. 987 By using the Alt-Svc model we also provide a way to solve the ESNI 988 multi-CDN challenges in a general case. 990 Unlike ESNI, this is focused on the specific case of HTTPS, although 991 this approach could be extended for other protocols. It also allows 992 specifying ESNI keys for a specific port, not an entire host. 994 B.5. SNI Alt-Svc parameter 996 Defining an Alt-Svc sni= parameter (such as from [AltSvcSNI]) would 997 have provided some benefits to clients and servers not implementing 998 ESNI, such as for specifying that "_wildcard.example.com" could be 999 sent as an SNI value rather than the full name. There is nothing 1000 precluding HTTPSSVC from being used with an sni= parameter if one 1001 were to be defined, but it is not included here to reduce scope, 1002 complexity, and additional potential security and tracking risks. 1004 Appendix C. Design Considerations and Open Issues 1006 This draft is intended to be a work-in-progress for discussion. Many 1007 details are expected to change with subsequent refinement. Some 1008 known issues or topics for discussion are listed below. 1010 C.1. Record Name 1012 Naming is hard. The "HTTPSSVC" is proposed as a placeholder. Other 1013 names for this record might include ALTSVC, HTTPS, HTTPSSRV, B, or 1014 something else. 1016 C.2. Applicability to other schemes 1018 The focus of this record is on optimizing the common case of the 1019 "https" scheme. It is worth discussing whether this is a valid 1020 assumption or if a more general solution is applicable. Past efforts 1021 to over-generalize have not met with broad success. 1023 C.3. Wire Format 1025 Advice from experts in DNS wire format best practices would be 1026 greatly appreciated to refine the proposed details, overall. 1028 C.4. Extensibility of SvcRecordType 1030 Only values of "0" and "1" are allowed for SvcRecordType. Should we 1031 give more thought to potential future values? The current version 1032 tries to leave this open by indicating that resource records with 1033 unknown SvcRecordType values should be ignored (and perhaps should be 1034 switched to MUST be ignored)? 1036 C.5. Where to include Priority 1038 The SvcFieldPriority could alternately be included as a pri= Alt-Svc 1039 attribute. It wouldn't be applicable for Alt-Svc returned via HTTP, 1040 but it is also not necessarily needed by DNS servers. It is also not 1041 used when SvcRecordType=0. A related question is whether to omit it 1042 from the textual representation when SvcRecordType=0. Regardless, 1043 having a series of sequential numeric values in the textual 1044 representation has risk of user error, especially as MX, SRV, and 1045 others all have their own variations here. 1047 C.6. Whether to include Weight 1049 Some other similar mechanisms such as SRV have a weight in-addition 1050 to priority. That is excluded here for simplicity. It could always 1051 be added as an optional Alt-Svc attribute. 1053 Appendix D. Change history 1055 o draft-nygren-httpbis-httpssvc-03 1057 * Change redirect type for HSTS-style behavior from 302 to 307 to 1058 reduce ambiguities. 1060 o draft-nygren-httpbis-httpssvc-02 1062 * Remove the redundant length fields from the wire format. 1064 * Define a SvcDomainName of "." for SvcRecordType=1 as being the 1065 HTTPSSVC RRNAME. 1067 * Replace "hq" with "h3". 1069 o draft-nygren-httpbis-httpssvc-01 1071 * Fixes of record name. Replace references to "HTTPSVC" with 1072 "HTTPSSVC". 1074 o draft-nygren-httpbis-httpssvc-00 1076 * Initial version 1078 Authors' Addresses 1080 Ben Schwartz 1081 Google 1083 Email: bemasc@google.com 1085 Mike Bishop 1086 Akamai Technologies 1088 Email: mbishop@evequefou.be 1089 Erik Nygren 1090 Akamai Technologies 1092 Email: erik+ietf@nygren.org