summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8565.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8565.txt')
-rw-r--r--doc/rfc/rfc8565.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc8565.txt b/doc/rfc/rfc8565.txt
new file mode 100644
index 0000000..c087fb8
--- /dev/null
+++ b/doc/rfc/rfc8565.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Independent Submission E. Fokschaner
+Request for Comments: 8565 1 April 2019
+Category: Informational
+ISSN: 2070-1721
+
+
+ Hypertext Jeopardy Protocol (HTJP/1.0)
+
+Abstract
+
+ The Hypertext Jeopardy Protocol (HTJP) inverts the request/response
+ semantics of the Hypertext Transfer Protocol (HTTP). Using
+ conventional HTTP, one connects to a server, asks a question, and
+ expects a correct answer. Using HTJP, one connects to a server,
+ sends an answer, and expects a correct question. This document
+ specifies the semantics of HTJP.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This is a contribution to the RFC Series, independently of any other
+ RFC stream. The RFC Editor has chosen to publish this document at
+ its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not candidates for any level of Internet Standard;
+ see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8565.
+
+Copyright Notice
+
+ Copyright (c) 2019 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
+ (https://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.
+
+
+
+
+
+
+
+Fokschaner Informational [Page 1]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. Comparison with HTTP . . . . . . . . . . . . . . . . . . . . 3
+ 4. Response and Request Semantics . . . . . . . . . . . . . . . 4
+ 4.1. Applicability of Postel's Robustness Principle . . . . . 4
+ 4.2. Identifying the Server Associated with an HTJP Response . 5
+ 4.3. Temporal Considerations . . . . . . . . . . . . . . . . . 5
+ 4.4. Pseudo-Valid HTJP Messages . . . . . . . . . . . . . . . 6
+ 4.5. HTTP Responses That Are Not Requestable . . . . . . . . . 6
+ 5. Caches and Proxies . . . . . . . . . . . . . . . . . . . . . 7
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
+ 7.1. Securing HTTP against HTJP . . . . . . . . . . . . . . . 7
+ 7.1.1. Anti-HTJP-Nonce Header . . . . . . . . . . . . . . . 8
+ 7.2. HTJPS . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 8.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Appendix A. Hypertext Double Jeopardy Protocol . . . . . . . . . 11
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
+
+1. Introduction
+
+ The Hypertext Jeopardy Protocol (HTJP) 1.0 is a stateless
+ application-level response/request protocol that functions as the
+ semantic inverse of the Hypertext Transfer Protocol (HTTP) 1.1 .
+
+ It can roughly be specified in relation to HTTP by the following
+ rules:
+
+ o Where an HTTP client would send an HTTP request message, an HTJP
+ client would send an HTTP response message.
+
+ o Where an HTTP server would send an HTTP response message, an HTJP
+ server would send an HTTP request message.
+
+ o The HTTP request sent as an HTJP response should be an HTTP
+ request that (if sent to the appropriate HTTP server) would elicit
+ the HTTP response sent in the HTJP request.
+
+ HTJP is compatible with the HTTP/1.1 specification, at least in
+ spirit, if not in letter.
+
+
+
+
+
+
+Fokschaner Informational [Page 2]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ HTJP has novel applications in all the following areas:
+
+ o Generative automated testing of HTTP implementations and HTTP-
+ based applications.
+
+ o Monitoring of HTTP-based applications in production.
+
+ o Forensic and diagnostic reconstruction of HTTP requests from HTTP
+ response logs.
+
+ o Discovery of first-party and third-party security vulnerabilities.
+
+2. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Comparison with HTTP
+
+ It is a little-known fact that HTTP/1.1 already defines itself to be
+ its own inverse mode of operation. Section 3.1 of RFC 7230
+ [RFC7230], which describes the start line of the HTTP message format,
+ states:
+
+ In theory, a client could receive requests and a server could
+ receive responses, distinguishing them by their different start-
+ line formats, but, in practice, servers are implemented to only
+ expect a request [...] and clients are implemented to only expect
+ a response.
+
+ It is only convention that HTTP clients send HTTP requests and that
+ HTTP servers send HTTP responses. Therefore, HTJP is just HTTP with
+ some alternative conventions. It is not a distinct protocol.
+ Furthermore, since all messages in HTJP are indistinguishable from
+ HTTP messages, an HTJP peer would have no way of identifying itself
+ explicitly as using HTJP rather than HTTP.
+
+ Therefore, we describe HTJP as a "pseudo-protocol" in order to
+ distinguish clients, servers, and conversations that are using the
+ HTTP conventions laid out in this document from those that use
+ conventions that are more commonly associated with HTTP.
+
+
+
+
+
+
+
+Fokschaner Informational [Page 3]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+4. Response and Request Semantics
+
+ An HTJP request MUST be an HTTP response message. An HTJP response
+ message MUST be an HTTP request message that, if issued to the
+ appropriate HTTP server, would elicit the HTTP response specified by
+ the HTJP request being replied to.
+
+ As described in Section 3, HTJP is unconventional but valid HTTP, and
+ so the entirety of the HTTP specification (as defined in [RFC7230],
+ [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]) MUST be
+ respected when doing so is consistent with HTJP's unique semantics.
+
+ The following example illustrates a typical message exchange for an
+ HTJP request concerning the same hypothetical server from Section 2.1
+ of RFC 7230 [RFC7230].
+
+ Client request:
+
+ HTTP/1.1 200 OK
+ Date: Mon, 27 Jul 2009 12:28:53 GMT
+ Server: Apache
+ Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
+ ETag: "34aa387-d-1568eb00"
+ Accept-Ranges: bytes
+ Content-Length: 51
+ Vary: Accept-Encoding
+ Content-Type: text/plain
+
+ Hello World! My payload includes a trailing CRLF.
+
+ Server response:
+
+ GET /hello.txt HTTP/1.1
+ Host: www.example.com
+
+4.1. Applicability of Postel's Robustness Principle
+
+ Implementations of HTJP SHOULD respect Postel's Robustness Principle
+ [IAB-PROTOCOL-MAINTENANCE].
+
+ Applied to HTJP, Postel's Robustness Principle implies that, given
+ the choice of multiple valid HTJP responses for an HTJP request, one
+ SHOULD prefer a response that is more adherent to the HTTP standard
+ or uses fewer HTTP features. For example, sometimes a User-Agent
+ header has no bearing on the HTTP response from an HTTP server. On
+ seeing such a response in an HTJP request, an HTJP server could
+ validly respond with a practically unlimited number of permutations
+ on the User-Agent header value. However, it SHOULD prefer to respond
+
+
+
+Fokschaner Informational [Page 4]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ with an HTTP request that has no User-Agent header whatsoever, in
+ keeping with Postel's Robustness Principle.
+
+ The same consideration applies when encountering an HTJP request for
+ which there are both valid and "pseudo-valid" (Section 4.4) HTJP
+ responses available.
+
+4.2. Identifying the Server Associated with an HTJP Response
+
+ It may be of interest to a user of HTJP to try issuing an HTJP
+ response as an HTTP request to the appropriate server. This brings
+ up the issue of correctly identifying the host to which the HTJP
+ response should be sent. Much of the time this will be able to be
+ determined from the Host header field of the HTJP response. The Host
+ header is required by conformant HTTP/1.1 requests. In the case that
+ the Host header is not present (for example, if the HTJP response is
+ an HTTP/1.0 request rather than HTTP/1.1), an HTJP response MAY use
+ the absolute URI form in the HTTP request line, to add clarity about
+ the target host if it would be validly accepted by the server. This
+ specific example is complicated by the fact that prior to HTTP/1.1 it
+ was not required that implementations accept the absolute URI form.
+ For this reason, it is also possible to phrase the HTJP response as
+ an HTTP request to a Forward Proxy server, which would have accepted,
+ indeed needed, the absolute URI request line prior to and after
+ HTTP/1.1. As a last resort, it may be possible to heuristically
+ derive the target host of an HTJP response from the HTJP request; for
+ example, the HTJP request may have absolute references to other HTTP
+ resources that seem to come from the same host.
+
+4.3. Temporal Considerations
+
+ When an HTJP response is issued, there is no guarantee that, by the
+ time the response is received by an HTJP client, the HTTP server that
+ is associated with said response will still reply with it. Providing
+ any guarantee about "when" an HTTP server would reply with said
+ response is obviously a theoretically unsolvable problem and
+ therefore outside the scope of this HTJP specification. It is only
+ required that the HTJP response be correct at some point in the range
+ of the 32-bit Unix Timestamp; see "Seconds Since the Epoch"
+ (Section 4.16) of Unix General Concepts [UNIX-General-Concepts].
+
+ HTJP servers that are responding with an HTTP request for a volatile
+ resource, and with high confidence in the time range at which the
+ resource would be in the state described by the HTJP request, MAY add
+ a Date header to the HTJP response. This is in conformance with the
+ ability for HTTP requests to carry a Date header; see Section 7.1.1.2
+ of [RFC7231].
+
+
+
+
+Fokschaner Informational [Page 5]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ HTJP clients can try to demand more temporal certainty by adding a
+ Date header to their HTTP response, embedding criteria for the time
+ of the HTTP response in the HTTP response itself. Of course, the
+ client might still only receive that exact HTTP response if it
+ manages to deliver the HTTP request at the precise time of the
+ previously requested Date header, and even then it is still not
+ guaranteed due to HTTP caching et cetera.
+
+4.4. Pseudo-Valid HTJP Messages
+
+ In the wild, HTTP clients and servers have been known to occasionally
+ exchange HTTP messages that are not conformant to any HTTP
+ specification. For this reason, we will identify a class of messages
+ that are, on the one hand, invalid HTTP messages, yet at the same
+ time, correctly answerable HTJP requests or correct answers to an
+ HTJP request, as "pseudo-valid" HTJP messages.
+
+ Consider, for example, an HTTP server that erroneously reports a
+ Content-Length header field of zero when sending an HTTP payload of
+ non-zero length. Despite this HTTP message violating the HTTP
+ specification, it is possible for an HTJP server to receive such a
+ message and correctly respond to it, satisfying the HTJP semantics in
+ doing so.
+
+ This applies to both HTJP requests and HTJP responses. There may be
+ times when the only valid HTJP response is an invalid HTTP request.
+ When there are both valid and invalid HTTP requests that could
+ satisfy the HTJP request, Postel's Robustness Principle SHOULD be
+ applied, as described in Section 4.1.
+
+4.5. HTTP Responses That Are Not Requestable
+
+ Given that an HTJP response MUST be an HTTP request, and that HTTP
+ requests do not have a status field (such as a status code), there is
+ no way for an HTJP response to signal a failure in response to an
+ HTJP request, via a status code or otherwise. The correct HTJP
+ response to an HTJP request when a server cannot determine an HTTP
+ request that elicits the HTTP response is to not respond at all. The
+ HTJP responder MAY close the connection; however, the HTJP requester
+ MUST NOT interpret the closing of the connection as a response. This
+ can have issues when HTJP servers are hosted behind non-HTJP-aware
+ HTTP proxies, as the proxy may inject a 5xx HTTP response, which
+ could be misinterpreted as an HTJP response. See more on proxies in
+ Section 5.
+
+
+
+
+
+
+
+Fokschaner Informational [Page 6]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+5. Caches and Proxies
+
+ Despite being valid HTTP traffic, support for caching and proxying of
+ HTJP traffic is unfortunately not widespread. It is estimated that
+ currently approximately 0.0% of all HTTP-aware intermediaries
+ gracefully handle HTJP traffic. For this reason, it is currently
+ RECOMMENDED that HTJP should not be deployed behind an HTTP proxying
+ or caching layer. Support will likely increase proportionally to
+ HTJP's popularity in production.
+
+6. IANA Considerations
+
+ In order that implementations of this specification can operate
+ correctly, and in accordance with [BCP90], the following new HTTP
+ header field would need to be registered in the "Message Headers"
+ registry maintained at
+ <https://www.iana.org/assignments/message-headers/>. To find out the
+ details of this registration, an application should send an HTJP
+ request to a suitable server specifying the Anti-HTJP-Nonce value
+ that the server would have supplied had the IANA registration been
+ made.
+
+ +-------------------+----------+---------------+---------------+
+ | Header Field Name | Protocol | Status | Reference |
+ +-------------------+----------+---------------+---------------+
+ | Anti-HTJP-Nonce | http | informational | Section 7.1.1 |
+ +-------------------+----------+---------------+---------------+
+
+7. Security Considerations
+
+7.1. Securing HTTP against HTJP
+
+ An incomplete implementation of HTJP is inadvisable from a security
+ perspective. A complete implementation of HTJP may have interesting
+ security features that are worthy of detailed examination. Due to
+ its semantics, the issuing of a successfully authorized HTTP response
+ to an HTJP server will result in a reply containing the HTTP request
+ that elicits said response, including any credentials, tokens,
+ cookies, or other authorization materials that were required to
+ elicit that response.
+
+
+
+
+
+
+
+
+
+
+
+Fokschaner Informational [Page 7]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ As an example:
+
+ Client request:
+
+ HTTP/1.1 200 OK
+ Date: Mon, 27 Jul 2009 12:28:53 GMT
+ Content-Length: 61
+ Content-Type: text/plain
+
+ Some predictable information accessed using authorization.
+
+ Server response:
+ (line breaks in the Authorization header are for RFC formatting)
+
+ GET /information.txt HTTP/1.1
+ Host: authorised-usage-service.example.com
+ Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
+ eyJzdWIiOiJodGpwIiwibmFtZSI6IkV2ZXJ5b25lIiwiaWF0IjowfQ.
+ JOL-kIObgTI0MzFfm1yVFFkIo1xf7DZGjY_oedRBZW0
+
+ Given that we cannot prevent anyone from attempting to implement
+ HTJP, it is RECOMMENDED to consider how HTJP impacts security when
+ using HTTP.
+
+ Note that it was only possible to query for the credentialed HTTP
+ request because the response to the authorized request was
+ predictable. HTTP servers could mitigate this vulnerability exposed
+ by HTJP by only serving a response that is at least as secret as the
+ credentials themselves in response to an authorized request.
+
+7.1.1. Anti-HTJP-Nonce Header
+
+ A generic solution to this problem is to use an "Anti-HTJP-Nonce"
+ HTTP header in HTTP responses. The value of an "Anti-HTJP-Nonce"
+ header SHOULD be a cryptographically secure random number in any
+ encoding that is valid for an HTTP header value. The length of this
+ number SHOULD be determined by the producer of the HTTP response,
+ accounting for their method of random number generation and their
+ threat model.
+
+7.2. HTJPS
+
+ HTJP, being just HTTP, has most of the same security concerns and
+ features as HTTP itself. For example, the use of HTJP over an
+ encrypted connection, such as TLS 1.3 [RFC8446], similar to HTTP
+ Secure (HTTPS), is referred to as HTJP Secure (HTJPS). However, it
+ is important to note that, unlike with HTTPS, it is not expected that
+ the hostname you are securely communicating with is the same hostname
+
+
+
+Fokschaner Informational [Page 8]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ as featured in the Host headers or absolute URIs of the HTJP messages
+ themselves, as HTJP messages are typically referring to other HTTP
+ hosts. This excludes the case of a server that supports both
+ conventional HTTP and HTJP, where it is possible to make HTJP
+ requests securely to the same host that is also the subject of the
+ HTJP requests being made.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Message Syntax and Routing",
+ RFC 7230, DOI 10.17487/RFC7230, June 2014,
+ <https://www.rfc-editor.org/info/rfc7230>.
+
+ [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
+ DOI 10.17487/RFC7231, June 2014,
+ <https://www.rfc-editor.org/info/rfc7231>.
+
+ [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
+ DOI 10.17487/RFC7232, June 2014,
+ <https://www.rfc-editor.org/info/rfc7232>.
+
+ [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
+ "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
+ RFC 7233, DOI 10.17487/RFC7233, June 2014,
+ <https://www.rfc-editor.org/info/rfc7233>.
+
+ [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+ Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
+ RFC 7234, DOI 10.17487/RFC7234, June 2014,
+ <https://www.rfc-editor.org/info/rfc7234>.
+
+ [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+ Protocol (HTTP/1.1): Authentication", RFC 7235,
+ DOI 10.17487/RFC7235, June 2014,
+ <https://www.rfc-editor.org/info/rfc7235>.
+
+
+
+
+
+
+Fokschaner Informational [Page 9]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [UNIX-General-Concepts]
+ "General Concepts", Chapter 4 of "The Open Group Base
+ Specifications, Issue 7", 2018 edition, IEEE
+ Std 1003.1-2017, 2018, <http://pubs.opengroup.org/
+ onlinepubs/9699919799/basedefs/V1_chap04.html>.
+
+8.2. Informative References
+
+ [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ September 2004, <https://www.rfc-editor.org/info/bcp90>.
+
+ [IAB-PROTOCOL-MAINTENANCE]
+ Thomson, M., "The Harmful Consequences of the Robustness
+ Principle", Work in Progress, draft-iab-protocol-
+ maintenance-02, March 2019.
+
+ [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
+ Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+ <https://www.rfc-editor.org/info/rfc8446>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fokschaner Informational [Page 10]
+
+RFC 8565 Hypertext Jeopardy Protocol 1.0 1 April 2019
+
+
+Appendix A. Hypertext Double Jeopardy Protocol
+
+ Also worth mentioning, in case one encounters it in the wild, is the
+ Hypertext Double Jeopardy Protocol (HTJ2P). The Hypertext Double
+ Jeopardy Protocol 1.0 is a stateless application-level request/
+ response protocol that functions as the inverse of the Hypertext
+ Jeopardy Protocol (HTJP) 1.0 .
+
+ An HTJ2P response MUST be an HTTP response which would be issued for
+ an HTTP request delivered as the HTJ2P request. Implementations of
+ HTJ2P have groundbreaking potential in the fields of HTTP caching,
+ and in the implementation of HTJP.
+
+Acknowledgements
+
+ The author thanks Alex Trebek for his distinguished contributions to
+ culture and society. The author thanks Peter Phillips for the
+ suggestion of the Anti-HTJP-Nonce header. The author also wishes to
+ thank anyone who has ever built a tool or a technology that made
+ people ask "Why?".
+
+Author's Address
+
+ Edmund Fokschaner
+
+ Email: edfokschaner@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fokschaner Informational [Page 11]
+