Network Working Group R.Peon Internet Draft Google Intended status: Standards Track G. Montenegro Expires: March 2014 Microsoft Corporation September 4, 2013 Profiles for Initial Server Settings draft-montenegro-httpbis-http2-server-profiles-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November, 2013. Copyright Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Peon, Montenegro et. al. [Page 1] Internet-Draft Server Profiles for Initial Settings May 2013 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. Abstract In HTTP/2.0, if running over TLS, the client is the first to transmit HTTP/2.0 frames on the new session. With its first transmission to the server, the client can already overrun some of the server settings and preferences, leading to failure conditions and unnecessary complexity. This document proposes a solution to this problem based on a very small set of server profiles for initial settings sent within the TLS handshake. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Definition of Server Profiles for Initial Settings.............3 3. Usage..........................................................4 4. Pros and Cons of Server Profiles...............................5 5. Security Considerations........................................6 6. IANA Considerations............................................6 7. Acknowledgments................................................6 8. References.....................................................7 8.1. Normative References......................................7 8.2. Informative References....................................7 1. Introduction In HTTP/2.0 [I-D.ietf-httpbis-http2] there is an issue with unknown startup state in the TLS case (for "HTTPS"): the client initiates the session by transmitting its SETTINGS and any requests it wishes. However, at this time, it has not yet heard the SETTINGS from the server, so the initial requests could overrun some of the server's preferences. However, if the server could somehow communicate its preferences to the client prior to the start of the HTTP/2.0 session, then the client will not overrun any of the server's preferences when it starts transmitting on the new session. Peon, Montenegro, et. al. [Page 2] Internet-Draft Server Profiles for Initial Settings May 2013 This documents proposes a profile-based approach, based on defining server profiles for initial settings sent by the server within the TLS handshake: a compact server profile vs a normal server profile. The profiles are communicated as part of the exchanged application- layer protocol names, precisely as supported already by ALPN. Of course, the compact profile is not limited to embedded/constrained servers. It could be used by a regular web server if it wishes to reduce its initial resource usage for new connections for whatever reason. These profiles are just means to communicate initial SETTINGS. These SETTINGS are no different from any other, and can be subsequently modified by another SETTINGS frames, per HTTP/2.0. For example, a server may use a compact profile for the beginning of a session, after which it may send an updated set of SETTINGS to the client, increasing the use of resources to match (or exceed) those used by the normal profile. A point bears repeating: this issue is only with server SETTINGS in the TLS case. The profiles are only for server initial SETTINGS. The client does not have this issue, as it starts the HTTP/2.0 session by sending its SETTINGS (within the connection header), so when the server gets a chance to initially transmit on the new session it is guaranteed to have received the client SETTINGS already. As an aside, in the HTTP non-TLS case (which is not the subject of this document), HTTP/2.0 already fixed that by allowing the client to send its settings in an HTTP/1.1 header (HTTP2-Settings). 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Definition of Server Profiles for Initial Settings There are two profiles for server initial settings: the compact server profile and the normal server profile. Profile 1 - constrained server profile: . Negotiation strings: . "H2c" for final HTTP/2.0 specification . "HTTP-draft-06/2.0c" for draft version -06 Peon, Montenegro, et. al. [Page 3] Internet-Draft Server Profiles for Initial Settings May 2013 (Appending a "c" to the negotiation string denotes the "compact" profile.) . SETTINGS_MAX_CONCURRENT_STREAMS: value: 1 . SETTINGS_INITIAL_WINDOW_SIZE: value: 2K . SETTINGS_FLOW_CONTROL_OPTIONS: 0 (flow control on) . SETTINGS_MAX_BUFFER_SIZE: 1K Profile 2 - normal server profile . Negotiation strings: . "H2" for final HTTP/2.0 specification . "HTTP-draft-06/2.0" for draft version -06 (Unchanged string implies the web server profile) . SETTINGS_MAX_CONCURRENT_STREAMS: value: 100 . SETTINGS_INITIAL_WINDOW_SIZE: value: 64K . SETTINGS_FLOW_CONTROL_OPTIONS: 0 (flow control on) . SETTINGS_MAX_BUFFER_SIZE: 4K These profiles are to be defined in the base HTTP/2.0 document, and the negotiation strings would be registered with IANA in the ALPN registry. Only the strings corresponding to the final HTTP/2.0 specification are to be registered in IANA. Other experimental profiles could be defined for use in testing new features, without need to register them in IANA. 3. Usage The client uses ALPN to include the negotiation strings for both profiles: in the TLS client hello, the client includes both of these: Example 1 - Profiles based on final HTTP/2.0 specification: . H2c . H2 Example 2 - Profiles based on draft versions of the HTTP/2.0 specifications, e.g., for draft version -06, the client includes both of these: . HTTP-draft-06/2.0c . HTTP-draft-06/2.0 Peon, Montenegro, et. al. [Page 4] Internet-Draft Server Profiles for Initial Settings May 2013 The server uses ALPN to respond with the negotiation string it selects. For example 1, to select the compact profile the server includes this in its Hello: "H2c". Alternatively, if the client had proposed draft -06 (Example 2), the server would respond with "HTTP- draft-04/2.0c". The client interprets the returned string and sets the SETTINGS for the server accordingly. The client can initiate the HTTP/2.0 session (beginning with the client's SETTINGS frame) and MUST respect the server SETTINGS. In examples above, the client sets the server SETTINGS per the compact server profile. Per usual HTTP/2.0 rules, either endpoint is free to adjust their preferences by sending additional SETTINGS frames. Upon receipt of the client's first transmission on the HTTP/2.0 session, the server responds with its own SETTINGS frame, which can already supersede any SETTINGS set via the server profile. This is in keeping with HTTP/2.0 rules. 4. Pros and Cons of Server Profiles Server profiles for initial settings are not the only possible approach for the server to communicate its settings in advance of the HTTP/2.0 session. This section compares to the other alternative that has been discussed, namely, the option of augmenting the TLS handshake to allow embedding the server SETTINGS (e.g., as ancillary data to the application-layer protocol negotiation itself). Pros: . No need to modify TLS handshake any further. This is a HUGE benefit, considering that ALPN has entered working group last call in the TLS WG. . No need to engage TLS WG (less extraneous dependencies). . Simple to spec (once the profiles are agreed upon). . HTTP/2.0 only needs to define the strings augmented with the profiles and register those in the ALPN registry (as well as other HTTPbis registries that may be applicable). . This approach of profiling could be used to distinguish experimental from production-grade servers. Peon, Montenegro, et. al. [Page 5] Internet-Draft Server Profiles for Initial Settings May 2013 . As compared to attempting to define default values for the server settings, the profile approach mitigates this by not requiring ONE set of defaults that must work for every type of server (which we fruitlessly attempted before), but 2 sets of defaults depending on the server profile. Targeting a limited set of 2 profiles should make this manageable (normal web server vs compact/embedded server). Cons: . Increases the size of the client TLS Hello as each profile would imply a separate string per ALPN specs, e.g., "H2c" and "H2". Not a big concern as long as we limit it to, say, 2 profiles. At any rate, other TLS extensions are growing this anyway. 5. Security Considerations None. 6. IANA Considerations The negotiation strings must be registered with IANA's ALPN registry: Application Layer Protocol Negotiation protocol byte strings within the TLS section. This is not new, as HTTP/2.0 has to do this anyways. This proposal just gives a certain format to the strings that would ultimately be registered by HTTP/2.0. In particular, the compact server profile would be denoted by the string "H2c". The normal server profile would be denoted by the string "H2". Notice that in the interest of terseness, this proposal departs from the notation currently used in HTTP/2.0. Current HTTP/2.0 would have the compact and normal server profiles be registered as "HTTP/2.0c" and "HTTP/2.0". 7. Acknowledgments Thanks to Mark Nottingham for useful discussions in this space. This document was prepared using 2-Word-v2.0.template.doc. Peon, Montenegro, et. al. [Page 6] Internet-Draft Server Profiles for Initial Settings May 2013 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-httpbis-http2] Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "Hypertext Transfer Protocol version 2.0", draft-ietf- httpbis-http2 (work in progress), August 2013. 8.2. Informative References None. Author's Addresses Roberto Peon Google, Inc Email: fenix@google.com Gabriel Montenegro Microsoft Corporation Phone: Email: gabriel.montenegro@microsoft.com Peon, Montenegro, et. al. [Page 7]