idnits 2.17.1 draft-nottingham-httpbis-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2014) is 3699 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 (-05) exists of draft-ietf-tls-applayerprotoneg-04 == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-09 == Outdated reference: A later version (-03) exists of draft-nottingham-http2-encryption-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Akamai 4 Intended status: Standards Track P. McManus 5 Expires: August 15, 2014 Mozilla 6 February 11, 2014 8 HTTP Alternate Services 9 draft-nottingham-httpbis-alt-svc-02 11 Abstract 13 This document proposes a number of changes to HTTP, centered around 14 "alternate services", which allow an origin's resources to be 15 available at a separate network location, possibly accessed with a 16 different protocol configuration. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 15, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 54 2. Use Cases for Alternate Services . . . . . . . . . . . . . . . 3 55 2.1. Upgrading HTTP/1 . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Using TLS with http:// URIs . . . . . . . . . . . . . . . 4 57 2.3. Mitigating Load Asymmetry . . . . . . . . . . . . . . . . 4 58 2.4. Segmenting Clients that Support TLS SNI . . . . . . . . . 5 59 3. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Proposal: Alternate Services . . . . . . . . . . . . . . . 5 61 3.1.1. Host Authentication . . . . . . . . . . . . . . . . . 7 62 3.1.2. Alternate Service Caching . . . . . . . . . . . . . . 7 63 3.1.3. Requiring Server Name Indication . . . . . . . . . . . 8 64 3.1.4. Using Alternate Services . . . . . . . . . . . . . . . 8 65 3.2. Proposal: The Alt-Svc HTTP Header Field . . . . . . . . . 8 66 3.2.1. Caching Alt-Svc Header Field Values . . . . . . . . . 9 67 3.3. Proposal: ALTSVC Frame . . . . . . . . . . . . . . . . . . 10 68 4. Proposal: SETTINGS_UNIVERSAL_SCHEMES (5) . . . . . . . . . . . 11 69 5. Proposal: NOT_AUTHORITATIVE (13) . . . . . . . . . . . . . . . 11 70 6. Proposal: Discovery of TLS Support for http:// URIs . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 72 7.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 13 73 7.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 13 74 7.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 14 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 79 Appendix B. TODO . . . . . . . . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 [I-D.ietf-httpbis-http2] specifies a few ways to negotiate the use of 85 HTTP/2 without changing existing URIs. However, several deficiencies 86 in using the "upgrade dance" for "http://" URIs have become apparent. 87 While that mechanism is still being investigated, some have expressed 88 interest in an alternate approach. 90 Furthermore, some implementers have expressed a strong desire utilize 91 HTTP/2 only in conjunction with TLS. Alternate-Services provides a 92 potential mechanism for achieving that for "http://" URIs; see 93 [I-D.nottingham-http2-encryption] for details. 95 Finally, HTTP/2 is designed to have longer-lived, fewer and more 96 active TCP connections. While these properties are generally 97 "friendlier" for the network, they can cause problems for servers 98 that currently exploit the short-lived flow characteristics of 99 HTTP/1.x for load balancing, session affinity and maintaining 100 locality to the user. 102 This document explores these use cases in Section 2, and makes 103 proposals to address them in Section 3. 105 1.1. Notational Conventions 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 This document uses the Augmented BNF defined in [RFC5234] along with 112 the "OWS", "DIGIT", "parameter", "uri-host", "port" and "delta- 113 second" rules from [I-D.ietf-httpbis-p1-messaging], and uses the 114 "#rule" extension defined in Section 7 of that document. 116 2. Use Cases for Alternate Services 118 This section details the use cases for Alternate Services, 119 identifying the proposals that would need to be adopted to meet each 120 one. 122 2.1. Upgrading HTTP/1 124 The first use case for Alternate Services is upgrading a client from 125 HTTP/1 to HTTP/2 for http:// URIs (i.e., without the use of SSL or 126 TLS). 128 While HTTP/2 defines how to use the Upgrade header "dance" to do 129 this, it might not always be suitable, since it involves blocking the 130 connection until the upgrade succeeds. Since HTTP/2 is focused on 131 improving performance, this is not desirable. 133 Furthermore, using Upgrade requires the server that supports HTTP/2 134 to be on the same ip:port tuple as the server supporting HTTP/1; this 135 can cause deployment issues, as well as operational issues with 136 devices that assume that all traffic on port 80 will be HTTP/1. 138 Therefore, a means of indicating that a different, new connection can 139 be used for HTTP/2 is desirable; this would allow the client to 140 continue using the HTTP/1 connection until the new connection is 141 established. It also simplifies deployment considerations by not 142 requiring HTTP/1 and HTTP/2 to be "spoken" on the same port, and 143 allows issues on port 80 to be avoided. 145 This use case can be met if Section 3.1 and Section 3.2 are accepted. 146 It can also be met if Section 3.1 is used with a different discovery 147 mechanism (e.g., DNS-based). 149 2.2. Using TLS with http:// URIs 151 As discussed in [I-D.nottingham-http2-encryption], it might be 152 desirable to "opportunistically" use TLS when accessing a HTTP URI. 154 This case can also be met by Section 3.1 and Section 6 with 155 Section 3.2 for HTTP/1, and Section 3.1 and Section 6 with 156 Section 3.2 or Section 3.3 for HTTP/2, with the possible addition of 157 Section 4. Section 5 might also be useful for handling errors in 158 this use case. 160 2.3. Mitigating Load Asymmetry 162 HTTP/2 fundamentally changes how HTTP uses TCP. While this has many 163 benefits, it also disrupts many server-side practices that take 164 advantage of HTTP/1's shorter flows. 166 In particular, load balancing among a pool of servers is often used, 167 either with DNS ("global" load balancing), or a device (hardware or 168 software) that dispatches requests locally. 170 HTTP/1's short flows aid in this, because it is easy to shift traffic 171 among servers when one becomes overloaded or unavailable. However, 172 in HTTP/2, this is more difficult, due to the protocol's longer 173 flows. 175 As a result, a mechanism for re-directing requests for an origin or 176 set of origins without making this apparent to the application is 177 desirable. 179 This use case can be met if Section 3.1 and Section 3.3 are accepted; 180 servers can redirect clients to alternate services as appropriate. 181 Section 5 might also be useful for handling errors in this use case. 183 2.4. Segmenting Clients that Support TLS SNI 185 TLS Server Name Indication (SNI) [RFC6066] was introduced to avoid a 186 requirement for a 1:1 mapping between origin hostnames and IP 187 addresses (in light of IPv4 address exhaustion), in a manner similar 188 to the Host header in HTTP/1. 190 However, there are still clients in common use that do not send SNI. 191 As a result, servers have no way to take practical advantage of the 192 extension, because there is no way to segment those clients that 193 support SNI from those that do not. 195 As a result, they need to build their infrastructure as if SNI did 196 not exist. 198 This use case can be met if Section 3.1 and Section 3.3 are accepted; 199 servers can advertise an alternate service and direct clients that 200 support SNI and HTTP/2 to the optimal server, while still maintaining 201 a smaller set of legacy servers for those clients that do not support 202 SNI (since HTTP/2 requires SNI support when TLS is in use). 204 3. Proposals 206 This section enumerates proposals made to meet the use cases in 207 Section 2. Note that they all need not be accepted together, 208 depending on the use cases that are determined as in-scope. 210 3.1. Proposal: Alternate Services 212 NOTE: This section can be incorporated into HTTP/2 directly, or it 213 can be published as a standalone specification. However, if 214 Section 3.3 is accepted, it will need to be included or referenced 215 from the spec, since frame type extensibility has been ruled out. 217 This specification defines a new concept in HTTP, the "alternate 218 service." When an origin (see [RFC6454] has resources are accessible 219 through a different protocol / host / port combination, it is said to 220 have an alternate service. 222 An alternate service can be used to interact with the resources on an 223 origin server at a separate location on the network, possibly using a 224 different protocol configuration. 226 For example, an origin: 228 ("http", "www.example.com", "80") 230 might declare that its resources are also accessible at the alternate 231 service: 233 ("h2", "new.example.com", "81") 235 By their nature, alternate services are explicitly at the granularity 236 of an origin; i.e., they cannot be selectively applied to resources 237 within an origin. 239 Alternate services do not replace or change the origin for any given 240 resource; in general, they are not visible to the software "above" 241 the access mechanism. The alternate service is essentially alternate 242 routing information that can also be used to reach the origin in the 243 same way that DNS CNAME or SRV records define routing information at 244 the name resolution level. Each origin maps to a set of these routes 245 - the default route is derived from origin itself and the other 246 routes are introduced based on alternate-protocol information. 248 Furthermore, it is important to note that the first member of an 249 alternate service tuple is different from the "scheme" component of 250 an origin; it is more specific, identifying not only the major 251 version of the protocol being used, but potentially communication 252 options for that protocol. 254 This means that clients using an alternate service will change the 255 host, port and protocol that they are using to fetch resources, but 256 these changes MUST NOT be propagated to the application that is using 257 HTTP; from that standpoint, the URI being accessed and all 258 information derived from it (scheme, host, port) are the same as 259 before. 261 Importantly, this includes its security context; in particular, when 262 TLS [RFC5246] is in use, the alternate server will need to present a 263 certificate for the origin's host name, not that of the alternate. 264 Likewise, the Host header is still derived from the origin, not the 265 alternate service (just as it would if a CNAME were being used). 267 The changes MAY, however, be made visible in debugging tools, 268 consoles, etc. 270 Formally, an alternate service is identified by the combination of: 272 o An ALPN protocol, as per [I-D.ietf-tls-applayerprotoneg] 273 o A host, as per [RFC3986] 274 o A port, as per [RFC3986] 276 Additionally, each alternate service MUST have: 278 o A freshness lifetime, expressed in seconds; see Section 3.1.2 280 There are many ways that a client could discover the alternate 281 service(s) associated with an origin. 283 3.1.1. Host Authentication 285 Clients MUST NOT use alternate services with a host other than the 286 origin's without strong server authentication; this mitigates the 287 attack described in Section 7.2. One way to achieve this is for the 288 alternate to use TLS with a certificate that is valid for that 289 origin. 291 For example, if the origin's host is "www.example.com" and an 292 alternate is offered on "other.example.com" with the "h2t" protocol, 293 and the certificate offered is valid for "www.example.com", the 294 client can use the alternate. However, if "other.example.com" is 295 offered with the "h2" protocol, the client cannot use it, because 296 there is no mechanism in that protocol to establish strong server 297 authentication. 299 Furthermore, this means that the HTTP Host header and the SNI 300 information provided in TLS by the client will be that of the origin, 301 not the alternate. 303 3.1.2. Alternate Service Caching 305 Mechanisms for discovering alternate services can associate a 306 freshness lifetime with them; for example, the Alt-Svc header field 307 uses the "ma" parameter. 309 Clients MAY choose to use an alternate service instead of the origin 310 at any time when it is considered fresh; see Section 3.1.4 for 311 specific recommendations. 313 Clients with existing connections to alternate services are not 314 required to fall back to the origin when its freshness lifetime ends; 315 i.e., the caching mechanism is intended for limiting how long an 316 alternate service can be used for establishing new requests, not 317 limiting the use of existing ones. 319 To mitigate risks associated with caching compromised values (see 320 Section 7.2 for details), user agents SHOULD examine cached alternate 321 services when they detect a change in network configuration, and 322 remove any that could be compromised (for example, those whose 323 association with the trust root is questionable). UAs that do not 324 have a means of detecting network changes SHOULD place an upper bound 325 on their lifetime. 327 3.1.3. Requiring Server Name Indication 329 A client must only use a TLS-based alternate service if the client 330 also supports TLS Server Name Indication (SNI) [RFC6066]. This 331 supports the conservation of IP addresses on the alternate service 332 host. 334 3.1.4. Using Alternate Services 336 By their nature, alternate services are optional; clients are not 337 required to use them. However, it is advantageous for clients to 338 behave in a predictable way when they are used by servers (e.g., for 339 load balancing). 341 Therefore, if a client becomes aware of an alternate service, the 342 client SHOULD use that alternate service for all requests to the 343 associated origin as soon as it is available, provided that the 344 security properties of the alternate service protocol are desirable, 345 as compared to the existing connection. 347 The client is not required to block requests; the origin's connection 348 can be used until the alternate connection is established. However, 349 if the security properties of the existing connection are weak (e.g. 350 cleartext HTTP/1.1) then it might make sense to block until the new 351 connection is fully available in order to avoid information leakage. 353 Furthermore, if the connection to the alternate service fails or is 354 unresponsive, the client MAY fall back to using the origin. Note, 355 however, that this could be the basis of a downgrade attack, thus 356 losing any enhanced security properties of the alternate service. 358 3.2. Proposal: The Alt-Svc HTTP Header Field 360 NOTE: Because this header is mostly defined for use in HTTP/1, it is 361 most likely most appropriate to put it in a separate specification. 362 However, it will need to reference Section 3.1, wherever that is 363 specified. 365 A HTTP(S) origin server can advertise the availability of alternate 366 services (see Section 3.1) to clients by adding an Alt-Svc header 367 field to responses. 369 Alt-Svc = 1#( alternate *( OWS ";" OWS parameter ) ) 370 alternate = <"> protocol-id <"> "=" port 371 protocol-id = 373 For example: 375 Alt-Svc: http2=8000 377 This indicates that the "http2" protocol on the same host using the 378 indicated port (in this case, 8000). 380 Alt-Svc does not allow advertisement of alternate services on other 381 hosts, to protect against various header-based attacks. 383 It can, however, have multiple values: 385 Alt-Svc: "h2"=8000, "h2t"=443 387 The value(s) advertised by Alt-Svc can be used by clients to open a 388 new connection to one or more alternate services immediately, or 389 simultaneously with subsequent requests on the same connection. 391 Intermediaries MUST NOT change or append Alt-Svc values. 393 Finally, note that while it may be technically possible to put 394 content other than printable ASCII in a HTTP header, some 395 implementations only support ASCII (or a superset of it) in header 396 field values. Therefore, this field SHOULD NOT be used to convey 397 protocol identifiers that are not printable ASCII, or those that 398 contain quote characters. 400 3.2.1. Caching Alt-Svc Header Field Values 402 When an alternate service is advertised using Alt-Svc, it is 403 considered fresh for 24 hours from generation of the message. This 404 can be modified with the 'ma' (max-age) parameter; 406 Alt-Svc: "h2t"=443;ma=3600 408 which indicates the number of seconds since the response was 409 generated the alternate service is considered fresh for. 411 ma = delta-seconds 413 See [I-D.ietf-httpbis-p6-cache] Section 4.2.3 for details of 414 determining response age. For example, a response: 416 HTTP/1.1 200 OK 417 Content-Type: text/html 418 Cache-Control: 600 419 Age: 30 420 Alt-Svc: "h2"=8000; ma=60 422 indicates that an alternate service is available and usable for the 423 next 60 seconds. However, the response has already been cached for 424 30 seconds (as per the Age header field value), so therefore the 425 alternate service is only fresh for the 30 seconds from when this 426 response was received, minus estimated transit time. 428 When an Alt-Svc response header is received from an origin, its value 429 invalidates and replaces all cached alternate services for that 430 origin. 432 See Section 3.1.2 for general requirements on caching alternate 433 services. 435 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 436 does not affect caching of Alt-Svc values. 438 3.3. Proposal: ALTSVC Frame 440 NOTE: Because of the current approach to HTTP/2 extensibility, this 441 section will need to be incorporated to the frame type listing in 442 HTTP/2 if accepted. 444 The ALTSVC frame (type=0xa) advertises the availability of an 445 alternate service to the client. It can be sent at any time for an 446 existing client-initiated stream or stream 0, and is intended to 447 allow servers to load balance or otherwise segment traffic; see 448 Section 3.1 for details. 450 An ALTSVC frame on a client-initiated stream indicates that the 451 conveyed alternate service is associated with the origin of that 452 stream. 454 An ALTSVC frame on stream 0 indicates that the conveyed alternate 455 service is associated with all origins that map to the server's 456 address (i.e., host and port). 458 The ALTSVC frame is intended for receipt by clients; a server that 459 receives an ALTSVC frame MUST treat it as a connection error of type 460 PROTOCOL_ERROR. 462 0 1 2 3 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | PID_LEN (8) | Reserved (8) | Port (16) | 466 +---------------------------------------------------------------+ 467 | Max-Age (32) | 468 +---------------------------------------------------------------+ 469 | Protocol-ID (*) | 470 +---------------------------------------------------------------+ 471 | Host (*) | 472 +---------------------------------------------------------------+ 474 The ALTSVC frame contains the following fields: 476 o PID_LEN: An unsigned, 8-bit integer indicating the length, in 477 bytes, of the PROTOCOL-ID field. 478 o Reserved: for future use. 479 o Port: An unsigned, 16-bit integer indicating the port that the 480 alternate service is available upon. 481 o Max-Age: An unsigned, 32-bit integer indicating the freshness 482 lifetime of the alternate service association, as per 483 Section 3.1.2. 484 o Protocol-ID: A sequence of bytes (length determined by PID_LEN) 485 containing the ALPN protocol identifier of the alternate service. 486 o Host: A sequence of bytes containing an ascii string indicating 487 the host that the alternate service is available upon. 489 The ALTSVC frame does not define any flags. 491 4. Proposal: SETTINGS_UNIVERSAL_SCHEMES (5) 493 NOTE: This is a proposal for a new SETTINGS value, to be incorporated 494 in that list if accepted. 496 A non-zero value indicates the sender MAY accept requests with 497 schemes that do not match the default port for the server. A non- 498 zero value is a pre-requisite for sending http:// over TLS via the 499 previous https connection method described in Section 6. 501 5. Proposal: NOT_AUTHORITATIVE (13) 503 NOTE: This is a proposal for a new error code, which should be 504 incorporated into the appropriate section if accepted. 506 The endpoint refuses the stream prior to performing any application 507 processing. This server is not configured to provide a definitive 508 response for the requested resource. Clients receiving this error 509 code SHOULD remove the endpoint from their cache of alternate 510 services, if present. 512 6. Proposal: Discovery of TLS Support for http:// URIs 514 NOTE: This section, if accepted, ought to be added as a new 515 subsection of "Starting HTTP/2". 517 A server wishing to advertise support for HTTP/2 over TLS for http:// 518 URIs MAY do so by including an Alt-Svc (Section 3.2 response header 519 with the "h2t" protocol identifier. 521 For example, a HTTP/1 connection could indicate support for HTTP/2 on 522 port 443 for use with future http:// URI requests with this Alt-Svc 523 header: 525 HTTP/1.1 200 OK 526 Alt-Svc: "h2t"=443 528 The process for starting HTTP/2 over TLS for an http:// URI is the 529 same as the connection process for an https:// URI, except that 530 authentication of the TLS channel is not required. The client MAY 531 use either anonymous or authenticated ciphersuites. If an 532 authenticated ciphersuite is used, the client MAY ignore 533 authentication failures. This enables servers that only serve 534 http:// URIs to use credentials that are not tied to a global PKI, 535 such as self-signed certificates. Clients MAY reserve the use of 536 certain security sensitive optimizations, such as caching the 537 existence of this successful connection, for authenticated 538 connections. 540 Additionally, if a client has previously successfully connected to a 541 given server over TLS, for example as part of an https:// request, 542 then it MAY attempt to use TLS for requests certain http:// URIs. To 543 use this mechanism the server MUST have sent a non-zero 544 SETTINGS_UNIVERSAL_SCHEMES setting to indicate support for this 545 mechanism. 547 Eligible http:// URIs: 549 1. Contain the same host name as the URI accessed over TLS, and 550 2. Do not contain an explicit port number. 552 For example, if the client has successfully made a request for the 553 URI "https://example.com/foo", then it may attempt to use TLS to make 554 a request for the URI "http://example.com/bar", but not for the URI 555 "http://example.com:80/". In particular, if a client has a TLS 556 connection open to a server (for example, due to a past "https" 557 request), then it may re-use that connection for "http" requests, 558 subject to the constraints above. 560 7. Security Considerations 562 Identified security considerations should be enumerated in the 563 appropriate documents depending on which proposals are accepted. 564 Those listed below are generic to all uses of alternate services; 565 more specific ones might be necessary. 567 7.1. Changing Ports 569 Using an alternate service implies accessing an origin's resources on 570 an alternate port, at a minimum. An attacker that can inject 571 alternate services and listen at the advertised port is therefore 572 able to hijack an origin. 574 For example, an attacker that can add HTTP response header fields can 575 redirect traffic to a different port on the same host using the Alt- 576 Svc header field; if that port is under the attacker's control, they 577 can thus masquerade as the HTTP server. 579 This risk can be mitigated by restricting the ability to advertise 580 alternate services, and restricting who can open a port for listening 581 on that host. 583 7.2. Changing Hosts 585 When the host is changed due to the use of an alternate service, it 586 presents an opportunity for attackers to hijack communication to an 587 origin. 589 For example, if an attacker can convince a user agent to send all 590 traffic for "innocent.example.org" to "evil.example.com" by 591 successfully associating it as an alternate service, they can 592 masquerade as that origin. This can be done locally (see mitigations 593 above) or remotely (e.g., by an intermediary as a man-in-the-middle 594 attack). 596 This is the reason for the requirement in Section 3.1.1 that any 597 alternate service with a host different to the origin's be strongly 598 authenticated with the origin's identity; i.e., presenting a 599 certificate for the origin proves that the alternate service is 600 authorized to serve traffic for the origin. 602 However, this authorization is only as strong as the method used to 603 authenticate the alternate service. In particular, there are well- 604 known exploits to make an attacker's certificate appear as 605 legitimate. 607 Alternate services could be used to persist such an attack; for 608 example, an intermediary could man-in-the-middle TLS-protected 609 communication to a target, and then direct all traffic to an 610 alternate service with a large freshness lifetime, so that the user 611 agent still directs traffic to the attacker even when not using the 612 intermediary. 614 As a result, there is a requirement in Section 3.1.2 to examine 615 cached alternate services when a network change is detected. 617 7.3. Changing Protocols 619 When the ALPN protocol is changed due to the use of an alternate 620 service, the security properties of the new connection to the origin 621 can be different from that of the "normal" connection to the origin, 622 because the protocol identifier itself implies this. 624 For example, if a "https://" URI had a protocol advertised that does 625 not use some form of end-to-end encryption (most likely, TLS), it 626 violates the expectations for security that the URI scheme implies. 628 Therefore, clients cannot blindly use alternate services, but instead 629 evaluate the option(s) presented to assure that security requirements 630 and expectations (of specifications, implementations and end users) 631 are met. 633 8. References 635 8.1. Normative References 637 [I-D.ietf-httpbis-p1-messaging] 638 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 639 (HTTP/1.1): Message Syntax and Routing", 640 draft-ietf-httpbis-p1-messaging-26 (work in progress), 641 February 2014. 643 [I-D.ietf-httpbis-p6-cache] 644 Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 645 Transfer Protocol (HTTP/1.1): Caching", 646 draft-ietf-httpbis-p6-cache-26 (work in progress), 647 February 2014. 649 [I-D.ietf-tls-applayerprotoneg] 650 Friedl, S., Popov, A., Langley, A., and S. Emile, 651 "Transport Layer Security (TLS) Application Layer Protocol 652 Negotiation Extension", draft-ietf-tls-applayerprotoneg-04 653 (work in progress), January 2014. 655 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 656 Requirement Levels", BCP 14, RFC 2119, March 1997. 658 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 659 Resource Identifier (URI): Generic Syntax", STD 66, 660 RFC 3986, January 2005. 662 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 663 Specifications: ABNF", STD 68, RFC 5234, January 2008. 665 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 666 Extension Definitions", RFC 6066, January 2011. 668 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 669 December 2011. 671 8.2. Informative References 673 [I-D.ietf-httpbis-http2] 674 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 675 "Hypertext Transfer Protocol version 2.0", 676 draft-ietf-httpbis-http2-09 (work in progress), 677 December 2013. 679 [I-D.nottingham-http2-encryption] 680 Nottingham, M., "Opportunistic Encryption for HTTP URIs", 681 draft-nottingham-http2-encryption-02 (work in progress), 682 December 2013. 684 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 685 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 687 Appendix A. Acknowledgements 689 Thanks to Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, 690 Erik Nygren, Paul Hoffman, Adam Langley, Will Chan and Richard Barnes 691 for their feedback and suggestions. 693 The Alt-Svc header field was influenced by the design of the 694 Alternate-Protocol header in SPDY. 696 Appendix B. TODO 698 o DNS: Alternate services are also amenable to DNS-based discovery. 699 If there is sufficient interest, a future revision may include a 700 proposal for that. 701 o Indicating Chosen Service: It's likely necessary for the server to 702 know which protocol the user agent has chosen, and perhaps even 703 the hostname (for load balancing). This could be conveyed as part 704 of the "magic", or as a request header. 705 o Advice for setting headers: guidelines for servers that use the 706 Alt-Svc header field. 707 o For the load balancing use case, it's necessary for clients to 708 always flush altsvc cache upon a network change, but right now 709 they're only required to examine the cache for suspicious entries. 710 We should discuss whether this should be upgraded to always flush. 712 Authors' Addresses 714 Mark Nottingham 715 Akamai 717 Email: mnot@mnot.net 718 URI: http://www.mnot.net/ 720 Patrick McManus 721 Mozilla 723 Email: mcmanus@ducksong.com 724 URI: https://mozillians.org/u/pmcmanus/