]> Apple

tpauly@apple.com

Mozilla

mt@lowentropy.net

ART OHAI Working Group 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. 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 OHAI Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Oblivious HTTP defines a system for sending HTTP requests and responses as encrypted messages. Clients send requests via a relay to a gateway, which is able to decrypt and forward the request to a target server. Responses are encrypted with an ephemeral symmetric key by the gateway and sent back to the client via the relay. The messages are protected with Hybrid Public Key Encryption (HPKE; ), and are intended to prevent the gateway from linking any two independent requests to the same client. The definition of Oblivious HTTP in encrypts messages such that entire request and response bodies need to be received before any of the content can be decrypted. This is well-suited for many of the use cases of Oblivious HTTP, such as DNS queries or metrics reporting. However, some applications of Oblivious HTTP can benefit from being able to encrypt and decrypt parts of the messages in chunks. If a request or response can be processed by a receiver in separate parts, and is particularly large or will be generated slowly, then sending a series of encrypted chunks can improve the performance of applications. Incremental delivery of responses allows an Oblivious Gateway Resource to provide Informational (1xx) responses (). This document defines an optional message format for Oblivious HTTP that supports the progressive creation and processing of both requests and responses. New media types are defined for this purpose.

Applicability Like the non-chunked variant, chunked Oblivious HTTP has limited applicability as described in , and requires the use of a willing Oblivious Relay Resource and Oblivious Gateway Resource. Chunked Oblivious HTTP is intended to be used in cases for where the privacy properties of Oblivious HTTP are needed -- specifically, removing linkage at the transport layer between separate HTTP requests -- but incremental processing is also needed for performance or functionality. One specific functional capability that requires chunked Oblivious HTTP is support for Informational (1xx) responses (). In order to be useful, the content of chunked Oblivious HTTP needs to be possible to process incrementally. Since incremental processing means that the message might end up being truncated, for example in the case of an error on the underlying transport, applications also need to be prepared to safely handle incomplete messages (see for more discussion). Choices about how the inner content is structured can be made independently of this chunked format; that is, Binary HTTP chunks do need not to align with those of OHTTP. Applications that use the Indeterminate format of Binary HTTP () are well-suited to using chunked Oblivious HTTP as it enables incremental construction of messages. That only applies to construction; how a message can be processed after decryption depends on how the format is processed. Binary HTTP messages in any format (either Known- or Indeterminate-Length) can be incrementally processed. Chunked Oblivious HTTP is not intended to be used for long-lived sessions between clients and servers that might build up state, or as a replacement for a proxied TLS session.

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. Notational conventions from are used in this document.

Chunked Requests and Responses Chunked Oblivious HTTP defines different media types than the non-chunked variant. These media types are "message/ohttp-chunked-req" (defined in ) and "message/ohttp-chunked-res" (defined in ). If a request uses the media type "message/ohttp-chunked-req", a successful corresponding response MUST use the media type "message/ohttp-chunked-res". Chunked Oblivious HTTP requests are defined to contain Binary HTTP requests in either Known- or Indeterminate-Length form; responses contain Binary HTTP responses; see . As with non-chunked Oblivious HTTP, the encapsulation format of chunked Oblivious HTTP can be repurposed for other media types; see . Use cases that require the use of Chunked OHTTP SHOULD only use the chunked media types for their requests, to indicate that Chunked OHTTP is required. If the gateway unexpectedly does not support Chunked OHTTP, then the request will fail as if OHTTP as a whole were not supported. If clients retry requests with the non-chunked media type, a gateway could partition client anonymity sets by rejecting some requests and accepting others. Chunked OHTTP requests and responses SHOULD include the Incremental header field set to ?1 . This signals to intermediaries -- the relay in particular -- that the content of the messages are intended to be delivered incrementally. Without this signal, intermediaries might buffer request or response body until complete, removing some of the benefits of using Chunked OHTTP. Incremental processing of messages does not always require incremental forwarding in the network. An endpoint might reasonably omit the Incremental header field if it only wants to support incremental processing of a complete message. Chunked OHTTP messages generally will not include a Content-Length header field, since the complete length of all chunks might not be known ahead of time. For example, a Chunked OHTTP request could look like the following: ]]> Implementations MUST support receiving chunks that contain 2¹⁴ (16384) octets of data prior to encapsulation. Senders of chunks SHOULD limit their chunks to this size, unless they are aware of support for larger sizes by the receiving party.

Request Format Chunked OHTTP requests start with the same header as used for the non-chunked variant, which consists of a key ID, algorithm IDs, and the KEM shared secret. This header is followed by chunks of data protected with HPKE, each of which is preceded by a variable-length integer (as defined in ) that indicates the length of the chunk. The final chunk is preceded by a length field with the value 0, which means the chunk extends to the end of the outer stream. This format relies on its length being indicated by the protocol that carries the message; for HTTP, the final chunk ends at the end of the HTTP message content.

Chunked Encapsulated Request Format

The content of the HPKE-protected chunks is defined in .

Response Format Chunked OHTTP responses start with a nonce, followed by chunks of data protected with an AEAD. Each chunk is preceded by a variable-length integer that indicates the length of the chunk. The final chunk is preceded by a length field with the value 0, which means the chunk extends to the end of the outer stream.

Chunked Encapsulated Response Format

Encapsulation of Chunks The encapsulation of chunked Oblivious HTTP requests and responses uses the same approach as the non-chunked variant, with the difference that the bodies of requests and responses are sealed and opened in chunks, instead of as a whole. The AEAD that protects both requests and responses protects individual chunks from modification or truncation. Additionally, chunk authentication protects two other pieces of information:

1. the order of the chunks (the sequence number of each chunk), which is included in the nonce of each chunk.
2. which chunk is the final chunk, which is indicated by a sentinel in the Additional Authenticated Data (AAD) of the final chunk.

The format of the outer packaging that carries the chunks (the length prefix for each chunk specifically) is not explicitly authenticated. This allows the chunks to be transported by alternative means, and still be valid as long as the order and finality are preserved. In particular, the variable-length encoding used for lengths allows for different expressions of the same value, where the choice between equivalent encodings is not authenticated. When translating from an HTTP message that is already divided into chunks -- such as the chunked transfer coding in HTTP/1.1 () or DATA frames in HTTP/2 or HTTP/3 ( and ) -- there is no expectation that any chunks align. As noted in , the chunking of the encapsulated binary HTTP message and the binary HTTP message do not need to be aligned. A non-final chunk MUST NOT contain a zero-length plaintext. A receiver MUST treat the receipt of a chunk that contains no data as equivalent to a decryption error, unless that chunk is the final chunk.

Request Encapsulation For requests, the setup of the HPKE context and the encrypted request header is the same as the non-chunked variant. This is the Chunked Request Header defined in . Each chunk is sealed using the HPKE context. For non-final chunks, the AAD is empty. The final chunk in a request uses an AAD of the ASCII string "final" (0x66696e616c) and is prefixed with a zero length. HPKE already maintains a sequence number for sealing operations as part of the context, so the order of chunks is protected. HPKE will produce an error if the sequence number overflows, which puts a limit on the number of chunks that can be sent in a request.

Response Encapsulation For responses, the first piece of data sent back is the response nonce, as in the non-chunked variant. As in the non-chunked variant, the length of the nonce is max(Nn, Nk), where Nn and Nk are the length of the AEAD nonce and key. Each chunk is sealed using the same AEAD key and AEAD nonce that are derived for the non-chunked variant, which are calculated as follows: The sender also maintains a counter of chunks, which is set to 0 for the first chunk and incremented by 1 after encoding each chunk. The AEAD nonce is XORed with the counter for encrypting (and decrypting) each chunk. For non-final chunks, the AAD is empty. The final chunk in a response uses an AAD of the string "final" and is prefixed with a zero length. If the counter reached the maximum value that can be held in an integer with Nn bytes (that maximum being 256^Nn), where Nn is the length of the AEAD nonce, the chunk_nonce would wrap and be reused. Therefore, the response MUST NOT use 256^Nn or more chunks. However, this limit does not consider security margins; see .

Security Considerations In general, Chunked OHTTP inherits the same security considerations as Oblivious HTTP . Note specifically that while Chunked OHTTP allows for incremental delivery and processing of messages, it does not add forward secrecy between chunks. As with the non-chunked variant, forward secrecy is only provided when changing the key configuration. This is particularly important when chunking is used to enable interactivity. The use of Chunked OHTTP can be considered part of the configuration a client knows about for a particular gateway. As such, the use of Chunked OHTTP falls under the same consistency privacy considerations as the rest of the configuration (see ). Specifically, clients SHOULD NOT fall back from Chunked OHTTP to the non-chunked variant if they are configured to used chunking. Falling back would allow clients to have inconsistent behavior that could be used to partition client anonymity sets.

Message Truncation The primary advantage of a chunked encoding is that chunked requests or responses can be generated or processed incrementally. However, for a recipient in particular, processing an incomplete message can have security consequences. Truncation might be the result of interference at the network layer, or by a malicious Oblivious Relay Resource. The potential for message truncation is not a new concern for HTTP. All versions of HTTP provide incremental delivery of messages. For this use of Oblivious HTTP, incremental processing that might result in side-effects demands particular attention as Oblivious HTTP does not provide strong protection against replay attacks; see . The risks from replay of incremental processing are in addition to the risks from replaying entire messages. Endpoints that receive chunked messages can perform early processing if the risks are understood and accepted. Conversely, endpoints that depend on having a complete message MUST ensure that they do not consider a message complete until having received a chunk with a 0-valued length prefix, which was successfully decrypted using the expected sentinel value, "final", in the AAD.

Interactivity and Privacy Without chunking, Oblivious HTTP involves a single request and response, with no further interactivity. Using a chunked variant at both Client and Oblivious Gateway Resource creates the possibility that an exchange could lead to multiple rounds of interaction. Information from early chunks from a peer could influence how an endpoint constructs later chunks of their message. However, the use of Chunked OHTTP does not necessarily mean that exchanges will involve interactivity. Interactivity for Chunked OHTTP can be defined as any case in which the response can influence the timing or content of the request. To help explain this distinction, the following scenarios can be used to understand different modalities for requests and responses:

• The request is sent as a single chunk, and the response is sent as a single chunk. This is a non-interactive case that is identical to the non-chunked variant.
• The request is sent as a single chunk, and the response is sent in multiple chunks. This is a non-interactive case, because there is no possibility that the client can influence its request based on the response content.
• The request is sent in multiple chunks, but either all chunks are sent before a response chunk is received, or the sending of the chunks is not influenced by the response chunks. This is a non-interactive case, since again the client's request is not influenced by any response content.
• The request is sent in multiple chunks, at least one of which specifically is sent after receiving -- and possibly processing -- a response chunk (or the complete response), where the response influences the timing and/or content of the request chunk. This is an interactive case.

In the interactive case, the Oblivious Gateway Resource can observe the round trip time to the Client, which can change the privacy assumptions of the system. Any interactivity also allows a network adversary (including the Oblivious Relay Resource) to measure the round-trip delay from themselves to the Client. Applications that require interactivity SHOULD avoid using chunked OHTTP and instead leverage protocols without the shortcomings of Oblivious HTTP. One example is combining TLS and the HTTP CONNECT method . Where interactivity is a desirable property, producing an analysis that explains why the resulting reduction in privacy is acceptable for that specific interactive application is recommended. For cases when interactivity introduces unacceptable risks, the client can ensure that it never has an interactive exchange, either by not sending its request in multiple chunks, or by ensuring that the sending of request chunks cannot be influenced by the response. Interactivity that is deliberate might be acceptable. For instance, the 100-continue feature in HTTP, which has the client withhold the body of a request until it receives a 100 Informational response, is not possible without an interactive exchange. This highlights the risks involved in the use of this chunked encoding to adapt an existing HTTP-based interaction to use Oblivious HTTP as such an adaptation might not achieve expected privacy outcomes. Interactivity does not inherently reduce replay risk unless the server explicitly verifies that a client is live (such as by having the client echo content from the response in its request). A request that is generated interactively can be replayed by a malicious relay.

Message Size Limits The security margins for many ciphers degrade as more data is protected. The total size of messages needs to be limited to limit the ability of an attacker to compromise cipher confidentiality and integrity. The multi-user analysis in describes a process for estimating limits on usage that maintain security margins. For instance, that analysis shows that to keep the Authenticated Encryption Advantage (AEA) for AEAD_AES_GCM_128 below 2^-50, the total number of bytes protected by a key can be kept below 2⁸⁰, divided by the total number of bytes protected by any key. Therefore, for AEAD_AES_GCM_128 and a target advantage of 2^-50, and a limit on the number of messages of 2²⁰, no message can exceed 2³⁰ bytes. The use of most AEAD ciphers is subject to a hard limit on ciphertext length. For this format, this limit applies to each chunk and is determined by the C_MAX parameter of the AEAD; see . AEAD ciphers also have a hard limit on the total number of chunks, which is 256^Nn. These hard limits on chunk size and count apply to both request and response.

IANA Considerations This document updates the "Media Types" registry at https://iana.org/assignments/media-types to add the media types "message/ohttp-chunked-req" (), and "message/ohttp-chunked-res" (), following the procedures of .

message/ohttp-chunked-req Media Type The "message/ohttp-chunked-req" identifies an encrypted binary HTTP request that is transmitted or processed in chunks. This is a binary format that is defined in .

Type name:

message

Subtype name:

ohttp-chunked-req

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Oblivious HTTP and applications that use Oblivious HTTP use this media type to identify encapsulated binary HTTP requests that are incrementally generated or processed.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

message/ohttp-chunked-res Media Type The "message/ohttp-chunked-res" identifies an encrypted binary HTTP response that is transmitted or processed in chunks. This is a binary format that is defined in .

Type name:

message

Subtype name:

ohttp-chunked-res

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

"binary"

Security considerations:

see

Interoperability considerations:

N/A

Published specification:

this specification

Applications that use this media type:

Oblivious HTTP and applications that use Oblivious HTTP use this media type to identify encapsulated binary HTTP responses that are incrementally generated or processed.

Fragment identifier considerations:

N/A

Additional information:

Magic number(s):

N/A

Deprecated alias names for this type:

N/A

File extension(s):

N/A

Macintosh file type code(s):

N/A

Person and email address to contact for further information:

see Authors' Addresses section

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

see Authors' Addresses section

Change controller:

IETF

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. 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. 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. Fastly Apple Mozilla This document specifies the "Incremental" HTTP header field, which instructs HTTP intermediaries to forward the HTTP message incrementally. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. IBM Research Europe - Zurich Mozilla Cloudflare An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document defines algorithms for Authenticated Encryption with Associated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. Informative References The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. 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. 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.

Example A single request and response exchange is shown here. This follows the same basic setup as the example in . The Oblivious Gateway Resource key pair is generated with a X25519 secret key of: The corresponding key configuration is: This key configuration is somehow obtained by the Client, which constructs a binary HTTP request: The client constructs an HPKE sending context with a secret key of: The corresponding public key is: The context is created with an info parameter of: This produces an encrypted message, allowing the Client to construct the following Encapsulated Request: This message contains a header, the encapsulated secret, and three encrypted chunks. Line breaks are included above to show where these chunks start. The encrypted chunks are the result of invoking the HPKE ContextS.Seal() function three times: the first with 12 bytes of the request, the second with the remaining 13 bytes, and the last containing no data. This final chunk is marked by a zero length in the encoding and an AAD of "final" to protect against undetected message truncation. Each chunk is expanded by 16 bytes for AEAD protection. After sending this to the Oblivious Relay Resource, the Oblivious Gateway Resource decrypts and processes this message. The Target Resource produces a response like: The response is protected by exporting a secret from the HPKE context, using input keying material of: The salt is: From these, HKDF-SHA256 produces a pseudorandom key of: The resulting AES-GCM key is: The 12-byte base nonce is: The AEAD Seal() function is then used to encrypt the response in chunks to produce the Encapsulated Response: This example is split onto separate lines to show the nonce and three chunks: the first with one byte of response, the second with the remaining two bytes, and the final with zero bytes of data. The nonces for processing the chunks are, in order:

Acknowledgments Thanks to Chris Wood for helping build an initial test implementation and providing reviews. Thanks to Jonathan Hoyland for identifying some of the privacy leaks. Thanks to Ricardo Perez, Derrell Piper, and Ben Schwartz for helping find and fix issues in the document.