]> Google LLC

dschinazi.ietf@gmail.com

Web and Internet Transport HTTP oblivious HTTP configuration extension Oblivious HTTP (OHTTP) is a protocol for forwarding encrypted HTTP messages. It does not provide Perfect Forward Secrecy (PFS). Chunked OHTTP expands OHTTP to be suitable for longer-lived streams, but still does not offer PFS. Combined, this is leading sensitive traffic to de deployed at scale without PFS. This document proposes a solution. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the HTTP Working Group mailing list (), which is archived at . Working Group information can be found at . Source for this draft and an issue tracker can be found at .

Introduction Oblivious HTTP () is a protocol for forwarding encrypted HTTP messages. It does not provide Perfect Forward Secrecy (PFS). Chunked OHTTP () expands OHTTP to be suitable for longer-lived streams, but still does not offer PFS. Unfortunately, providing a streaming abstraction over OHTTP makes it an attractive tool to provide privacy. This is leading application designers to build Remote Procedure Call (RPC) systems over this bidirectional stream, without realizing the security cost of losing PFS. This document proposes a solution that offers PFS to all data sent over OHTTP apart from the client's first flight. This provides privacy and security properties similar to TLS 0-RTT (see ) run over HTTP CONNECT (see ) without losing the performance nor request-correlation-prevention properties of OHTTP. This mechanism is designed to be backwards compatible with unextended OHTTP.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from .

Mechanism This mechanism relies on the generation of two more ephemeral key pairs per OHTTP request: one for the client (denoted skC, pkC) and one for the gateway (not denoted since it only exists inside of SetupBaseS). The client starts by generating a second ephemeral key pair, using the same KEM it has selected for this request: The client then adds the serialized public key SerializePublicKey(pkC) to its Binary HTTP () request headers using the "OHTTP-PFS" header. That header is a Structured Header Field Item of type Byte Sequence as defined in . For example: The client then encrypts the Binary HTTP request following the procedure in . The gateway follows the procedure in that same section to recover the Binary HTTP request. The gateway then checks the request for the presence of the "ohttp-pfs" header to determine whether this extension is in use. If it is, it uses the HPKE receiver context (rctxt) from the OHTTP request as the HPKE context (req_context) as follows: The client then reverses this process to extract the response. This document's editor ran out of time right before the draft deadline, so this section is still a work in progress. Please check the editor's copy, they most likely have made some progress since then.

Security Considerations TODO

IANA Considerations

OHTTP-PFS HTTP Header Field TODO

References Normative References This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document defines a binary format for representing HTTP messages. This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. Informative References Apple Mozilla This document defines a variant of the Oblivious HTTP message format that allows chunks of requests and responses to be encrypted and decrypted before the entire request or response is processed. This allows incremental processing of Oblivious HTTP messages, which is particularly useful for handling large messages or systems that process messages slowly. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.

Acknowledgments Thank you to Martin Thomson and Chris Wood for asking me to write this draft.