Oblivious HTTPMozillamt@lowentropy.netCloudflarecaw@heapingbits.net
ART
HTTPBISThis document describes a system for the forwarding of encrypted HTTP messages.
This allows a client to make multiple requests of a server without the server being able
to link those requests to the client or to identify the requests as having come
from the same client.Discussion VenuesDiscussion of this document takes place on the
HTTP Working Group mailing list (http@ietf.org),
which is archived at .Source for this draft and an issue tracker can be found at
.IntroductionThe act of making a request using HTTP reveals information about the client
identity to a server. Though the content of requests might reveal information,
that is information under the control of the client. In comparison, the source
address on the connection reveals information that a client has only limited
control over.Even where an IP address is not directly attributed to an individual, the use
of an address over time can be used to correlate requests. Servers are able to
use this information to assemble profiles of client behavior, from which they
can make inferences about the people involved. The use of persistent
connections to make multiple requests improves performance, but provides
servers with additional certainty about the identity of clients in a similar
fashion.Use of an HTTP proxy can provide a degree of protection against servers
correlating requests. Systems like virtual private networks or the Tor network
, provide other options for clients.Though the overhead imposed by these methods varies, the cost for each request
is significant. Preventing request linkability requires that each request
use a completely new TLS connection to the server. At a minimum,
this requires an additional round trip to the server in addition to that
required by the request. In addition to having high latency, there are
significant secondary costs, both in terms of the number of additional bytes
exchanged and the CPU cost of cryptographic computations.This document describes a method of encapsulation for binary HTTP messages
using Hybrid Public Key Encryption (HPKE;
). This protects the content of both requests and
responses and enables a deployment architecture that can separate the identity
of a requester from the request.Though this scheme requires that servers and proxies explicitly support it,
this design represents a performance improvement over options that perform just
one request in each connection. With limited trust placed in the proxy (see
), clients are assured that requests are not uniquely attributed to
them or linked to other requests.Conventions and DefinitionsThe 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.
Encapsulated Request:
An HTTP request that is encapsulated in an HPKE-encrypted message; see
.
Encapsulated Response:
An HTTP response that is encapsulated in an HPKE-encrypted message; see
.
Oblivious Proxy Resource:
An intermediary that forwards requests and responses between clients and a
single oblivious request resource.
Oblivious Request Resource:
A resource that can receive an encapsulated request, extract the contents of
that request, forward it to an oblivious target resource, receive a response,
encapsulate that response, then return that response.
Oblivious Target Resource:
The resource that is the target of an encapsulated request. This resource
logically handles only regular HTTP requests and responses and so might be
ignorant of the use of oblivious HTTP to reach it.
This draft includes pseudocode that uses the functions and conventions defined
in .Encoding an integer to a sequence of bytes in network byte order is described
using the function encode(n, v), where n is the number of bytes and v is
the integer value. The function len() returns the length of a sequence of
bytes.Formats are described using notation from .OverviewA client learns the following:
The identity of an oblivious request resource. This might include some
information about oblivious target resources that the oblivious request
resource supports.
The details of an HPKE public key that the oblivious request resource accepts,
including an identifier for that key and the HPKE algorithms that are
used with that key.
The identity of an oblivious proxy resource that will forward encapsulated
requests and responses to the oblivious request resource.
This information allows the client to make a request of an oblivious target
resource without that resource having only a limited ability to correlate that
request with the client IP or other requests that the client might make to that
server.In order to make a request to an oblivious target resource, the following steps
occur, as shown in :
The client constructs an HTTP request for an oblivious target resource.
The client encodes the HTTP request in a binary HTTP message and then
encapsulates that message using HPKE and the process from .
The client sends a POST request to the oblivious proxy resource with the
encapsulated request as the content of that message.
The oblivious proxy resource forwards this request to the oblivious request
resource.
The oblivious request resource receives this request and removes
the HPKE protection to obtain an HTTP request.
The oblivious request resource makes an HTTP request that includes the target
URI, method, fields, and content of the request it acquires.
The oblivious target resource answers this HTTP request with an HTTP
response.
The oblivious request resource encapsulates the HTTP response following the
process in and sends this in response to the request from the
oblivious proxy resource.
The oblivious proxy resource forwards this response to the client.
The client removes the encapsulation to obtain the response to the original
request.
ApplicabilityOblivious HTTP has limited applicability. Many uses of HTTP benefit from being
able to carry state between requests, such as with cookies (),
authentication (Section 11 of ), or even
alternative services (). Oblivious HTTP seeks to prevent this sort
of linkage, which requires that applications not carry state between requests.Oblivious HTTP is primarily useful where privacy risks associated with possible
stateful treatment of requests are sufficiently negative that the cost of
deploying this protocol can be justified. Oblivious HTTP is simpler and less
costly than more robust systems, like Prio () or Tor
(), which can provide stronger guarantees at higher operational costs.Oblivious HTTP is more costly than a direct connection to a server. Some costs,
like those involved with connection setup, can be amortized, but there are
several ways in which oblivious HTTP is more expensive than a direct request:
Each oblivious request requires at least two regular HTTP requests, which adds
latency.
Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and AEAD expansion.
Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.
Examples of where preventing the linking of requests might justify these costs
include:
DNS queries. DNS queries made to a recursive resolver reveal information
about the requester, particularly if linked to other queries.
Telemetry submission. Applications that submit reports about their usage to
their developers might use oblivious HTTP for some types of moderately
sensitive data.
Key ConfigurationA client needs to acquire information about the key configuration of the
oblivious request resource in order to send encapsulated requests.In order to ensure that clients do not encapsulate messages that other entities
can intercept, the key configuration MUST be authenticated and have integrity
protection.This document describes the "application/ohttp-keys" media type; see
. This media type might be used, for example with HTTPS, as part
of a system for configuring or discovering key configurations. Note however
that such a system needs to consider the potential for key configuration to be
used to compromise client privacy; see .Specifying a format for expressing the information a client needs to construct
an encapsulated request ensures that different client implementations can be
configured in the same way. This also enables advertising key configurations in
a consistent format.A client might have multiple key configurations to select from when
encapsulating a request. Clients are responsible for selecting a preferred key
configuration from those it supports. Clients need to consider both the key
encapsulation method (KEM) and the combinations of key derivation function
(KDF) and authenticated encryption with associated data (AEAD) in this
decision.Evolution of the key configuration format is supported through the definition
of new formats that are identified by new media types.Key Configuration EncodingA single key configuration consists of a key identifier, a public key, an
identifier for the KEM that the public key uses, and a set HPKE symmetric
algorithms. Each symmetric algorithm consists of an identifier for a KDF and an
identifier for an AEAD. shows a single key configuration, KeyConfig, that is
expressed using the TLS syntax; see .The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF, and AEAD
respectively. The definitions for these identifiers and the semantics of the
algorithms they identify can be found in . The Npk parameter
corresponding to the HpkeKdfId can be found in .Key Configuration Media TypeThe "application/ohttp-keys" format is a media type that identifies a
serialized collection of key configurations. The content of this media type
comprises one or more key configuration encodings (see ) that are
concatenated.
Type name:
application
Subtype name:
ohttp-keys
Required parameters:
N/A
Optional parameters:
None
Encoding considerations:
only "8bit" or "binary" is permitted
Security considerations:
see
Interoperability considerations:
N/A
Published specification:
this specification
Applications that use this media type:
N/A
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:
IESG
HPKE EncapsulationHTTP message encapsulation uses HPKE for request and response encryption.
An encapsulated HTTP message includes the following values:
A binary-encoded HTTP message; see .
Padding of arbitrary length which MUST contain all zeroes.
The encoding of an HTTP message is as follows:An Encapsulated Request is comprised of a length-prefixed key identifier and a
HPKE-protected request message. HPKE protection includes an encapsulated KEM
shared secret (or enc), plus the AEAD-protected request message. An
Encapsulated Request is shown in . describes the
process for constructing and processing an Encapsulated Request.The Nenc parameter corresponding to the HpkeKdfId can be found in .Responses are bound to responses and so consist only of AEAD-protected content.
describes the process for constructing and processing an
Encapsulated Response.The size of the Nonce field in an Encapsulated Response corresponds to the
size of an AEAD key for the corresponding HPKE ciphersuite.Encapsulation of RequestsClients encapsulate a request request using values from a key configuration:
the key identifier from the configuration, keyID, with the corresponding KEM
identified by kemID,
the public key from the configuration, pkR, and
a selected combination of KDF, identified by kdfID, and AEAD, identified by
aeadID.
The client then constructs an encapsulated request, enc_request, as follows:
Compute an HPKE context using pkR, yielding context and encapsulation
key enc.
Construct associated data, aad, by concatenating the values of keyID,
kemID, kdfID, and aeadID, as one 8-bit integer and three 16-bit
integers, respectively, each in network byte order.
Encrypt (seal) request with aad as associated data using context,
yielding ciphertext ct.
Concatenate the values of aad, enc, and ct, yielding an Encapsulated
Request enc_request.
Note that enc is of fixed-length, so there is no ambiguity in parsing this
structure.In pseudocode, this procedure is as follows:Servers decrypt an Encapsulated Request by reversing this process. Given an
Encapsulated Request enc_request, a server:
Parses enc_request into keyID, kemID, kdfID, aeadID, enc, and ct
(indicated using the function parse() in pseudocode). The server is then
able to find the HPKE private key, skR, corresponding to keyID.
a. If keyID does not identify a key matching the type of kemID, the server
returns an error.
b. If kdfID and aeadID identify a combination of KDF and AEAD that the
server is unwilling to use with skR, the server returns an error.
Compute an HPKE context using skR and the encapsulated key enc,
yielding context.
Construct additional associated data, aad, from keyID, kdfID, and
aeadID or as the first five bytes of enc_request.
Decrypt ct using aad as associated data, yielding request or an error
on failure. If decryption fails, the server returns an error.
In pseudocode, this procedure is as follows:Encapsulation of ResponsesGiven an HPKE context context, a request message request, and a response
response, servers generate an Encapsulated Response enc_response as
follows:
Export a secret secret from context, using the string "response" as context.
The length of this secret is max(Nn, Nk), where Nn and Nk are the length
of AEAD key and nonce associated with context.
Generate a random value of length max(Nn, Nk) bytes, called response_nonce.
Extract a pseudorandom key prk using the Extract function provided by
the KDF algorithm associated with context. The ikm input to this
function is secret; the salt input is the concatenation of enc (from
enc_request) and response_nonce
Use the Expand function provided by the same KDF to extract an AEAD key
key, of length Nk - the length of the keys used by the AEAD associated
with context. Generating key uses a label of "key".
Use the same Expand function to extract a nonce nonce of length Nn -
the length of the nonce used by the AEAD. Generating nonce uses a label of
"nonce".
Encrypt response, passing the AEAD function Seal the values of key,
nonce, empty aad, and a pt input of request, which yields ct.
Concatenate response_nonce and ct, yielding an Encapsulated Response
enc_response. Note that response_nonce is of fixed-length, so there is no
ambiguity in parsing either response_nonce or ct.
In pseudocode, this procedure is as follows:Clients decrypt an Encapsulated Request by reversing this process. That is,
they first parse enc_response into response_nonce and ct. They then
follow the same process to derive values for aead_key and aead_nonce.The client uses these values to decrypt ct using the Open function provided by
the AEAD. Decrypting might produce an error, as follows:HTTP UsageA client interacts with the oblivious proxy resource by constructing an
encapsulated request. This encapsulated request is included as the content of a
POST request to the oblivious proxy resource. This request MUST only contain
those fields necessary to carry the encapsulated request: a method of POST, a
target URI of the oblivious proxy resource, a header field containing
the content type (see (), and the encapsulated request as the
request content. Clients MAY include fields that do not reveal information
about the content of the request, such as Alt-Used , or
information that it trusts the oblivious proxy resource to remove, such as
fields that are listed in the Connection header field.The oblivious proxy resource interacts with the oblivious request resource by
constructing a request using the same restrictions as the client request, except
that the target URI is the oblivious request resource. The content of this
request is copied from the client. The oblivious proxy resource MUST NOT add
information about the client to this request.When a response is received from the oblivious request resource, the oblivious
proxy resource forwards the response according to the rules of an HTTP proxy;
see .An oblivious request resource, if it receives any response from the oblivious
target resource, sends a single 200 response containing the encapsulated
response. Like the request from the client, this response MUST only contain
those fields necessary to carry the encapsulated response: a 200 status code, a
header field indicating the content type, and the encapsulated response as the
response content. As with requests, additional fields MAY be used to convey
information that does not reveal information about the encapsulated response.An oblivious request resource acts as a gateway for requests to the oblivious
target resource (see ). The one exception is that any
information it might forward in a response MUST be encapsulated, unless it is
responding to errors it detects before removing encapsulation of the request;
see .Informational ResponsesThis encapsulation does not permit progressive processing of responses. Though
the binary HTTP response format does support the inclusion of informational
(1xx) status codes, the AEAD encapsulation cannot be removed until the entire
message is received.In particular, the Expect header field with 100-continue (see Section 10.1.1 of
) cannot be used. Clients MUST NOT
construct a request that includes a 100-continue expectation; the oblivious
request resource MUST generate an error if a 100-continue expectation is
received.ErrorsA server that receives an invalid message for any reason MUST generate an HTTP
response with a 4xx status code.Errors detected by the oblivious proxy resource and errors detected by the
oblivious request resource before removing protection (including being unable to
remove encapsulation for any reason) result in the status code being sent
without protection in response to the POST request made to that resource.Errors detected by the oblivious request resource after successfully removing
encapsulation and errors detected by the oblivious target resource MUST be sent
in an encapsulated response.Media TypesMedia types are used to identify encapsulated requests and responses.Evolution of the format of encapsulated requests and responses is supported
through the definition of new formats that are identified by new media types.message/ohttp-req Media TypeThe "message/ohttp-req" identifies an encapsulated binary HTTP request. This
is a binary format that is defined in .
Type name:
message
Subtype name:
ohttp-req
Required parameters:
N/A
Optional parameters:
None
Encoding considerations:
only "8bit" or "binary" is permitted
Security considerations:
see
Interoperability considerations:
N/A
Published specification:
this specification
Applications that use this media type:
N/A
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:
IESG
message/ohttp-res Media TypeThe "message/ohttp-res" identifies an encapsulated binary HTTP response. This
is a binary format that is defined in .
Type name:
message
Subtype name:
ohttp-res
Required parameters:
N/A
Optional parameters:
None
Encoding considerations:
only "8bit" or "binary" is permitted
Security considerations:
see
Interoperability considerations:
N/A
Published specification:
this specification
Applications that use this media type:
N/A
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:
IESG
Security ConsiderationsIn this design, a client wishes to make a request of a server that is
authoritative for the oblivious target resource. The client wishes to make this
request without linking that request with either:
The identity at the network and transport layer of the client (that is, the
client IP address and TCP or UDP port number the client uses to create a
connection).
Any other request the client might have made in the past or might make in
the future.
In order to ensure this, the client selects a proxy (that serves the oblivious
proxy resource) that it trusts will protect this information by forwarding the
encapsulated request and response without passing the server (that serves the
oblivious request resource).In this section, a deployment where there are three entities is considered:
A client makes requests and receives responses
A proxy operates the oblivious proxy resource
A server operates both the oblivious request resource and the oblivious
target resource
To achieve the stated privacy goals, the oblivious proxy resource cannot be
operated by the same entity as the oblivious request resource. However,
colocation of the oblivious request resource and oblivious target resource
simplifies the interactions between those resources without affecting client
privacy.Client ResponsibilitiesClients MUST ensure that the key configuration they select for generating
encapsulated requests is integrity protected and authenticated so that it can
be attributed to the oblivious request resource; see .Clients MUST NOT include identifying information in the request that is
encapsulated.Clients cannot carry connection-level state between requests as they only
establish direct connections to the proxy responsible for the oblivious proxy
resource. However, clients need to ensure that they construct requests without
any information gained from previous requests. Otherwise, the server might be
able to use that information to link requests. Cookies are
the most obvious feature that MUST NOT be used by clients. However, clients
need to include all information learned from requests, which could include the
identity of resources.Clients MUST generate a new HPKE context for every request, using a good source
of entropy () for generating keys. Key reuse not only risks
requests being linked, reuse could expose request and response contents to the
proxy.The request the client sends to the oblivious proxy resource only requires
minimal information; see . The request that carries the
encapsulated request and is sent to the oblivious proxy resource MUST NOT
include identifying information unless the client ensures that this information
is removed by the proxy. A client MAY include information only for the
oblivious proxy resource in header fields identified by the Connection header
field if it trusts the proxy to remove these as required by Section 7.6.1 of
. The client needs to trust that the proxy does not replicate the
source addressing information in the request it forwards.Clients rely on the oblivious proxy resource to forward encapsulated requests
and responses. However, the proxy can only refuse to forward messages, it
cannot inspect or modify the contents of encapsulated requests or responses.Proxy ResponsibilitiesThe proxy that serves the oblivious proxy resource has a very simple function
to perform. For each request it receives, it makes a request of the oblivious
request resource that includes the same content. When it receives a response,
it sends a response to the client that includes the content of the response
from the oblivious request resource. When generating a request, the proxy MUST
follow the forwarding rules in .A proxy can also generate responses, though it assumed to not be able to
examine the content of a request (other than to observe the choice of key
identifier, KDF, and AEAD), so it is also assumed that it cannot generate an
encapsulated response.A proxy MUST NOT add information about the client identity when forwarding
requests. This includes the Via field, the Forwarded field
, and any similar information.Denial of ServiceAs there are privacy benefits from having a large rate of requests forwarded by
the same proxy (see ), servers that operate the oblivious request
resource might need an arrangement with proxies. This arrangement might be
necessary to prevent having the large volume of requests being classified as an
attack by the server.If a server accepts a larger volume of requests from a proxy, it needs to
trust that the proxy does not allow abusive levels of request volumes from
clients. That is, if a server allows requests from the proxy to be exempt from
rate limits, the server might want to ensure that the proxy applies a rate
limiting policy that is acceptable to the server.Servers that enter into an agreement with a proxy that enables a higher request
rate might choose to authenticate the proxy to enable the higher rate.Linkability Through Traffic AnalysisAs the time at which encapsulated request or response messages are sent can
reveal information to a network observer. Though messages exchanged between the
oblivious proxy resource and the oblivious request resource might be sent in a
single connection, traffic analysis could be used to match messages that are
forwarded by the proxy.A proxy could, as part of its function, add delays in order to increase the
anonymity set into which each message is attributed. This could latency to the
overall time clients take to receive a response, which might not be what some
clients want.A proxy can use padding to reduce the effectiveness of traffic analysis.A proxy that forwards large volumes of exchanges can provide better privacy by
providing larger sets of messages that need to be matched.Server ResponsibilitiesA server that operates both oblivious request and oblivious target resources is
responsible for removing request encapsulation, generating a response the
encapsulated request, and encapsulating the response.Servers should account for traffic analysis based on response size or generation time.
Techniques such as padding or timing delays can help protect against such attacks;
see .If separate entities provide the oblivious request resource and oblivious
target resource, these entities might need an arrangement similar to that
between server and proxy for managing denial of service; see . It is
also necessary to provide confidentiality protection for the unprotected
requests and responses, plus protections for traffic analysis; see .An oblivious request resource needs to have a plan for replacing keys. This
might include regular replacement of keys, which can be assigned new key
identifiers. If an oblivious request resource receives a request that contains
a key identifier that it does not understand or that corresponds to a key that
has been replaced, the server can respond with an HTTP 422 (Unprocessable
Content) status code.A server can also use a 422 status code if the server has a key that
corresponds to the key identifier, but the encapsulated request cannot be
successfully decrypted using the key.Replay AttacksEncapsulated requests can be copied and replayed by the oblivious proxy
resource. The design of oblivious HTTP does not assume that the oblivious proxy
resource will not replay requests. In addition, if a client sends an
encapsulated request in TLS early data (see and
), a network-based adversary might be able to cause the request to
be replayed. In both cases, the effect of a replay attack and the mitigations
that might be employed are similar to TLS early data.A client or oblivious proxy resource MUST NOT automatically attempt to retry a
failed request unless it receives a positive signal indicating that the request
was not processed or forwarded. The HTTP/2 REFUSED_STREAM error code (Section
8.1.4 of ), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1
of ), or a GOAWAY frame (in either protocol
version) are all sufficient signals that no processing occurred. Connection
failures or interruptions are not sufficient signals that no processing
occurred.The anti-replay mechanisms described in are generally
applicable to oblivious HTTP requests. Servers can use the encapsulated keying
material as a unique key for identifying potential replays.The mechanism used in TLS for managing differences in client and server clocks
cannot be used as it depends on being able to observe previous interactions.
Oblivious HTTP explicitly prevents such linkability.
Applications can still include an explicit indication of time to limit the span
of time over which a server might need to track accepted requests. Clock
information could be used for client identification, so reduction in precision
or obfuscation might be necessary.The considerations in as they relate to managing the risk of
replay also apply, though there is no option to delay the processing of a
request.Limiting requests to those with safe methods might not be satisfactory for some
applications, particularly those that involve the submission of data to a
server. The use of idempotent methods might be of some use in managing replay
risk, though it is important to recognize that different idempotent requests
can be combined to be not idempotent.Idempotent actions with a narrow scope based on the value of a protected nonce
could enable data submission with limited replay exposure. A nonce might be
added as an explicit part of a request, or, if the oblivious request and target
resources are co-located, the encapsulated keying material can be used to
produce a nonce.The server-chosen response_nonce field ensures that responses have unique
AEAD keys and nonces even when requests are replayed.Post-Compromise SecurityThis design does not provide post-compromise security for responses. A client
only needs to retain keying material that might be used compromise the
confidentiality and integrity of a response until that response is consumed, so
there is negligible risk associated with a client compromise.A server retains a secret key that might be used to remove protection from messages
over much longer periods. A server compromise that provided access to the
oblivious request resource secret key could allow an attacker to recover the
plaintext of all requests sent toward affected keys and all of the responses
that were generated. Accessing requests and responses also requires access to
requests and responses, which implies either compromise of TLS connections or
collusion with the oblivious proxy resource.The total number of affected messages affected by server key compromise can be
limited by regular rotation of server keys.Privacy ConsiderationsOne goal of this design is that independent client requests are only linkable
by the chosen key configuration. The oblivious proxy and request resources can link
requests using the same key configuration by matching KeyConfig.key_id, or, if
the oblivious target resource is willing to use trial decryption, a limited set
of key configurations that share an identifier. An oblivious proxy can link
requests using the public key corresponding to KeyConfig.key_id.Request resources are capable of linking requests depending on how KeyConfigs
are produced by servers and discovered by clients. Specifically, servers can
maliciously construct key configurations to track individual clients. A specific
method for a client to acquire key configurations is not included in this
specification. Clients need to consider these tracking vectors when choosing a
discovery method. Applications using this design should provide accommodations
to mitigate tracking.IANA ConsiderationsPlease update the "Media Types" registry at
https://www.iana.org/assignments/media-types with the registration
information in for the media types "message/ohttp-req",
"message/ohttp-res", and "application/ohttp-keys".ReferencesNormative ReferencesBinary Representation of HTTP MessagesMozillaHTTP SemanticsAdobeFastlygreenbytes GmbH 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 obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
QUIC: A UDP-Based Multiplexed and Secure TransportFastlyMozilla 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.
DO NOT DEPLOY THIS VERSION OF QUIC
DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
archived at https://mailarchive.ietf.org/arch/search/?email_list=quic
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-transport.
The Transport Layer Security (TLS) Protocol Version 1.3This 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.Hybrid Public Key EncryptionCiscoInriaInriaCloudflare This document describes a scheme for hybrid public-key encryption
(HPKE). This scheme provides authenticated public key encryption of
arbitrary-sized plaintexts for a recipient public key. HPKE works
for any combination of an asymmetric key encapsulation mechanism
(KEM), key derivation function (KDF), and authenticated encryption
with additional data (AEAD) encryption function. We provide
instantiations of the scheme using widely used and efficient
primitives, such as Elliptic Curve Diffie-Hellman key agreement,
HKDF, and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG)
in the IRTF.
Key words for use in RFCs to Indicate Requirement LevelsIn 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.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Using Early Data in HTTPUsing TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.Hypertext Transfer Protocol Version 2 (HTTP/2)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 perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.Hypertext Transfer Protocol Version 3 (HTTP/3)Akamai 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.
DO NOT DEPLOY THIS VERSION OF HTTP
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/search/?email_list=quic.
Working Group information can be found at https://github.com/quicwg;
source code and issues list for this draft can be found at
https://github.com/quicwg/base-drafts/labels/-http.
Informative ReferencesTor: The Second-Generation Onion RouterPrio: Private, Robust, and Scalable Computation of Aggregate StatisticsHTTP State Management MechanismThis document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]HTTP SemanticsAdobeFastlygreenbytes GmbH 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 obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC
7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
HTTP Alternative ServicesThis document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.HTTP Alternative ServicesThis document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.HTTP State Management MechanismThis document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. [STANDARDS-TRACK]Randomness Requirements for SecuritySecurity systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Forwarded HTTP ExtensionThis document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.Elliptic Curves for SecurityThis memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.Oblivious DNS Over HTTPSApple Inc.FastlyApple Inc.Cloudflare This document describes an extension to DNS Over HTTPS (DoH) that
allows hiding client IP addresses via proxying encrypted DNS
transactions. This improves privacy of DNS operations by not
allowing any one server entity to be aware of both the client IP
address and the content of DNS queries and answers.
Complete Example of a Request and ResponseA single request and response exchange is shown here. Binary values (key
configuration, secret keys, the content of messages, and intermediate values)
are shown in hexadecimal. The request and response here are absolutely minimal;
the purpose of this example is to show the cryptographic operations.The oblivious request resource generates a key pair. In this example the server
chooses DHKEM(X25519, HKDF-SHA256) and generates an X25519 key pair
. The X25519 secret key is:The oblivious request resource constructs a key configuration that includes the
corresponding public key as follows:This key configuration is somehow obtained by the client. Then when a client
wishes to send an HTTP request of a GET request to https://example.com, it
constructs the following binary HTTP message:The client then reads the oblivious request resource key configuration and
selects a mutually supported KDF and AEAD. In this example, the client selects
HKDF-SHA256 and AES-128-GCM. The client then generates an HPKE context that
uses the server public key. This results in the following encapsulated key:The corresponding private key is:Applying the Seal operation from the HPKE context produces an encrypted
message, allowing the client to construct the following encapsulated request:The client then sends this to the oblivious proxy resource in a POST request,
which might look like the following HTTP/1.1 request:
]]>The oblivious proxy resource receives this request and forwards it to the
oblivious request resource, which might look like:
]]>The oblivous request resource receives this request, selects the key it
generated previously using the key identifier from the message, and decrypts
the message. As this request is directed to the same server, the oblivious
request resource does not need to initiate an HTTP request to the oblivious
target resource. The request can be served directly by the oblivious target
resource, which generates a minimal response (consisting of just a 200 status
code) as follows:The response is constructed by extracting a secret from the HPKE context:The key derivation for the encapsulated response uses both the encapsulated KEM
key from the request and a randomly selected nonce. This produces a salt of:The salt and secret are both passed to the Extract function of the selected KDF
(HKDF-SHA256) to produce a pseudorandom key of:The pseudorandom key is used with the Expand function of the KDF and an info
field of "key" to produce a 16-byte key for the selected AEAD (AES-128-GCM):With the same KDF and pseudorandom key, an info field of "nonce" is used to
generate a 12-byte nonce:The AEAD Seal function is then used to encrypt the response, which is added
to the randomized nonce value to produce the encapsulated response:The oblivious request resource then constructs a response:
]]>The same response might then be generated by the oblivious proxy resource which
might change as little as the Date header. The client is then able to use the
HPKE context it created and the nonce from the encapsulated response to
construct the AEAD key and nonce and decrypt the response.AcknowledgmentsThis design is based on a design for oblivious DoH, described in
. Eric Rescorla helped unify the
structure of the key format.