idnits 2.17.1 draft-nygren-altsvc-fixes-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 301: '...suboptimal. Therefore, clients SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 June 2021) is 1043 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-10 == Outdated reference: A later version (-02) exists of draft-thomson-tls-snip-01 == Outdated reference: A later version (-12) exists of draft-ietf-dnsop-svcb-https-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group E. Nygren 3 Internet-Draft Akamai 4 Intended status: Informational 11 June 2021 5 Expires: 13 December 2021 7 Alt-Svc Fixes and Feature Candidates 8 draft-nygren-altsvc-fixes-00 10 Abstract 12 HTTP Alternative Services has become the primary mechanism for HTTP/3 13 upgrade, but overlaps with and disagrees with other developing 14 standards, such as the HTTPS resource record in DNS. This document 15 explores a set of potential fixes and/or additional features for Alt- 16 Svc. It is used to record and share thoughts, and is not expected to 17 progress on its own. 19 Discussion Venues 21 This note is to be removed before publishing as an RFC. 23 Discussion of this document takes place on the mailing list 24 (httpbis@ietf.org), which is archived at 25 https://mailarchive.ietf.org/arch/browse/httpbis/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/MikeBishop/alt-svc-bis. 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 13 December 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Potential Scope Items . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Incorporating errata and Editorial improvements . . . . . 3 66 2.2. Fix ALPN handling . . . . . . . . . . . . . . . . . . . . 3 67 2.3. Address concerns about Alt-Svc lifetime bounding . . . . 4 68 2.4. Support ECH . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.5. Better Interactions with HTTPS Record . . . . . . . . . . 4 70 2.6. HTTP/3 Frame Definition . . . . . . . . . . . . . . . . . 5 71 2.7. Accept-Alt-Svc Request Header . . . . . . . . . . . . . . 5 72 2.8. Improve/Replace Alt-Used Header . . . . . . . . . . . . . 5 73 2.9. Path-Scoped Alt-Svc . . . . . . . . . . . . . . . . . . . 6 74 2.10. Persist and Caching Concerns . . . . . . . . . . . . . . 7 75 2.11. Radical Simplification . . . . . . . . . . . . . . . . . 8 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5. Informative References . . . . . . . . . . . . . . . . . . . 8 79 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Overview 84 Alt-Svc [AltSvc] was published in April of 2016. Since then, it has 85 become the primary mechanism to upgrade connections to HTTP/3, at 86 least until HTTPS RRs [SVCB] are standardized and widely supported. 88 This brainstorms a set of potential fixes and feature candidates for 89 an Alt-Svc BIS. In the spirit of brainstorming, some of the things 90 in this list may be bad ideas. One of the points of this document is 91 to judge interest in each of these items to determine what potential 92 authors may be interested in including in a draft. 94 A number of these items were deferred out of the SVCB/HTTPS draft. 95 Others are based on regrets from implementation experience with 96 AltSvc. A few are potentially valuable features. 98 It is not yet defined whether this should be a new header or can be 99 done via extensions to Alt-Svc as it exists today. 101 A number of major clients have yet to implement Alt-Svc to other 102 hostnames fully, and some of this is due to concerns that they have 103 with the current specification. 105 It may make sense to split this list into batches, but another option 106 would be to try and get all of these done at once even if as separate 107 but cooperating drafts. 109 2. Potential Scope Items 111 2.1. Incorporating errata and Editorial improvements 113 (Hopefully this is non-controversial.) 115 Includes: 117 * Incorporate errata 119 * Reference RFC 8336 "ORIGIN Frames" (regarding disabling connection 120 coalescing) 122 * Incorporate [I-D.pardue-httpbis-dont-be-clear] 124 * ... 126 2.2. Fix ALPN handling 128 The ALPN semantics in [AltSvc] are ambiguous, and problematic in some 129 interpretations. We should update [AltSvc] to give it well-defined 130 semantics that match the HTTPS RRs. For example, specify that the 131 ALPN [ALPN] negotiated via the TLS handshake does not need to be the 132 same as the ALPN indicated in the AltSvc. 134 (From HTTPS RR #246 (https://github.com/MikeBishop/dns-alt-svc/ 135 issues/246) and other discussion threads during HTTPS RR. David 136 Benjamin also has strong opinions on this topic.) 138 One option would be to pull in the text we landed on for the HTTPS/ 139 SVCB draft, see Section 6.1 of [SVCB]. See also 140 [I-D.thomson-tls-snip]. 142 2.3. Address concerns about Alt-Svc lifetime bounding 144 Some people have expressed concerns that Alt-Svc allows a compromised 145 Origin to hold onto clients forever by continuing to offer updated 146 Alt-Svc entries. There may be ways to reduce the vulnerability 147 exposure here, such as by periodic reconfirmation with the "real" 148 origin or something it controls. This is of particular concern when 149 an Alt-Svc record has a much longer lifetime than an HTTPS RR. 151 For example, if the Alt-Svc records were signed with a key published 152 in DNS. Records remain valid so long as the key that signed them is 153 still claimed by the domain. An unsigned record has a very short 154 lifetime bound. 156 2.4. Support ECH 158 The HTTPS RR [SVCB] is currently the only way to retrieve keys for 159 Encrypted Client Hello [ECH]. To maintain security, it puts Alt-Svc 160 out-of-scope, since Alt-Svc cannot deliver ECH keys. 162 Two options (and there may be more) include: 164 * Add an ech= parameter to Alt-Svc 166 * Defining some better integration between Alt-Svc and HTTPS RRs. 167 For example, allow an AltSvc server name to be treated as an 168 "AliasMode" reference to an HTTPS record. 170 2.5. Better Interactions with HTTPS Record 172 This was deferred out of the HTTPS RR draft. There are a number of 173 design options here, but requirements and pros/cons will want to be 174 discussed in-detail before proposing designs. Supporting ECH and 175 Alt-Svc together is a primary goal. 177 An important item here is which takes precedence, providing safe and 178 time-bounded ways to allow Alt-Svc to take precedence over HTTPS 179 records. Alt-Svc has the ability to be delivered in a user-specific 180 manner -- useful operationally, but potentially problematic for 181 privacy. HTTPS records can be easily revalidated, which is more 182 difficult with an Alt-Svc record. 184 Providing a way for Alt-Svc to act as AliasMode references to HTTPS 185 SvcMode records seems like one clean way for interaction in that it 186 avoids needing to duplicate SVCB in Alt-Svc. We would still need to 187 address time-bounding and trust considerations. 189 2.6. HTTP/3 Frame Definition 191 The ALTSVC frame has not been defined for HTTP/3. Perhaps it should 192 be [I-D.bishop-httpbis-altsvc-quic]. Alternatively, if the frame has 193 not been widely adopted, should it be deprecated from HTTP/2 instead? 195 2.7. Accept-Alt-Svc Request Header 197 There is significant variation in client support for the Alt-Svc 198 specification, including some clients which only implement a subset 199 of the specification. Having an Accept-Alt-Svc request header that 200 lists a set of supported Alt-Svc features allows for extension of 201 Alt-Svc but also allows for deprecation. 203 If we don't deprecate the frames, we'd also need a SETTINGS 204 equivalent. 206 There are potential client fingerprinting concerns here, so we'll 207 want to not go too far with this. 209 2.8. Improve/Replace Alt-Used Header 211 There is limited implementation support for Alt-Used out of privacy 212 concerns. It also only sends a subset of the Alt-Svc record being 213 used, and there are unclear interactions between Alt-Used and HTTPS 214 RRs. 216 Daniel Stenberg points out: 218 Alt-Used (RFC 7838 section 5) is a request header that only sends 219 host name + port number, with no hint if that port number is TCP 220 or UDP (or ALPN name), which makes at least one large HTTP/3 221 deployment trigger its Alt-Svc loop detection when only switching 222 protocols to h3. 224 It is proposed that we replace or redefine Alt-Used and also define 225 how it interacts with SVCB. Note that hostile origins have many 226 knobs for getting this information (e.g., encoding in hostnames, 227 ports, or IPv6 addresses) so a goal would be to allow non-hostile 228 origins to get information on which Alt-Svc or SVCB record is being 229 used in a way that doesn't make things worse from a privacy 230 perspective. 232 Some options include: 234 * Just send the whole Alt-Svc or SVCB binding used in the header 235 * Have a param encoding an N-bit or N-character value for the 236 record-id. This value would be sent as Alt-Used. How many bits 237 to use is an open question. 239 - Allowing for a dynamic length where the client chooses how many 240 bits or characters to include based on privacy budget is one 241 attractive but complicated option. Server implementers would 242 put the most important info into earlier bits/characters. 244 The goal here is to allow for virtual hosting of alternative 245 services, allowing the server to know which alternative service was 246 used (eg, for load feedback, diagnostics/debugging, loop detection, 247 and other operational purposes), but without hacks like separate 248 ports or IP addresses that leak information to passive network 249 observers. 251 The usefulness of Alt-Used is currently limited by the fact that most 252 servers simply send ":443" and some clients won't consider any other 253 alternative offered. 255 See some discussion and other options here 256 (https://github.com/MikeBishop/dns-alt-svc/issues/107). 258 2.9. Path-Scoped Alt-Svc 260 The largest-scope, most disruptive, and perhaps most controversial 261 item would be to allow Alt-Svc to be scoped to URL paths with a way 262 to indicate that transitions to use the Alt-Svc should be done 263 synchronously. 265 This is desired for use-cases of large content libraries where an 266 Origin would like to have clients use different endpoints for 267 different objects while sharing a single Origin. This would also 268 likely need negotiation. 270 This use-case is similar to that served by 271 [I-D.reschke-http-oob-encoding], which is one possible solution. In 272 that model, the origin retains control of the entire namespace while 273 delegating delivery of particular objects to other endpoints. 275 Extending Alt-Svc is another approach which might allow more 276 flexibility. For example: 278 * Client indicates via a request header (eg, Accept-*) or a SETTING 279 that it supports this feature 281 * Server's Alt-Svc indicates that the path="/movies/ 282 MurderOnTheExampleExpress/" should be accessed by a particular 283 alternative service 285 * Server returns a new 3xx response header response header 286 indicating that the Alt-Svc should be used synchronously to fetch 287 the response 289 2.10. Persist and Caching Concerns 291 [AltSvc] defines the "persist" parameter. 293 Alternative services that are intended to be longer lived (such as 294 those that are not specific to the client access network) can 295 carry the "persist" parameter with a value "1" as a hint that the 296 service is potentially useful beyond a network configuration 297 change. 299 When alternative services are used to send a client to the most 300 optimal server, a change in network configuration can result in 301 cached values becoming suboptimal. Therefore, clients SHOULD 302 remove from cache all alternative services that lack the "persist" 303 flag with the value "1" when they detect such a change, when 304 information about network state is available. 306 For some clients (e.g. cURL), detecting network changes is very 307 tricky. Certain clients default to behaving like persist=1 for all 308 alternatives. 310 The RFC text today seems to imply that servers factor in client 311 network properties when deciding what to advertise. That is not true 312 for all deployments. The recommendation that a client invalidate 313 Alt-Svc cache entries based on their own network state changes can 314 seem mistaken today. The situation can potentially get worse with 315 protocol evolution (connection migration, multipath, etc). 317 This feature was designed to address the "mistaken mapping" scenario, 318 where either DNS mapping or anycast landed you at one POP but the 319 server knows another one is closer to you: You're in Seattle, your 320 VPN endpoint and DNS server is in Sacramento, and so DNS resolution 321 gives you a CDN node in California. The California endpoint gives 322 you the unicast IP of the Seattle endpoint as a friendly shove. 324 Similarly, it's one of the best work-around options for off-net DNS 325 (via DoH, ODoH, etc.) if there is a CDN endpoint very close to the 326 user's network, but doesn't work so well if the Alt-Svc record keeps 327 being used after a network change. 329 When you're no longer in the same network environment, we can trust 330 mapping again. What is the signal this redirect is no longer useful 331 if clients can't reliably detect network changes? 333 2.11. Radical Simplification 335 If we are able to reach wide deployment and use of the HTTPS record, 336 it may supersede many use cases for Alt-Svc. We should reassess the 337 needs from the new baseline to see whether Alt-Svc can be radically 338 simplified. (Chrome never fully implemented Alt-Svc redirection 339 anyway.) 341 3. Security Considerations 343 TODO Security 345 4. IANA Considerations 347 This document has no IANA actions. 349 5. Informative References 351 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 352 "Transport Layer Security (TLS) Application-Layer Protocol 353 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 354 July 2014, . 356 [AltSvc] Nottingham, M., McManus, P., and J. Reschke, "HTTP 357 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 358 April 2016, . 360 [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. A. Wood, "TLS 361 Encrypted Client Hello", Work in Progress, Internet-Draft, 362 draft-ietf-tls-esni-10, 8 March 2021, 363 . 365 [I-D.bishop-httpbis-altsvc-quic] 366 Bishop, M., "ALTSVC Frame in HTTP/QUIC", Work in Progress, 367 Internet-Draft, draft-bishop-httpbis-altsvc-quic-01, 15 368 May 2020, . 371 [I-D.pardue-httpbis-dont-be-clear] 372 Pardue, L. and A. Ramine, "Reserving the clear ALPN 373 Protocol ID", Work in Progress, Internet-Draft, draft- 374 pardue-httpbis-dont-be-clear-00, 15 March 2021, 375 . 378 [I-D.reschke-http-oob-encoding] 379 Reschke, J. F. and S. Loreto, "'Out-Of-Band' Content 380 Coding for HTTP", Work in Progress, Internet-Draft, draft- 381 reschke-http-oob-encoding-12, 24 June 2017, 382 . 385 [I-D.thomson-tls-snip] 386 Thomson, M., "Secure Negotiation of Incompatible Protocols 387 in TLS", Work in Progress, Internet-Draft, draft-thomson- 388 tls-snip-01, 3 January 2021, 389 . 391 [SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service binding 392 and parameter specification via the DNS (DNS SVCB and 393 HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf- 394 dnsop-svcb-https-05, 21 April 2021, 395 . 398 Acknowledgments 400 Martin Thomson, Lucas Pardue, and Mike Bishop reviewed and commented 401 on an early version of this draft (https://docs.google.com/document/ 402 d/1QNaXduqohACK93qLPpxkPJ2rHQMgWqUPL-DkZS11htQ/edit?ts=60a5dc92#). 404 Author's Address 406 Erik Nygren 407 Akamai 409 Email: erik+ietf@nygren.org