idnits 2.17.1 draft-nottingham-http-over-version-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2014) is 3591 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-13 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Informational June 20, 2014 5 Expires: December 22, 2014 7 The Over-Version HTTP Response Header Field 8 draft-nottingham-http-over-version-00 10 Abstract 12 The 505 (HTTP Version Not Supported) status code does not clearly 13 indicate, on its own, the scope of the assertion, nor the version(s) 14 supported. This document introduces a new header field, "Over- 15 Version", to indicate this information. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 22, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Use Case: TLS Client Authentication . . . . . . . . . . . 2 53 1.2. Notational Conventions . . . . . . . . . . . . . . . . . 3 54 2. The Over-Version HTTP Header Field . . . . . . . . . . . . . 3 55 2.1. Over-Version Scopes . . . . . . . . . . . . . . . . . . . 3 56 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 The semantics of the 505 (Version Not Supported) status code are 66 defined by [RFC7231] as: 68 The 505 (HTTP Version Not Supported) status code indicates that the 69 server does not support, or refuses to support, the major version of 70 HTTP that was used in the request message. The server is indicating 71 that it is unable or unwilling to complete the request using the same 72 major version as the client, as described in Section 2.6 of 73 [RFC7230], other than with this error message. The server should 74 generate a representation for the 505 response that describes why 75 that version is not supported and what other protocols are supported 76 by that server. 78 This document defines a new HTTP response header, "Over-Version", to 79 be used in 505 responses to specify the protocol version(s) that can 80 be used, what resource(s) that assertion applies to, and how long it 81 is valid for (leveraging Cache-Control). 83 1.1. Use Case: TLS Client Authentication 85 While Over-Version might have a variety of applications, the primary 86 use case for them is the signaling that a resource (or set of 87 resources) requires TLS Client Authentication in HTTP/2 88 [I-D.ietf-httpbis-http2]. Since TLS renegotiation has been forbidden 89 in that protocol, a means of signaling that a particular request 90 should be made on a HTTP/1.1 connection is needed, so that a client 91 can use that protocol, allowing the server to perform renegotiation 92 to initiate client authentication. 94 1.2. Notational Conventions 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 Furthermore, this document uses the Augmented BNF defined in 101 [RFC5234], along with the #rule list extension defined in [RFC7230], 102 Section 7. 104 2. The Over-Version HTTP Header Field 106 The Over-Version HTTP Header field, when occurring in 505 (Version 107 Not Supported) responses, asserts the version or versions of HTTP 108 that are supported, and what resource(s) the assertion applies to, 109 and optionally how long it lasts. 111 Over-Version = 1*( OWS ";" OWS parameter ) 113 This document specifies the following over-version parameters: 115 o "scope" - one of "origin", "resource" or "prefix" (see below) 117 o "version-id" - a space-separated list of ALPN protocol identifiers 118 [I-D.ietf-tls-applayerprotoneg]. 120 Additionally, when Over-Version is in use, it indicates that the 121 Cache-Control header conveys a cache policy that is applicable to 122 this information (as well as the response itself). 124 For example: 126 HTTP/1.1 505 Version Not Supported 127 Over-Version: scope="prefix", version-id="h2" 128 Cache-Control: max=age=60 130 This response indicates that the requested resource and its children 131 cannot be reached over the current protocol version, and that for the 132 next 60 seconds, the client can successfully request them using the 133 "h2" protocol (in this case, HTTP/2). 135 2.1. Over-Version Scopes 137 This document defines the following values for the "scope" parameter; 139 o "origin" - indicates that the over-version applies to all 140 resources on the origin of the request 142 o "resource" - indicates that the over-version applies to the 143 requested resource only (i.e., matching origin, path, and query) 145 o "prefix" - indicates that the over-version applies to resources 146 when the origin matches and the requested resource's path segments 147 are a prefix. For example, if the requested resource's path is 148 "/foo" then "/foo", "/foo?bar", "/foo/bar", "/foo/bar/baz" would 149 share the over-version, while "/bar", "/foobar" and "/bar/foo" 150 would not. 152 3. IANA Considerations 154 This document registers a new HTTP header field, "Over-Version", into 155 the Permanent Message Header Field Name Registry. 157 o Header Field Name: Over-Version 159 o Protocol: HTTP 161 o Status: standard 163 o Reference: [this document] 165 4. Security Considerations 167 Over-Version can be used to effect a downgrade attack by a man-in- 168 the-middle. When received over an insecure channel, it SHOULD be 169 ignored. 171 Over-Version can also be used to effect a downgrade attack by a party 172 that has the ability to inject response headers on the same origin. 173 The "origin" scope in particular is able to be misused, and SHOULD be 174 ignored unless the security properties of the new protocol are equal 175 to or better than the existing one. 177 5. References 179 5.1. Normative References 181 [I-D.ietf-tls-applayerprotoneg] 182 Friedl, S., Popov, A., Langley, A., and S. Emile, 183 "Transport Layer Security (TLS) Application Layer Protocol 184 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 185 (work in progress), March 2014. 187 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 191 Specifications: ABNF", STD 68, RFC 5234, January 2008. 193 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 194 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 195 2014. 197 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 198 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 200 5.2. Informative References 202 [I-D.ietf-httpbis-http2] 203 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 204 Protocol version 2", draft-ietf-httpbis-http2-13 (work in 205 progress), June 2014. 207 Author's Address 209 Mark Nottingham 211 Email: mnot@mnot.net 212 URI: http://www.mnot.net/