HTTPBis Working Group S. Loreto Internet-Draft J. Mattsson Intended status: Standards Track R. Skog Expires: August 18, 2014 H. Spaak Ericsson G. Gus D. Druta M. Hafeez AT&T February 14, 2014 Explicit Trusted Proxy in HTTP/2.0 draft-loreto-httpbis-trusted-proxy20-01 Abstract The purpose of this Internet Draft is to continue the discussion on explicit and trusted proxy as intermediary of HTTP2 traffic. The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or without TLS, without any constraints from the standard (see: issue 314). To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport "http" URIs resources: h2clr. This document describes two alternative methods for an user-agent to automatically discover and for an user to provide consent for a Trusted Proxy to be securely involved when he or she is requesting an HTTP URI resource over HTTP2 with TLS. The consent is supposed to be per network access. The draft also describes the role of the Trusted Proxy in helping the user to fetch HTTP URIs resource when the user has provided consent to the Trusted Proxy to be involved. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Loreto, et al. Expires August 18, 2014 [Page 1] Internet-Draft Trusted Proxy 2.0 February 2014 Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Loreto, et al. Expires August 18, 2014 [Page 2] Internet-Draft Trusted Proxy 2.0 February 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Explicit and Trusted Proxy . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. How a Forward Proxy establishes the trust . . . . . . . . . . 6 3.1. Proxy certificate . . . . . . . . . . . . . . . . . . . . 6 3.1.1. TLS Handshake with Proxy certificate . . . . . . . . . 7 3.1.2. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Captive Proxy . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 11 4. Explicit Proxy behaviour . . . . . . . . . . . . . . . . . . . 12 4.1. Secure Forward Proxy towards HTTP2 origin server . . . . . 13 4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server . . . 14 4.3. Secure Forward Proxy and https URIs . . . . . . . . . . . 15 5. Signalling the presence of a Proxy in between . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Loreto, et al. Expires August 18, 2014 [Page 3] Internet-Draft Trusted Proxy 2.0 February 2014 1. Introduction The current (i.e. HTTP/1.1) and previous HTTP protocol versions have provided room and made it possible to create a Web ecosystem of various kind of proxies and intermediaries: cache servers, security gateways, web accelerators, content filters, and many others. In some cases their presence is explicit (i.e. configured proxies), and in other they are completely transparent to the end user (i.e. transparent proxy, reverse proxy). The success and the presence of those intermediaries is also a problem for the evolution of the HTTP protocol as the intermediary behaviour on protocol extension and especially on alternative wire format of the protocol is not predictable. This not predictable behaviour can lead to difficulties to deploy a new version of the protocol before the intermediate are themselves update to support it (see the difficult in deploying the WebSocket Protocol [RFC6455] in clear). Relying on establishing an HTTPS tunnel has then become the popular way to bypass the intermediate proxies as it provides reliable deployment model for web protocols: the encrypted tunnel obfuscates the data from all intermediaries. HTTPS tunnels, while speeding up the deployment, makes it difficult for a forward proxy and other intermediaries to be used to allow caching, to provide anonymity to a User-Agent, or to provide security by using an application-layer firewall to inspect the HTTP traffic on behalf of the User-Agent (e.g. to protect it against cross-site scripting attacks). HTTPS tunnels also remove the possibility to enhance delivery performance based on the knowledge of the network status, and this become an important limitation especially with HTTP2 when multiple streams are multiplexed on top of the same TCP connection. In the presence of HTTPS tunnels the only possibility to have a trusted intermediary (and still providing confidentiality towards not trusted elements in the network) is then to have separate TLS sessions between the User-Agent and the proxy, on one side, and the proxy and the server on the other side (see Figure 1). UserAgent Proxy Server TLS Session #1 TLS Session #2 <------------> <-------------> HTTP <-----------------------------------> Figure 1: A proxied HTTPS session, with two independent TLS sessions Several drafts analysing the role and the requirements for proxy have Loreto, et al. Expires August 18, 2014 [Page 4] Internet-Draft Trusted Proxy 2.0 February 2014 been submitted: 1. [I-D.nottingham-http-proxy-problem] discusses the use and configuration of proxies in HTTP, pointing out problems in the currently deployed Web infrastructure along the way 2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with HTTP proxies for TLS protected traffic and motivates the need for explicit proxying capability in HTTP. It also presents the goals that such a solution would need to satisfy and some example solution directions. 3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to a proxy via a secure channel, allowing, disallowing, and detecting any transforms that the proxy may perform, and allowing the proxy to connect via secure channel to another site on the user's behalf.. Use cases in form of stories for proxies are also listed in the wiki Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy Use Case Analysis and Alternatives [2]. 1.1. Explicit and Trusted Proxy The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or without TLS, without any constraints from the standard (see issue 314 [3]), however the role of explicit and trusted proxy as intermediary in HTTP2 is still to be specified in the standard. The main aim for this document is to analyse and define the role of an Explicit and Trusted proxy for HTTP URI resources transported over HTTP2 with TLS. To distinguish between an HTTP2 connection meant to transport "https" URIs resources and an HTTP2 connection meant to transport "http" URIs resource, the draft proposes to register a new value in the Application Layer Protocol negotiation (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 to transport "http" URIs resources: h2clr. This document describes two alternative methods for an user-agent to automatically discover and then for an user to provide consent for a Trusted Proxy to be securely involved when an HTTP URI resource is requested. Section 3.1 proposes a solution based on sending a proxy certificate in the TLS handshake. Loreto, et al. Expires August 18, 2014 [Page 5] Internet-Draft Trusted Proxy 2.0 February 2014 Section 3.2 proposes a solution based on the presence of a Captive Proxy. The consent is supposed to be per network access. Section 4 describes the role of the Trusted Proxy in helping the user to fetch HTTP URIs resource when the user has provided consent to the Trusted Proxy to be involved. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This document defines the following terms: Explicit proxy: an intermediary that explicit signals its presence to the User-Agent and eventually also to the Origin Server. Trusted proxy: an intermediary that in order to authenticate itself provides a proxy certificate issued by a trusted certification authority, where the root certificate is assumed to be preinstalled in the User-Agent. 3. How a Forward Proxy establishes the trust An explicit and trusted proxy is preferable to a transparent MITM proxy as an intermediary of HTTP2 traffic. However how a proxy is interposed into a network flow often has great affect on perceptions of its operation by end users and origin servers. The following sections describe two mechanisms by which a proxy can establish trust. 3.1. Proxy certificate To help HTTP User-Agents identify and distinguish proxies from other servers (e.g. web servers), a certification authority can issue special public key certificates to trusted proxies. More specifically, the certification authority can use the Extended Key Usage extension as specified in [RFC5280] to indicate a key purpose "proxyAuthentication" (a new object identifier needs to be assigned by IANA for this key purpose). The certification authority also marks this Extended Key Usage extension as critical. As the user needs to have high trust in the Proxy, the validation procedure for Loreto, et al. Expires August 18, 2014 [Page 6] Internet-Draft Trusted Proxy 2.0 February 2014 proxy certificates should be more rigorous than for ordinary SSL certificates. All proxy certificates should therefore be Extended Validation (EV) SSL Certificates. 3.1.1. TLS Handshake with Proxy certificate When a (TLS and HTTP) User-Agent receives a Server Certificate message, it checks whether the certificate contains an Extended Key Usage extension and if so whether the "proxyAuthentication" key purpose id is included. If it is included, the User-Agent concludes that the certificate belongs to a proxy. It then verifies that the proxy certificate is a valid EV certificate. The user-agent then SHOULD secure user consent. When the user has given consent to the use of a proxy, the User-Agent SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy. The consent SHOULD be limited to the specific access and MAY be limited to a single connection to that access or limited in time. How the consent information is stored is implementation specific, but as a network may have several proxies (for network resilience) it is RECOMMENDED that the consent is only tied to the Subject field of the proxy certificate so that the consent applies to all proxy certificates with the same name. If the user has previously given consent to use the specific proxy and the user-agent has stored that, the user-agent may conclude that the user has given consent without asking the user again. If the user provides consent, the User-Agent continues the TLS handshake with the proxy. Loreto, et al. Expires August 18, 2014 [Page 7] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +------------+ +-------------+ | user-agent | | Proxy | | Server | +--------------+ +------------+ +-------------+ | | | | | | | (1) ClientHello | | |--------------------------->| | | (ALPN ProtocolName: h2clr) | | | | | | | | | | | |(2) ServerHello, ServerCert | | |<---------------------------| | | (Proxy-specific cert) | | | | | | | | (3) User consent | | | | | | (4) Rest of TLS handshake | | |<-------------------------->| | | | | | (5) HTTP2 over TLS |(5) HTTP2 (may be over TLS) | |<-------------------------->|<---------------------------->| | | | | | | Figure 2: TLS Handshake with Proxy certificate 3.1.2. Opt Out If the user does not give consent, or decides to opt out from the proxy for a specific connection, the user-agent will negotiate HTTP2 connection using "h2" value in the Application Layer Protocol Negotiation (ALPN) extension field. The proxy will then notice that the TLS connection is to be used for a https resource or for a http resource for which the user wants to opt out from the proxy. The proxy will then forward the ClientHello message to the Server and the TLS connection will be end-to-end between the user-agent and the Server. Loreto, et al. Expires August 18, 2014 [Page 8] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +------------+ +-------------+ | user-agent | | Proxy | | Server | +--------------+ +------------+ +-------------+ | | | (1) TLS ClientHello | |---------------------------------------------------------->| | (ALPN ProtocolName: h2) | | | | (2) ServerHello, ServerCert | |<----------------------------------------------------------| | (3) Rest of TLS handshake | |<--------------------------------------------------------->| | | | (4) HTTP 2 over TLS | |<--------------------------------------------------------->| | | Figure 3: Opt Out 3.2. Captive Proxy The Captive Proxy mechanism suggests that a Secure Proxy may indicate its presence and identity by intercepting a TLS ClientHello message, analysing the application layer protocol negotiation extension field and if it contains "h2clr" value forcing the User-Agent to redirect to a secure page on a Portal where the user is request to consent to the presence of the Secure Proxy for all the request towards "http" URI resources while it stays in that network (see Figure 4). Loreto, et al. Expires August 18, 2014 [Page 9] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +------------+ +--------+ +-------------+ | user-agent | | Proxy | | Portal | | Server | +--------------+ +------------+ +--------+ +-------------+ | | | | | | | | | (1) TLS ClientHello \|/ | | |----------------------------| | | | (ALPN ProtocolName: h2clr)/|\ | | | | | | | (2) GET HTTP/1.1 | | | |--------------------------->| | | | (3) 302 | | | |<---------------------------| | | | (4) GET HTTPS/1.1 | | | |------------------------------------------>| | | (5) 200 | | | |<------------------------------------------| | | (6) download certificate+file.pac | | |<------------------------------------------| | | (7) GET /1.1 | | | |--------------------------->|------------------------------>| | (8) 200 Alternate | | | |<---------------------------|<------------------------------| Figure 4: Captive Proxy flow Figure 4 steps are explained below (1) A User-Agent that makes a request to an "http" URI without prior knowledge about support for HTTP2 uses TLS, with the application level protocol negotiation extension inserting the h2clr tag, to start the HTTP2 connection. The Proxy intercepts the TLS ClientHello analyses the application layer protocol negotiation extension field and if it contains "h2clr" value it blocks the TLS ClientHello. (2), (3), (4) The User-Agent receives an TLS Alert (e.g. unsupported_extension) indicating that that the resource does not support HTTP2 and it will fall back to HTTP/1.1 and will issue a GET /1.1. The proxy intercepts the GET and redirects the User- Agent to a portal secure page. Note that the portal page is an https URI resource, so that the user can be sure of the identity of the portal. Loreto, et al. Expires August 18, 2014 [Page 10] Internet-Draft Trusted Proxy 2.0 February 2014 (5) When the User-Agent arrives to the portal page it becomes aware of the existence of a Proxy in the access network and receives a consent request for the proxy to stay in the path for HTTP URI resources. The user-agent then SHOULD secure user consent. When the user has given consent to the use of a proxy, both the User-Agent and the Proxy SHOULD store this consent so that the user does not have to give consent for each new TLS connection involving the proxy. (6) If the user provides consent, then it will start to download a certificate identifying the proxy. The proxy certificate should be issued by a trusted certification authority, where the root certificate is assumed to be preinstalled in the User-Agent. The proxy certificate SHOULD be stored in a proxy certificate repository distinct from the repository for the server certificates. The portal page may also offer the possibility to download a signed (with the proxy certificate) pac file that contains all the information to automatically configure the proxy in the User- Agent. (7) (8) The User-Agent is then forwarded to the origin initially requested and it receives the requested content, however the Proxy will insert an Alternate header that will tell the User-Agent to asynchronously upgrade to HTTP2. The presence of the pac file or of the proxy certificate for that access network will automatically configure the User-Agent in the Proxy mode. 3.2.1. Opt Out This section specifies how an user can opt out (i.e. refuse) the presence of a Proxy for all the subsequent requests toward "http" URI resources while it stays in that network (see Figure 5). If the user decides to opt out from the proxy, the User-Agent will start (step 6 in the figure below) to negotiate HTTP2 connection only using "h2" vale in the Application Layer Protocol Negotiation (ALPN) extension field, while staying in that access network. Loreto, et al. Expires August 18, 2014 [Page 11] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +------------+ +--------+ +-------------+ | user-agent | | Proxy | | Portal | | Server | +--------------+ +------------+ +--------+ +-------------+ | | | | | | | | | (1) TLS ClientHello \|/ | | |----------------------------| | | | (ALPN ProtocolName: h2clr)/|\ | | | | | | | (2) GET HTTP/1.1 | | | |--------------------------->| | | | (3) 302 | | | |<---------------------------| | | | (4) GET HTTPS/1.1 | | | |------------------------------------------>| | | (5) 200 | | | |<------------------------------------------| | | (6) TLS ClientHello | |----------------------------------------------------------->| | (ALPN ProtocolName: h2) | | (7) ServerHello | |<-----------------------------------------------------------| | (8) ChangeCipherSpec | |----------------------------------------------------------->| | (9) ChangeCipherSpec | |<-----------------------------------------------------------| | | |---(10)-stream(X)---GET------------------------------------>| | | |<------------------------(11)--stream(Z)---200 OK-----------| Figure 5: Proxy Opt Out 4. Explicit Proxy behaviour This section describes the role of the Trusted Proxy in helping the user to fetch HTTP URI resources when the user has provided consent to the Trusted Proxy to be involved. Loreto, et al. Expires August 18, 2014 [Page 12] Internet-Draft Trusted Proxy 2.0 February 2014 4.1. Secure Forward Proxy towards HTTP2 origin server +--------------+ +--------------+ +--------------+ | user-agent | | Proxy | | Server | +--------------+ +--------------+ +--------------+ | | | (TLS Proxy certificate or Captive proxy) | (mechanism has taken place) | | | | | (1) TLS ClientHello | | |--------------------------->| | | (2) ServerHello | | |<---------------------------| | | (3) ChangeCipherSpec | | |--------------------------->| | | (4) ChangeCipherSpec | | |<---------------------------| | | | | | | | |/==========HTTP2===========\| | | | | |(5)-stream(X)---GET-------->| | | | (6) TLS ClientHello | | |----------------------------->| | | (7) TLS ServerHello | | |<-----------------------------| | | (8) ChangeCipherSpec | | |----------------------------->| | | (9) ChangeCipherSpec | | |<-----------------------------| | | | | |/=========(HTTP2)============\| | |-(10)--stream(Z)---GET------->| | | | | | | | |<(11)--stream(Z)---200 OK-----| |<-(12)--stream(X)---200 OK--| | | | | |\========(HTTP2)===========/|\==========(HTTP2)===========/| | | | Figure 6: requesting an HTTP resource Loreto, et al. Expires August 18, 2014 [Page 13] Internet-Draft Trusted Proxy 2.0 February 2014 (0) The TLS Proxy Announcement (Section 3.1) or Captive Proxy (Section 3.2) mechanism has already taken place, so the User-Agent is now configure in the proxy mode. (1). . .(4) For each "http" URI resource towards a not yet contacted Server Origin, then the User-Agent negotiates a new TLS session, using the ALPN extension containing the "h2clr" tag, to establish an HTTP2 connection. (5) The User-Agent will then use the streams in the HTTP2 connection to request any resources hosted on that Origin Server. (6),(7),(8),(9) In the case the Proxy receives a request for an URI resource towards a not yet contacted Server Origin, then the trusted Proxy negotiates a new TLS session, using the ALPN extension containing the "h2clr" tag, to establish an HTTP2 connection. (10) Once the Proxy has established the HTTP2 connection toward the origin, then it picks one stream to forward the request (11) (12) The Proxy forward the answer it receives from the Origin Server to the User-Agent. 4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server In the case the "http" URI resources requested by the user-agent will be only available over HTTP/1.1 or the proxy does not have a previous knowledge about it, the proxy will then attempt to contact the resource based on its knowledge. If the proxy does not know if the resource is a HTTP2 or not it will contact it using HTTP1.1 (see Figure 7). Loreto, et al. Expires August 18, 2014 [Page 14] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +--------------+ +--------------+ | user-agent | | Proxy | | Server | +--------------+ +--------------+ +--------------+ | | | (TLS Proxy announcement or Captive proxy) | (mechanism has taken place) | | | | | (1) TLS ClientHello | | |--------------------------->| | | (2) ServerHello | | |<---------------------------| | | (3) ChangeCipherSpec | | |--------------------------->| | | (4) ChangeCipherSpec | | |<---------------------------| | | | | |/--------------------------\| | |(5)-stream(X)---GET-------->| | | | | | HTTP2 |-(6)-------GET /1.1---------->| | | | | |<-(7)-------200 OK------------| |<--(8)--stream(X)---200 OK--| | | | | |\--------------------------/| | | | | Figure 7: Origin server with only HTTP/1.1 support 4.3. Secure Forward Proxy and https URIs The Proxy intercepts the TLS ClientHello analyses the application layer protocol negotiation extension field and if it contains "h2" value it does not do anything and let the TLS handshake continue and the TLS session be established between the User-Agent and the Server (see Figure 8). Loreto, et al. Expires August 18, 2014 [Page 15] Internet-Draft Trusted Proxy 2.0 February 2014 +--------------+ +------------+ +--------+ +-------------+ | user-agent | | Proxy | | Portal | | Server | +--------------+ +------------+ +--------+ +-------------+ | | | | | | | | | (1) TLS ClientHello | |----------------------------------------------------------->| | (ALPN ProtocolName: h2) | | (2) ServerHello | |<-----------------------------------------------------------| | (3) ChangeCipherSpec | |----------------------------------------------------------->| | (4) ChangeCipherSpec | |<-----------------------------------------------------------| | | |---(5)-stream(X)---GET------------------------------------->| | | |<-------------------------(6)--stream(X)---200 OK-----------| Figure 8: Trusted Proxy and HTTPS URI resources 5. Signalling the presence of a Proxy in between The Via general-header field MUST be used by the user-agent to indicate the presence of the secure proxy between the User-Agent and the server on requests, and between the origin server and the User- Agent on responses. 6. Security Considerations This document addresses proxies that act as intermediary for HTTP2 traffic and therefore the security and privacy implications of having those proxies in the path need to be considered. MITM [4], [I-D.nottingham-http-proxy-problem] and [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and privacy issues associated with the use of proxies. Users should be made aware that, different than end-to-end HTTPS, the achievable security level is now also dependent on the security features/ capabilities of the proxy as to what cipher suites it supports, which root CA certificates it trusts, how it checks certificate revocation status, etc. Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information. By requiring proxy certificates to be extended validation Loreto, et al. Expires August 18, 2014 [Page 16] Internet-Draft Trusted Proxy 2.0 February 2014 certificates the barrier to attaining a proxy certificate is significantly increased. To further increase the security, the validation by the CA could also include technical details and processes relevant for the security. The owner could for example be obliged to apply security patches in a timely fashion. This document proposes two alternative approaches to making the presence of proxy explicit to users and letting them decide whether they accept that. A user can opt out and choose to bypass the proxy. This ensures that a proxy never acts as intermediary for HTTP2 traffic unless authorized by the user. When the user has given consent to the presence of the proxy, the User-Agent switches to a Proxy mode in which it does not check the hostname of the origin server against the server's identity as presented in the Server Certificate message. However if any of the following checks fails the User-Agent should immediately exit this Proxy mode: 1. the server's certificate is issued by a trusted CA and the certificate is valid; 2. the Extended Key Usage extension is present in the certificate and indicates the owner of this certificate is a proxy; 3. the server possesses the private key corresponding to the certificate. 7. Privacy Considerations 8. IANA Considerations This document creates a registration for the identification of HTTP2 used to transport "http" URIs resources in the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in [TLSALPN]. Protocol: HTTP2 used to transport "http" URIs resources Identification Sequence: 0x68 0x32 0x63 0x6C 0x72 ("h2clr") 9. Acknowledgments The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson, Nicolas Mailhot and Salman Taj for their ideas, technical suggestions Loreto, et al. Expires August 18, 2014 [Page 17] Internet-Draft Trusted Proxy 2.0 February 2014 and comments. 10. References 10.1. Normative References [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "Hypertext Transfer Protocol version 2.0", draft-ietf-httpbis-http2-08 (work in progress), November 2013. [I-D.ietf-httpbis-p1-messaging] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", draft-ietf-httpbis-p1-messaging-24 (work in progress), September 2013. [I-D.nottingham-http-proxy-problem] Nottingham, M., "Problems with Proxies in HTTP", draft-nottingham-http-proxy-problem-00 (work in progress), October 2013. [I-D.rpeon-httpbis-exproxy] Peon, R., "Explicit Proxies for HTTP/2.0", draft-rpeon-httpbis-exproxy-00 (work in progress), June 2012. [I-D.vidya-httpbis-explicit-proxy-ps] Narayanan, V., "Explicit Proxying in HTTP - Problem Statement And Goals", draft-vidya-httpbis-explicit-proxy-ps-00 (work in progress), October 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Loreto, et al. Expires August 18, 2014 [Page 18] Internet-Draft Trusted Proxy 2.0 February 2014 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 10.2. Informative References [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011. URIs [1] [2] [3] [4] Authors' Addresses Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com John Mattsson Ericsson Kista Sweden Email: john.mattsson@ericsson.com Loreto, et al. Expires August 18, 2014 [Page 19] Internet-Draft Trusted Proxy 2.0 February 2014 Robert Skog Ericsson Kista Sweden Email: robert.skog@ericsson.com Hans Spaak Ericsson Kista Sweeden Email: hans.spaak@ericsson.com Gus Bourg AT&T Phone: Email: Dan Druta AT&T Phone: Email: dd5826@att.com Mohammad Hafeez AT&T Phone: Email: mh2897@att.com Loreto, et al. Expires August 18, 2014 [Page 20]