Oblivious HTTP
RFC 9458
| Document | Type |
RFC
- Proposed Standard
(January 2024)
Errata
Was
draft-ietf-ohai-ohttp
(ohai WG)
|
|
|---|---|---|---|
| Authors | Martin Thomson , Christopher A. Wood | ||
| Last updated | 2024-01-25 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Murray Kucherawy | |
| Send notices to | (None) |
RFC 9458
Network Working Group T. Ylonen
Request for Comments: 4251 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Protocol Architecture
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Secure Shell (SSH) Protocol is a protocol for secure remote login
and other secure network services over an insecure network. This
document describes the architecture of the SSH protocol, as well as
the notation and terminology used in SSH protocol documents. It also
discusses the SSH algorithm naming system that allows local
extensions. The SSH protocol consists of three major components: The
Transport Layer Protocol provides server authentication,
confidentiality, and integrity with perfect forward secrecy. The
User Authentication Protocol authenticates the client to the server.
The Connection Protocol multiplexes the encrypted tunnel into several
logical channels. Details of these protocols are described in
separate documents.
Ylonen & Lonvick Standards Track [Page 1]
RFC 4251 SSH Protocol Architecture January 2006
Table of Contents
1. Introduction ....................................................3
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................4
4. Architecture ....................................................4
4.1. Host Keys ..................................................4
4.2. Extensibility ..............................................6
4.3. Policy Issues ..............................................6
4.4. Security Properties ........................................7
4.5. Localization and Character Set Support .....................7
5. Data Type Representations Used in the SSH Protocols .............8
6. Algorithm and Method Naming ....................................10
7. Message Numbers ................................................11
8. IANA Considerations ............................................12
9. Security Considerations ........................................13
9.1. Pseudo-Random Number Generation ...........................13
9.2. Control Character Filtering ...............................14
9.3. Transport .................................................14
9.3.1. Confidentiality ....................................14
9.3.2. Data Integrity .....................................16
9.3.3. Replay .............................................16
9.3.4. Man-in-the-middle ..................................17
9.3.5. Denial of Service ..................................19
9.3.6. Covert Channels ....................................20
9.3.7. Forward Secrecy ....................................20
9.3.8. Ordering of Key Exchange Methods ...................20
9.3.9. Traffic Analysis ...................................21
9.4. Authentication Protocol ...................................21
9.4.1. Weak Transport .....................................21
9.4.2. Debug Messages .....................................22
9.4.3. Local Security Policy ..............................22
9.4.4. Public Key Authentication ..........................23
9.4.5. Password Authentication ............................23
9.4.6. Host-Based Authentication ..........................23
9.5. Connection Protocol .......................................24
9.5.1. End Point Security .................................24
9.5.2. Proxy Forwarding ...................................24
9.5.3. X11 Forwarding .....................................24
10. References ....................................................26
10.1. Normative References .....................................26
10.2. Informative References ...................................26
Authors' Addresses ................................................29
Trademark Notice ..................................................29
Ylonen & Lonvick Standards Track [Page 2]
RFC 4251 SSH Protocol Architecture January 2006
1. Introduction
Secure Shell (SSH) is a protocol for secure remote login and other
secure network services over an insecure network. It consists of
three major components:
o The Transport Layer Protocol [SSH-TRANS] provides server
authentication, confidentiality, and integrity. It may optionally
also provide compression. The transport layer will typically be
run over a TCP/IP connection, but might also be used on top of any
other reliable data stream.
o The User Authentication Protocol [SSH-USERAUTH] authenticates the
client-side user to the server. It runs over the transport layer
protocol.
o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted
tunnel into several logical channels. It runs over the user
authentication protocol.
The client sends a service request once a secure transport layer
connection has been established. A second service request is sent
after user authentication is complete. This allows new protocols to
be defined and coexist with the protocols listed above.
The connection protocol provides channels that can be used for a wide
range of purposes. Standard methods are provided for setting up
secure interactive shell sessions and for forwarding ("tunneling")
arbitrary TCP/IP ports and X11 connections.
2. Contributors
The major original contributors of this set of documents have been:
Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH
Communications Security Corp), and Markku-Juhani O. Saarinen
(University of Jyvaskyla). Darren Moffat was the original editor of
this set of documents and also made very substantial contributions.
Many people contributed to the development of this document over the
years. People who should be acknowledged include Mats Andersson, Ben
Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller,
Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff
Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph
Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas
Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon
Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and
Tadayoshi Kohno. Listing their names here does not mean that they
endorse this document, but that they have contributed to it.
Ylonen & Lonvick Standards Track [Page 3]
RFC 4251 SSH Protocol Architecture January 2006
3. Conventions Used in This Document
All documents related to the SSH protocols shall use the keywords
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe
requirements. These keywords are to be interpreted as described in
[RFC2119].
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
this document when used to describe namespace allocation are to be
interpreted as described in [RFC2434].
Protocol fields and possible values to fill them are defined in this
set of documents. Protocol fields will be defined in the message
definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as
follows.
byte SSH_MSG_CHANNEL_DATA
uint32 recipient channel
string data
Throughout these documents, when the fields are referenced, they will
appear within single quotes. When values to fill those fields are
referenced, they will appear within double quotes. Using the above
example, possible values for 'data' are "foo" and "bar".
4. Architecture
4.1. Host Keys
Each server host SHOULD have a host key. Hosts MAY have multiple
host keys using multiple different algorithms. Multiple hosts MAY
share the same host key. If a host has keys at all, it MUST have at
least one key that uses each REQUIRED public key algorithm (DSS
[FIPS-186-2]).
The server host key is used during key exchange to verify that the
client is really talking to the correct server. For this to be
possible, the client must have a priori knowledge of the server<----------------+ | |
| | | |
Figure 1: Overview of Oblivious HTTP
In order to forward a request for a Target Resource to the Oblivious
Gateway Resource, the following steps occur, as shown in Figure 1:
1. The Client constructs an HTTP request for a Target Resource.
2. The Client encodes the HTTP request in a binary HTTP message and
then encapsulates that message using HPKE and the process from
Section 4.3.
3. The Client sends a POST request to the Oblivious Relay Resource
with the Encapsulated Request as the content of that message.
4. The Oblivious Relay Resource forwards this request to the
Oblivious Gateway Resource.
5. The Oblivious Gateway Resource receives this request and removes
the HPKE protection to obtain an HTTP request.
The Oblivious Gateway Resource then handles the HTTP request. This
typically involves making an HTTP request using the content of the
Encapsulated Request. Once the Oblivious Gateway Resource has an
HTTP response for this request, the following steps occur to return
this response to the Client:
1. The Oblivious Gateway Resource encapsulates the HTTP response
following the process in Section 4.4 and sends this in response
to the request from the Oblivious Relay Resource.
2. The Oblivious Relay Resource forwards this response to the
Client.
3. The Client removes the encapsulation to obtain the response to
the original request.
This interaction provides authentication and confidentiality
protection between the Client and the Oblivious Gateway, but
importantly not between the Client and the Target Resource. While
the Target Resource is a distinct HTTP resource from the Oblivious
Gateway Resource, they are both logically under the control of the
Oblivious Gateway, since the Oblivious Gateway Resource can
unilaterally dictate the responses returned from the Target Resource
to the Client. This arrangement is shown in Figure 1.
2.1. Applicability
Oblivious HTTP has limited applicability. Importantly, it requires
explicit support from a willing Oblivious Relay Resource and
Oblivious Gateway Resource, thereby limiting the use of Oblivious
HTTP for generic applications; see Section 6.3 for more information.
Many uses of HTTP benefit from being able to carry state between
requests, such as with cookies [COOKIES], authentication (Section 11
of [HTTP]), or even alternative services [RFC7838]. Oblivious HTTP
removes linkage at the transport layer, which is only useful for an
application that does not carry state between requests.
Oblivious HTTP is primarily useful where the privacy risks associated
with possible stateful treatment of requests are sufficiently large
that the cost of deploying this protocol can be justified. Oblivious
HTTP is simpler and less costly than more robust systems, like Prio
[PRIO] or Tor [DMS2004], 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 request requires at least two regular HTTP requests, which
could increase latency.
* Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and Authenticated Encryption with
Associated Data (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.
These are examples of requests where there is information in a
request that -- if it were connected to the identity of the user --
might allow a server to learn something about that user even if the
identity of the user were pseudonymous. Other examples include
submitting anonymous surveys, making search queries, or requesting
location-specific content (such as retrieving tiles of a map
display).
In addition to these limitations, Section 6 describes operational
constraints that are necessary to realize the goals of the protocol.
2.2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses terminology from [HTTP] and defines several terms
as follows:
Client:
A Client originates Oblivious HTTP requests. A Client is also an
HTTP client in two ways: for the Target Resource and for the
Oblivious Relay Resource. However, when referring to the HTTP
definition of client (Section 3.3 of [HTTP]), the term "HTTP
client" is used; see Section 5.
Encapsulated Request:
An HTTP request that is encapsulated in an HPKE-encrypted message;
see Section 4.3.
Encapsulated Response:
An HTTP response that is encapsulated in an HPKE-encrypted
message; see Section 4.4.
Oblivious Relay Resource:
An intermediary that forwards Encapsulated Requests and Responses
between Clients and a single Oblivious Gateway Resource. In
context, this can be referred to simply as a "relay".
Oblivious Gateway Resource:
A resource that can receive an Encapsulated Request, extract the
contents of that request, forward it to a Target Resource, receive
a response, encapsulate that response, and then return the
resulting Encapsulated Response. In context, this can be referred
to simply as a "gateway".
Target Resource:
The resource that is the target of an Encapsulated Request. This
resource logically handles only regular HTTP requests and
responses, so it might be ignorant of the use of Oblivious HTTP to
reach it.
This document includes pseudocode that uses the functions and
conventions defined in [HPKE].
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. ASCII [ASCII] encoding of a string
s is indicated using the function encode_str(s).
Formats are described using notation from Section 1.3 of [QUIC]. An
extension to that notation expresses the number of bits in a field
using a simple mathematical function.
3. Key Configuration
A Client needs to acquire information about the key configuration of
the Oblivious Gateway 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 does not define how that acquisition occurs. However,
in order to help facilitate interoperability, it does specify a
format for the keys. This ensures that different Client
implementations can be configured in the same way and also enables
advertising key configurations in a consistent format. This format
might be used, for example, with HTTPS, as part of a system for
configuring or discovering key configurations. However, note that
such a system needs to consider the potential for key configuration
to be used to compromise Client privacy; see Section 7.
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 the Key Derivation Function (KDF) and AEAD in this decision.
3.1. Key Configuration Encoding
A single key configuration consists of a key identifier, a public
key, an identifier for the KEM that the public key uses, and a set of
HPKE symmetric algorithms. Each symmetric algorithm consists of an
identifier for a KDF and an identifier for an AEAD.
Figure 2 shows a single key configuration.
HPKE Symmetric Algorithms {
HPKE KDF ID (16),
HPKE AEAD ID (16),
}
Key Config {
Key Identifier (8),
HPKE KEM ID (16),
HPKE Public Key (Npk * 8),
HPKE Symmetric Algorithms Length (16) = 4..65532,
HPKE Symmetric Algorithms (32) ...,
}
Figure 2: A Single Key Configuration
That is, a key configuration consists of the following fields:
Key Identifier:
An 8-bit value that identifies the key used by the Oblivious
Gateway Resource.
HPKE KEM ID:
A 16-bit value that identifies the KEM used for the identified key
as defined in Section 7.1 of [HPKE] or the "HPKE KEM Identifiers"
registry <https://www.iana.org/assignments/hpke>.
HPKE Public Key:
The public key used by the gateway. The length of the public key
is Npk, which is determined by the choice of HPKE KEM as defined
in Section 4 of [HPKE].
HPKE Symmetric Algorithms Length:
A 16-bit integer in network byte order that encodes the length, in
bytes, of the HPKE Symmetric Algorithms field that follows.
HPKE Symmetric Algorithms:
One or more pairs of identifiers for the different combinations of
HPKE KDF and AEAD that the Oblivious Gateway Resource supports:
HPKE KDF ID:
A 16-bit HPKE KDF identifier as defined in Section 7.2 of
[HPKE] or the "HPKE KDF Identifiers" registry
<https://www.iana.org/assignments/hpke>.
HPKE AEAD ID:
A 16-bit HPKE AEAD identifier as defined in Section 7.3 of
[HPKE] or the "HPKE AEAD Identifiers" registry
<https://www.iana.org/assignments/hpke>.
3.2. Key Configuration Media Type
The "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
Section 3.1). Each encoded configuration is prefixed with a 2-byte
integer in network byte order that indicates the length of the key
configuration in bytes. The length-prefixed encodings are
concatenated to form a list. See Section 9.1 for a definition of the
media type.
Evolution of the key configuration format is supported through the
definition of new formats that are identified by new media types.
A Client that receives an "application/ohttp-keys" object with
encoding errors might be able to recover one or more key
configurations. Differences in how key configurations are recovered
might be exploited to segregate Clients, so Clients MUST discard
incorrectly encoded key configuration collections.
4. HPKE Encapsulation
This document defines how a binary-encoded HTTP message [BINARY] is
encapsulated using HPKE [HPKE]. Separate media types are defined to
distinguish request and response messages:
* An Encapsulated Request format defined in Section 4.1 is
identified by the "message/ohttp-req" media type (Section 9.2).
* An Encapsulated Response format defined in Section 4.2 is
identified by the "message/ohttp-res" media type (Section 9.3).
Alternative encapsulations or message formats are indicated using the
media type; see Sections 4.5 and 4.6.
4.1. Request Format
A message in "message/ohttp-req" format protects a binary HTTP
request message; see Figure 3.
Request {
Binary HTTP Message (..),
}
Figure 3: Plaintext Request Structure
This plaintext Request structure is encapsulated into a message in
"message/ohttp-req" form by generating an Encapsulated Request. An
Encapsulated Request comprises a key identifier; HPKE parameters for
the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or
enc); and an HPKE-protected binary HTTP request message.
An Encapsulated Request is shown in Figure 4. Section 4.3 describes
the process for constructing and processing an Encapsulated Request.
Encapsulated Request {
Key Identifier (8),
HPKE KEM ID (16),
HPKE KDF ID (16),
HPKE AEAD ID (16),
Encapsulated KEM Shared Secret (8 * Nenc),
HPKE-Protected Request (..),
}
Figure 4: Encapsulated Request
That is, an Encapsulated Request comprises a Key Identifier, an HPKE
KEM ID, an HPKE KDF ID, an HPKE AEAD ID, an Encapsulated KEM Shared
Secret, and an HPKE-Protected Request. The Key Identifier, HPKE KEM
ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in Section 3.1.
The Encapsulated KEM Shared Secret is the output of the Encap()
function for the KEM, which is Nenc bytes in length, as defined in
Section 4 of [HPKE].
4.2. Response Format
A message in "message/ohttp-res" format protects a binary HTTP
response message; see Figure 5.
Response {
Binary HTTP Message (..),
}
Figure 5: Plaintext Response Structure
This plaintext Response structure is encapsulated into a message in
"message/ohttp-res" form by generating an Encapsulated Response. An
Encapsulated Response comprises a nonce and the AEAD-protected binary
HTTP response message.
An Encapsulated Response is shown in Figure 6. Section 4.4 describes
the process for constructing and processing an Encapsulated Response.
Encapsulated Response {
Nonce (8 * max(Nn, Nk)),
AEAD-Protected Response (..),
}
Figure 6: Encapsulated Response
That is, an Encapsulated Response contains a Nonce and an AEAD-
Protected Response. The Nonce field is either Nn or Nk bytes long,
whichever is larger. The Nn and Nk values correspond to parameters
of the AEAD used in HPKE, which is defined in Section 7.3 of [HPKE]
or the "HPKE AEAD Identifiers" IANA registry
<https://www.iana.org/assignments/hpke>. Nn and Nk refer to the size
of the AEAD nonce and key, respectively, in bytes.
4.3. Encapsulation of Requests
Clients encapsulate a request, identified as request, using values
from a key configuration:
* the key identifier from the configuration (key_id) with the
corresponding KEM identified by kem_id,
* the public key from the configuration (pkR), and
* a combination of KDF (identified by kdf_id) and AEAD (identified
by aead_id) that the Client selects from those in the key
configuration.
The Client then constructs an Encapsulated Request, enc_request, from
a binary-encoded HTTP request [BINARY] (request) as follows:
1. Construct a message header (hdr) by concatenating the values of
key_id, kem_id, kdf_id, and aead_id as one 8-bit integer and
three 16-bit integers, respectively, each in network byte order.
2. Build a sequence of bytes (info) by concatenating the ASCII-
encoded string "message/bhttp request", a zero byte, and the
header. Note: Section 4.6 discusses how alternative message
formats might use a different info value.
3. Create a sending HPKE context by invoking SetupBaseS()
(Section 5.1.1 of [HPKE]) with the public key of the receiver pkR
and info. This yields the context sctxt and an encapsulation key
enc.
4. Encrypt request by invoking the Seal() method on sctxt
(Section 5.2 of [HPKE]) with empty associated data aad, yielding
ciphertext ct.
5. Concatenate the values of hdr, enc, and ct. This yields 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:
hdr = concat(encode(1, key_id),
encode(2, kem_id),
encode(2, kdf_id),
encode(2, aead_id))
info = concat(encode_str("message/bhttp request"),
encode(1, 0),
hdr)
enc, sctxt = SetupBaseS(pkR, info)
ct = sctxt.Seal("", request)
enc_request = concat(hdr, enc, ct)
An Oblivious Gateway Resource decrypts an Encapsulated Request by
reversing this process. To decapsulate an Encapsulated Request,
enc_request:
1. Parse enc_request into key_id, kem_id, kdf_id, aead_id, enc, and
ct (indicated using the function parse() in pseudocode). The
Oblivious Gateway Resource is then able to find the HPKE private
key, skR, corresponding to key_id.
a. If key_id does not identify a key matching the type of
kem_id, the Oblivious Gateway Resource returns an error.
b. If kdf_id and aead_id identify a combination of KDF and AEAD
that the Oblivious Gateway Resource is unwilling to use with
skR, the Oblivious Gateway Resource returns an error.
2. Build a sequence of bytes (info) by concatenating the ASCII-
encoded string "message/bhttp request"; a zero byte; key_id as an
8-bit integer; plus kem_id, kdf_id, and aead_id as three 16-bit
integers.
3. Create a receiving HPKE context, rctxt, by invoking SetupBaseR()
(Section 5.1.1 of [HPKE]) with skR, enc, and info.
4. Decrypt ct by invoking the Open() method on rctxt (Section 5.2 of
[HPKE]), with an empty associated data aad, yielding request or
an error on failure. If decryption fails, the Oblivious Gateway
Resource returns an error.
In pseudocode, this procedure is as follows:
key_id, kem_id, kdf_id, aead_id, enc, ct = parse(enc_request)
info = concat(encode_str("message/bhttp request"),
encode(1, 0),
encode(1, key_id),
encode(2, kem_id),
encode(2, kdf_id),
encode(2, aead_id))
rctxt = SetupBaseR(enc, skR, info)
request, error = rctxt.Open("", ct)
The Oblivious Gateway Resource retains the HPKE context, rctxt, so
that it can encapsulate a response.
4.4. Encapsulation of Responses
Oblivious Gateway Resources generate an Encapsulated Response
(enc_response) from a binary-encoded HTTP response [BINARY]
(response). The Oblivious Gateway Resource uses the HPKE receiver
context (rctxt) as the HPKE context (context) as follows:
1. Export a secret (secret) from context, using the string "message/
bhttp response" as the exporter_context parameter to
context.Export; see Section 5.3 of [HPKE]. The length of this
secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD
key and nonce that are associated with context. Note:
Section 4.6 discusses how alternative message formats might use a
different context value.
2. Generate a random value of length max(Nn, Nk) bytes, called
response_nonce.
3. 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.
4. Use the Expand function provided by the same KDF to create an
AEAD key, key, of length Nk -- the length of the keys used by the
AEAD associated with context. Generating aead_key uses a label
of "key".
5. Use the same Expand function to create a nonce, nonce, of length
Nn -- the length of the nonce used by the AEAD. Generating
aead_nonce uses a label of "nonce".
6. Encrypt response, passing the AEAD function Seal the values of
aead_key, aead_nonce, an empty aad, and a pt input of response.
This yields ct.
7. 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:
secret = context.Export("message/bhttp response", max(Nn, Nk))
response_nonce = random(max(Nn, Nk))
salt = concat(enc, response_nonce)
prk = Extract(salt, secret)
aead_key = Expand(prk, "key", Nk)
aead_nonce = Expand(prk, "nonce", Nn)
ct = Seal(aead_key, aead_nonce, "", response)
enc_response = concat(response_nonce, ct)
Clients decrypt an Encapsulated Response by reversing this process.
That is, Clients first parse enc_response into response_nonce and ct.
Then, they follow the same process to derive values for aead_key and
aead_nonce, using their sending HPKE context, sctxt, as the HPKE
context, context.
The Client uses these values to decrypt ct using the AEAD function
Open. Decrypting might produce an error, as follows:
response, error = Open(aead_key, aead_nonce, "", ct)
4.5. Request and Response Media Types
Media types are used to identify Encapsulated Requests and Responses;
see Sections 9.2 and 9.3 for definitions of these media types.
Evolution of the format of Encapsulated Requests and Responses is
supported through the definition of new formats that are identified
by new media types. New media types might be defined to use a
similar encapsulation with a different HTTP message format than in
[BINARY]; see Section 4.6 for guidance on reusing this encapsulation
method. Alternatively, a new encapsulation method might be defined.
4.6. Repurposing the Encapsulation Format
The encrypted payload of an Oblivious HTTP request and response is a
binary HTTP message [BINARY]. The Client and Oblivious Gateway
Resource agree on this encrypted payload type by specifying the media
type "message/bhttp" in the HPKE info string and HPKE export context
string for request and response encryption, respectively.
Future specifications may repurpose the encapsulation mechanism
described in this document. This requires that the specification
define a new media type. The encapsulation process for that content
type can follow the same process, using new constant strings for the
HPKE info and exporter context inputs.
For example, a future specification might encapsulate DNS messages,
which use the "application/dns-message" media type [RFC8484]. In
creating a new, encrypted media types, specifications might define
the use of string "application/dns-message request" (plus a zero byte
and the header for the full value) for request encryption and the
string "application/dns-message response" for response encryption.
5. HTTP Usage
A Client interacts with the Oblivious Relay Resource by constructing
an Encapsulated Request. This Encapsulated Request is included as
the content of a POST request to the Oblivious Relay Resource. This
request only needs those fields necessary to carry the Encapsulated
Request: a method of POST, a target URI of the Oblivious Relay
Resource, a header field containing the content type (see
Section 9.2), and the Encapsulated Request as the request content.
In the request to the Oblivious Relay Resource, Clients MAY include
additional fields. However, additional fields MUST be independent of
the Encapsulated Request and MUST be fields that the Oblivious Relay
Resource will remove before forwarding the Encapsulated Request
towards the target, such as the Connection or Proxy-Authorization
header fields [HTTP].
The Client role in this protocol acts as an HTTP client both with
respect to the Oblivious Relay Resource and the Target Resource. The
request, which the Client makes to the Target Resource, diverges from
typical HTTP assumptions about the use of a connection (see
Section 3.3 of [HTTP]) in that the request and response are encrypted
rather than sent over a connection. The Oblivious Relay Resource and
the Oblivious Gateway Resource also act as HTTP clients toward the
Oblivious Gateway Resource and Target Resource, respectively.
In order to achieve the privacy and security goals of the protocol, a
Client also needs to observe the guidance in Section 6.1.
The Oblivious Relay Resource interacts with the Oblivious Gateway
Resource as an HTTP client by constructing a request using the same
restrictions as the Client request, except that the target URI is the
Oblivious Gateway Resource. The content of this request is copied
from the Client. An Oblivious Relay Resource MAY reject requests
that are obviously invalid, such as a request with no content. The
Oblivious Relay Resource MUST NOT add information to the request
without the Client being aware of the type of information that might
be added; see Section 6.2 for more information on relay
responsibilities.
When a response is received from the Oblivious Gateway Resource, the
Oblivious Relay Resource forwards the response according to the rules
of an HTTP proxy; see Section 7.6 of [HTTP]. In case of timeout or
error, the Oblivious Relay Resource can generate a response with an
appropriate status code.
In order to achieve the privacy and security goals of the protocol,
an Oblivious Relay Resource also needs to observe the guidance in
Section 6.2.
An Oblivious Gateway Resource acts as a gateway for requests to the
Target Resource (see Section 7.6 of [HTTP]). The one exception is
that any information it might forward in a response MUST be
encapsulated, unless it is responding to errors that do not relate to
processing the contents of the Encapsulated Request; see Section 5.2.
An Oblivious Gateway Resource, if it receives any response from the
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 Gateway Resource that does not receive a response can
itself generate a response with an appropriate error status code
(such as 504 (Gateway Timeout); see Section 15.6.5 of [HTTP]), which
is then encapsulated in the same way as a successful response.
In order to achieve the privacy and security goals of the protocol,
an Oblivious Gateway Resource also needs to observe the guidance in
Section 6.3.
5.1. Informational Responses
This 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 [HTTP]) cannot be used. Clients MUST NOT construct
a request that includes a 100-continue expectation; the Oblivious
Gateway Resource MUST generate an error if a 100-continue expectation
is received.
5.2. Errors
A server that receives an invalid message for any reason MUST
generate an HTTP response with a 4xx status code.
Errors detected by the Oblivious Relay Resource and errors detected
by the Oblivious Gateway 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 Gateway Resource after successfully
removing encapsulation and errors detected by the Target Resource
MUST be sent in an Encapsulated Response. This might be because the
Encapsulated Request is malformed or the Target Resource does not
produce a response. In either case, the Oblivious Gateway Resource
can generate a response with an appropriate error status code (such
as 400 (Bad Request) or 504 (Gateway Timeout); see Sections 15.5.1
and 15.6.5 of [HTTP], respectively). This response is encapsulated
in the same way as a successful response.
Errors in the encapsulation of requests mean that responses cannot be
encapsulated. This includes cases where the key configuration is
incorrect or outdated. The Oblivious Gateway Resource can generate
and send a response with a 4xx status code to the Oblivious Relay
Resource. This response MAY be forwarded to the Client or treated by
the Oblivious Relay Resource as a failure. If a Client receives a
response that is not an Encapsulated Response, this could indicate
that the Client configuration used to construct the request is
incorrect or out of date.
5.3. Signaling Key Configuration Problems
The problem type [PROBLEM] of "https://iana.org/assignments/http-
problem-types#ohttp-key" is defined in this section. An Oblivious
Gateway Resource MAY use this problem type in a response to indicate
that an Encapsulated Request used an outdated or incorrect key
configuration.
Figure 7 shows an example response in HTTP/1.1 format.
HTTP/1.1 400 Bad Request
Date: Mon, 07 Feb 2022 00:28:05 GMT
Content-Type: application/problem+json
Content-Length: 106
{"type":"https://iana.org/assignments/http-problem-types#ohttp-key",
"title": "key identifier unknown"}
Figure 7: Example Rejection of Key Configuration
As this response cannot be encrypted, it might not reach the Client.
A Client cannot rely on the Oblivious Gateway Resource using this
problem type. A Client might also be configured to disregard
responses that are not encapsulated on the basis that they might be
subject to observation or modification by an Oblivious Relay
Resource. A Client might manage the risk of an outdated key
configuration using a heuristic approach whereby it periodically
refreshes its key configuration if it receives a response with an
error status code that has not been encapsulated.
6. Security Considerations
In this design, a Client wishes to make a request to an Oblivious
Gateway Resource that is forwarded to a Target Resource. The Client
wishes to make this request without linking that request with either
of the following:
* 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 relay (that serves the
Oblivious Relay Resource) that it trusts will protect this
information by forwarding the Encapsulated Request and Response
without passing it to the server (that serves the Oblivious Gateway
Resource).
In this section, a deployment where there are three entities is
considered:
* A Client makes requests and receives responses.
* A relay operates the Oblivious Relay Resource.
* A server operates both the Oblivious Gateway Resource and the
Target Resource.
Section 6.10 discusses the security implications for a case where
different servers operate the Oblivious Gateway Resource and Target
Resource.
Requests from the Client to Oblivious Relay Resource and from
Oblivious Relay Resource to Oblivious Gateway Resource MUST use HTTPS
in order to provide unlinkability in the presence of a network
observer.
To achieve the stated privacy goals, the Oblivious Relay Resource
cannot be operated by the same entity as the Oblivious Gateway
Resource. However, colocation of the Oblivious Gateway Resource and
Target Resource simplifies the interactions between those resources
without affecting Client privacy.
As a consequence of this configuration, Oblivious HTTP prevents
linkability described above. Informally, this means:
1. Requests and responses are known only to Clients and Oblivious
Gateway Resources. In particular, the Oblivious Relay Resource
knows the origin and destination of an Encapsulated Request and
Response, yet it does not know the decrypted contents. Likewise,
Oblivious Gateway Resources learn only the Oblivious Relay
Resource and the decrypted request. No entity other than the
Client can see the plaintext request and response and can
attribute them to the Client.
2. Oblivious Gateway Resources, and therefore Target Resources,
cannot link requests from the same Client in the absence of
unique per-Client keys.
Traffic analysis that might affect these properties is outside the
scope of this document; see Section 6.2.3.
A formal analysis of Oblivious HTTP is in [OHTTP-ANALYSIS].
6.1. Client Responsibilities
Because Clients do not authenticate the Target Resource when using
Oblivious HTTP, Clients MUST have some mechanism to authorize an
Oblivious Gateway Resource for use with a Target Resource. One
possible means of authorization is an allowlist. This ensures that
Oblivious Gateway Resources are not misused to forward traffic to
arbitrary Target Resources. Section 6.3 describes similar
responsibilities that apply to Oblivious Gateway Resources.
Clients 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 Gateway
Resource; see Section 3.
Since Clients connect directly to the Oblivious Relay Resource
instead of the Target Resource, application configurations wherein
Clients make policy decisions about target connections, e.g., to
apply certificate pinning, are incompatible with Oblivious HTTP. In
such cases, alternative technologies such as HTTP CONNECT
(Section 9.3.6 of [HTTP]) can be used. Applications could implement
related policies on key configurations and relay connections, though
these might not provide the same properties as policies enforced
directly on target connections. Instead, when this difference is
relevant, applications can connect directly to the target at the cost
of either privacy or performance.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the relay responsible for the
Oblivious Relay Resource. However, the content of requests might be
used by a server to correlate requests. Cookies [COOKIES] are the
most obvious feature that might be used to correlate requests, but
any identity information and authentication credentials might have
the same effect. Clients also need to treat information learned from
responses with similar care when constructing subsequent requests,
which includes the identity of resources.
Clients MUST generate a new HPKE context for every request, using a
good source of entropy [RANDOM] for generating keys. Key reuse not
only risks requests being linked but also could expose request and
response contents to the relay.
The request the Client sends to the Oblivious Relay Resource only
requires minimal information; see Section 5. The request that
carries the Encapsulated Request and that is sent to the Oblivious
Relay Resource MUST NOT include identifying information unless the
Client can trust that this information is removed by the relay. A
Client MAY include information only for the Oblivious Relay Resource
in header fields identified by the Connection header field if it
trusts the relay to remove these, as required by Section 7.6.1 of
[HTTP]. The Client needs to trust that the relay does not replicate
the source addressing information in the request it forwards.
Clients rely on the Oblivious Relay Resource to forward Encapsulated
Requests and Responses. However, the relay can only refuse to
forward messages; it cannot inspect or modify the contents of
Encapsulated Requests or Responses.
6.2. Relay Responsibilities
The relay that serves the Oblivious Relay Resource has a very simple
function to perform. For each request it receives, it makes a
request of the Oblivious Gateway 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
Gateway Resource.
When forwarding a request, the relay MUST follow the forwarding rules
in Section 7.6 of [HTTP]. A generic HTTP intermediary implementation
is suitable for the purposes of serving an Oblivious Relay Resource,
but additional care is needed to ensure that Client privacy is
maintained.
Firstly, a generic implementation will forward unknown fields. For
Oblivious HTTP, an Oblivious Relay Resource SHOULD NOT forward
unknown fields. Though Clients are not expected to include fields
that might contain identifying information, removing unknown fields
removes this privacy risk.
Secondly, generic implementations are often configured to augment
requests with information about the Client, such as the Via field or
the Forwarded field [FORWARDED]. A relay MUST NOT add information
when forwarding requests that might be used to identify Clients,
except for information that a Client is aware of; see Section 6.2.1.
Finally, a relay can also generate responses, though it is assumed to
not be able to examine the content of a request (other than to
observe the choice of key identifier, KDF, and AEAD); therefore, it
is also assumed that it cannot generate an Encapsulated Response.
6.2.1. Differential Treatment
A relay MAY add information to requests if the Client is aware of the
nature of the information that could be added. Any addition MUST NOT
include information that uniquely and permanently identifies the
Client, including any pseudonymous identifier. Information added by
the relay -- beyond what is already revealed through Encapsulated
Requests from Clients -- can reduce the size of the anonymity set of
Clients at a gateway.
A Client does not need to be aware of the exact value added for each
request but needs to know the range of possible values the relay
might use. How a Client might learn about added information is not
defined in this document.
Moreover, relays MAY apply differential treatment to Clients that
engage in abusive behavior, e.g., by sending too many requests in
comparison to other Clients, or as a response to rate limits signaled
from the gateway. Any such differential treatment can reveal
information to the gateway that would not be revealed otherwise and
therefore reduce the size of the anonymity set of Clients using a
gateway. For example, if a relay chooses to rate limit or block an
abusive Client, this means that any Client requests that are not
treated this way are known to be non-abusive by the gateway. Clients
need to consider the likelihood of such differential treatment and
the privacy risks when using a relay.
Some patterns of abuse cannot be detected without access to the
request that is made to the target. This means that only the gateway
or the target is in a position to identify abuse. A gateway MAY send
signals toward the relay to provide feedback about specific requests.
For example, a gateway could respond differently to requests it
cannot decapsulate, as mentioned in Section 5.2. A relay that acts
on this feedback could -- either inadvertently or by design -- lead
to Client deanonymization.
6.2.2. Denial of Service
As there are privacy benefits from having a large rate of requests
forwarded by the same relay (see Section 6.2.3), servers that operate
the Oblivious Gateway Resource might need an arrangement with
Oblivious Relay Resources. 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 relay, it
needs to trust that the relay does not allow abusive levels of
request volumes from Clients. That is, if a server allows requests
from the relay to be exempt from rate limits, the server might want
to ensure that the relay applies a rate-limiting policy that is
acceptable to the server.
Servers that enter into an agreement with a relay that enables a
higher request rate might choose to authenticate the relay to enable
the higher rate.
6.2.3. Traffic Analysis
Using HTTPS protects information about which resources are the
subject of request and prevents a network observer from being able to
trivially correlate messages on either side of a relay. However,
using HTTPS does not prevent traffic analysis by such network
observers.
The time at which Encapsulated Request or Response messages are sent
can reveal information to a network observer. Though messages
exchanged between the Oblivious Relay Resource and the Oblivious
Gateway Resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
relay.
A relay could, as part of its function, delay requests before
forwarding them. Delays might increase the anonymity set into which
each request is attributed. Any delay also increases the time that a
Client waits for a response, so delays SHOULD only be added with the
consent -- or at least awareness -- of Clients.
A relay that forwards large volumes of exchanges can provide better
privacy by providing larger sets of messages that need to be matched.
Traffic analysis is not restricted to network observers. A malicious
Oblivious Relay Resource could use traffic analysis to learn
information about otherwise encrypted requests and responses relayed
between Clients and gateways. An Oblivious Relay Resource terminates
TLS connections from Clients, so they see message boundaries. This
privileged position allows for richer feature extraction from
encrypted data, which might improve traffic analysis.
Clients and Oblivious Gateway Resources can use padding to reduce the
effectiveness of traffic analysis. Padding is a capability provided
by binary HTTP messages; see Section 3.8 of [BINARY]. If the
encapsulation method described in this document is used to protect a
different message type (see Section 4.6), that message format might
need to include padding support. Oblivious Relay Resources can also
use padding for the same reason but need to operate at the HTTP layer
since they cannot manipulate binary HTTP messages; for example, see
Section 10.7 of [HTTP/2] or Section 10.7 of [HTTP/3]).
6.3. Server Responsibilities
The Oblivious Gateway Resource can be operated by a different entity
than the Target Resource. However, this means that the Client needs
to trust the Oblivious Gateway Resource not to modify requests or
responses. This analysis concerns itself with a deployment scenario
where a single server provides both the Oblivious Gateway Resource
and Target Resource.
A server that operates both Oblivious Gateway and Target Resources is
responsible for removing request encryption, generating a response to
the Encapsulated Request, and encrypting 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 Section 6.2.3.
If separate entities provide the Oblivious Gateway Resource and
Target Resource, these entities might need an arrangement similar to
that between server and relay for managing denial of service; see
Section 6.2.2. Moreover, the Oblivious Gateway Resource SHOULD have
some mechanism to ensure that the Oblivious Gateway Resource is not
misused as a relay for HTTP messages to an arbitrary Target Resource,
such as an allowlist.
Non-secure requests -- such as those with the "http" scheme as
opposed to the "https" scheme -- SHOULD NOT be used if the Oblivious
Gateway and Target Resources are not on the same origin. If messages
are forwarded between these resources without the protections
afforded by HTTPS, they could be inspected or modified by a network
attacker. Note that a request could be forwarded without protection
if the two resources share an origin.
6.4. Key Management
An Oblivious Gateway 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 Gateway 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.
A server MUST ensure that the HPKE keys it uses are not valid for any
other protocol that uses HPKE with the "message/bhttp request" label.
Designers of protocols that reuse this encryption format, especially
new versions of this protocol, can ensure key diversity by choosing a
different label in their use of HPKE. The "message/bhttp response"
label was chosen for symmetry only as it provides key diversity only
within the HPKE context created using the "message/bhttp request's
public host key.
Two different trust models can be used:
o The client has a local database that associates each host name (as
typed by the user) with the corresponding public host key. This
method requires no centrally administered infrastructure, and no
Ylonen & Lonvick Standards Track [Page 4]
RFC 4251 SSH Protocol Architecture January 2006
third-party coordination. The downside is that the database of
name-to-key associations may become burdensome to maintain.
o The host name-to-key association is certified by a trusted
certification authority (CA). The client only knows the CA root
key, and can verify the validity of all host keys certified by
accepted CAs.
The second alternative eases the maintenance problem, since ideally
only a single CA key needs to be securely stored on the client. On
the other hand, each host key must be appropriately certified by a
central authority before authorization is possible. Also, a lot of
trust is placed on the central infrastructure.
The protocol provides the option that the server name - host key
association is not checked when connecting to the host for the first
time. This allows communication without prior communication of host
keys or certification. The connection still provides protection
against passive listening; however, it becomes vulnerable to active
man-in-the-middle attacks. Implementations SHOULD NOT normally allow
such connections by default, as they pose a potential security
problem. However, as there is no widely deployed key infrastructure
available on the Internet at the time of this writing, this option
makes the protocol much more usable during the transition time until
such an infrastructure emerges, while still providing a much higher
level of security than that offered by older solutions (e.g., telnet
[RFC0854] and rlogin [RFC1282]).
Implementations SHOULD try to make the best effort to check host
keys. An example of a possible strategy is to only accept a host key
without checking the first time a host is connected, save the key in
a local database, and compare against that key on all future
connections to that host.
Implementations MAY provide additional methods for verifying the
correctness of host keys, e.g., a hexadecimal fingerprint derived
from the SHA-1 hash [FIPS-180-2] of the public key. Such
fingerprints can easily be verified by using telephone or other
external communication channels.
All implementations SHOULD provide an option not to accept host keys
that cannot be verified.
The members of this Working Group believe that 'ease of use' is
critical to end-user acceptance of security solutions, and no
improvement in security is gained if the new solutions are not used.
Thus, providing the option not to check the server host key is
Ylonen & Lonvick Standards Track [Page 5]
RFC 4251 SSH Protocol Architecture January 2006
believed to improve the overall security of the Internet, even though
it reduces the security of the protocol in configurations where it is
allowed.
4.2. Extensibility
We believe that the protocol will evolve over time, and some
organizations will want to use their own encryption, authentication,
and/or key exchange methods. Central registration of all extensions
is cumbersome, especially for experimental or classified features.
On the other hand, having no central registration leads to conflicts
in method identifiers, making interoperability difficult.
We have chosen to identify algorithms, methods, formats, and
extension protocols with textual names that are of a specific format.
DNS names are used to create local namespaces where experimental or
classified extensions can be defined without fear of conflicts with
other implementations.
One design goal has been to keep the base protocol as simple as
possible, and to require as few algorithms as possible. However, all
implementations MUST support a minimal set of algorithms to ensure
interoperability (this does not imply that the local policy on all
hosts would necessarily allow these algorithms). The mandatory
algorithms are specified in the relevant protocol documents.
Additional algorithms, methods, formats, and extension protocols can
be defined in separate documents. See Section 6, Algorithm Naming,
for more information.
4.3. Policy Issues
The protocol allows full negotiation of encryption, integrity, key
exchange, compression, and public key algorithms and formats.
Encryption, integrity, public key, and compression algorithms can be
different for each direction.
The following policy issues SHOULD be addressed in the configuration
mechanisms of each implementation:
o Encryption, integrity, and compression algorithms, separately for
each direction. The policy MUST specify which is the preferred
algorithm (e.g., the first algorithm listed in each category).
o Public key algorithms and key exchange method to be used for host
authentication. The existence of trusted host keys for different
public key algorithms also affects this choice.
Ylonen & Lonvick Standards Track [Page 6]
RFC 4251 SSH Protocol Architecture January 2006
o The authentication methods that are to be required by the server
for each user. The server's policy MAY require multiple
authentication for some or all users. The required algorithms MAY
depend on the location from where the user is trying to gain
access.
o The operations that the user is allowed to perform using the
connection protocol. Some issues are related to security; for
example, the policy SHOULD NOT allow the server to start sessions
or run commands on the client machine, and MUST NOT allow
connections to the authentication agent unless forwarding such
connections has been requested. Other issues, such as which
TCP/IP ports can be forwarded and by whom, are clearly issues of
local policy. Many of these issues may involve traversing or
bypassing firewalls, and are interrelated with the local security
policy.
4.4. Security Properties
The primary goal of the SSH protocol is to improve security on the
Internet. It attempts to do this in a way that is easy to deploy,
even at the cost of absolute security.
o All encryption, integrity, and public key algorithms used are
well-known, well-established algorithms.
o All algorithms are used with cryptographically sound key sizes
that are believed to provide protection against even the strongest
cryptanalytic attacks for decades.
o All algorithms are negotiated, and in case some algorithm is
broken, it is easy to switch to some other algorithm without
modifying the base protocol.
Specific concessions were made to make widespread, fast deployment
easier. The particular case where this comes up is verifying that
the server host key really belongs to the desired host; the protocol
allows the verification to be left out, but this is NOT RECOMMENDED.
This is believed to significantly improve usability in the short
term, until widespread Internet public key infrastructures emerge.
4.5. Localization and Character Set Support
For the most part, the SSH protocols do not directly pass text that
would be displayed to the user. However, there are some places where
such data might be passed. When applicable, the character set for
Ylonen & Lonvick Standards Track [Page 7]
RFC 4251 SSH Protocol Architecture January 2006
the data MUST be explicitly specified. In most places, ISO-10646
UTF-8 encoding is used [RFC3629]. When applicable, a field is also
provided for a language tag [RFC3066].
One big issue is the character set of the interactive session. There
is no clear solution, as different applications may display data in
different formats. Different types of terminal emulation may also be
employed in the client, and the character set to be used is
effectively determined by the terminal emulation. Thus, no place is
provided for directly specifying the character set or encoding for
terminal session data. However, the terminal emulation type (e.g.,
"vt100") is transmitted to the remote site, and it implicitly
specifies the character set and encoding. Applications typically use
the terminal type to determine what character set they use, or the
character set is determined using some external means. The terminal
emulation may also allow configuring the default character set. In
any case, the character set for the terminal session is considered
primarily a client local issue.
Internal names used to identify algorithms or protocols are normally
never displayed to users, and must be in US-ASCII.
The client and server user names are inherently constrained by what
the server is prepared to accept. They might, however, occasionally
be displayed in logs, reports, etc. They MUST be encoded using ISO
10646 UTF-8, but other encodings may be required in some cases. It
is up to the server to decide how to map user names to accepted user
names. Straight bit-wise, binary comparison is RECOMMENDED.
For localization purposes, the protocol attempts to minimize the
number of textual messages transmitted. When present, such messages
typically relate to errors, debugging information, or some externally
configured data. For data that is normally displayed, it SHOULD be
possible to fetch a localized message instead of the transmitted
message by using a numerical code. The remaining messages SHOULD be
configurable.
5. Data Type Representations Used in the SSH Protocols
byte
A byte represents an arbitrary 8-bit value (octet). Fixed length
data is sometimes represented as an array of bytes, written
byte[n], where n is the number of bytes in the array.
Ylonen & Lonvick Standards Track [Page 8]
RFC 4251 SSH Protocol Architecture January 2006
boolean
A boolean value is stored as a single byte. The value 0
represents FALSE, and the value 1 represents TRUE. All non-zero
values MUST be interpreted as TRUE; however, applications MUST NOT
store values other than 0 and 1.
uint32
Represents a 32-bit unsigned integer. Stored as four bytes in the
order of decreasing significance (network byte order). For
example: the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4
aa.
uint64
Represents a 64-bit unsigned integer. Stored as eight bytes in
the order of decreasing significance (network byte order).
string
Arbitrary length binary string. Strings are allowed to contain
arbitrary binary data, including null characters and 8-bit
characters. They are stored as a uint32 containing its length
(number of bytes that follow) and zero (= empty string) or more
bytes that are the value of the string. Terminating null
characters are not used.
Strings are also used to store text. In that case, US-ASCII is
used for internal names, and ISO-10646 UTF-8 for text that might
be displayed to the user. The terminating null character SHOULD
NOT normally be stored in the string. For example: the US-ASCII
string "testing" is represented as 00 00 00 07 t e s t i n g. The
UTF-8 mapping does not alter the encoding of US-ASCII characters.
mpint
Represents multiple precision integers in two's complement format,
stored as a string, 8 bits per byte, MSB first. Negative numbers
have the value 1 as the most significant bit of the first byte of
the data partition. If the most significant bit would be set for
a positive number, the number MUST be preceded by a zero byte.
Unnecessary leading bytes with the value 0 or 255 MUST NOT be
included. The value zero MUST be stored as a string with zero
bytes of data.
By convention, a number that is used in modular computations in
Z_n SHOULD be represented in the range 0 <= x < n.
Ylonen & Lonvick Standards Track [Page 9]
RFC 4251 SSH Protocol Architecture January 2006
Examples:
value (hex) representation (hex)
----------- --------------------
0 00 00 00 00
9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7
80 00 00 00 02 00 80
-1234 00 00 00 02 ed cc
-deadbeef 00 00 00 05 ff 21 52 41 11
name-list
A string containing a comma-separated list of names. A name-list
is represented as a uint32 containing its length (number of bytes
that follow) followed by a comma-separated list of zero or more
names. A name MUST have a non-zero length, and it MUST NOT
contain a comma (","). As this is a list of names, all of the
elements contained are names and MUST be in US-ASCII. Context may
impose additional restrictions on the names. For example, the
names in a name-list may have to be a list of valid algorithm
identifiers (see Section 6 below), or a list of [RFC3066] language
tags. The order of the names in a name-list may or may not be
significant. Again, this depends on the context in which the list
is used. Terminating null characters MUST NOT be used, neither
for the individual names, nor for the list as a whole.
Examples:
value representation (hex)
----- --------------------
(), the empty name-list 00 00 00 00
("zlib") 00 00 00 04 7a 6c 69 62
("zlib,none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
6. Algorithm and Method Naming
The SSH protocols refer to particular hash, encryption, integrity,
compression, and key exchange algorithms or methods by name. There
are some standard algorithms and methods that all implementations
MUST support. There are also algorithms and methods that are defined
in the protocol specification, but are OPTIONAL. Furthermore, it is
expected that some organizations will want to use their own
algorithms or methods.
In this protocol, all algorithm and method identifiers MUST be
printable US-ASCII, non-empty strings no longer than 64 characters.
Names MUST be case-sensitive.
Ylonen & Lonvick Standards Track [Page 10]
RFC 4251 SSH Protocol Architecture January 2006
There are two formats for algorithm and method names:
o Names that do not contain an at-sign ("@") are reserved to be
assigned by IETF CONSENSUS. Examples include "3des-cbc", "sha-1",
"hmac-sha1", and "zlib" (the doublequotes are not part of the
name). Names of this format are only valid if they are first
registered with the IANA. Registered names MUST NOT contain an
at-sign ("@"), comma (","), whitespace, control characters (ASCII
codes 32 or less), or the ASCII code 127 (DEL). Names are case-
sensitive, and MUST NOT be longer than 64 characters.
o Anyone can define additional algorithms or methods by using names
in the format name@domainname, e.g., "ourcipher-cbc@example.com".
The format of the part preceding the at-sign is not specified;
however, these names MUST be printable US-ASCII strings, and MUST
NOT contain the comma character (","), whitespace, control
characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
They MUST have only a single at-sign in them. The part following
the at-sign MUST be a valid, fully qualified domain name [RFC1034]
controlled by the person or organization defining the name. Names
are case-sensitive, and MUST NOT be longer than 64 characters. It
is up to each domain how it manages its local namespace. It
should be noted that these names resemble STD 11 [RFC0822] email
addresses. This is purely coincidental and has nothing to do with
STD 11 [RFC0822].
7. Message Numbers
SSH packets have message numbers in the range 1 to 255. These
numbers have been allocated as follows:
Transport layer protocol:
1 to 19 Transport layer generic (e.g., disconnect, ignore,
debug, etc.)
20 to 29 Algorithm negotiation
30 to 49 Key exchange method specific (numbers can be reused
for different authentication methods)
User authentication protocol:
50 to 59 User authentication generic
60 to 79 User authentication method specific (numbers can be
reused for different authentication methods)
Ylonen & Lonvick Standards Track [Page 11]
RFC 4251 SSH Protocol Architecture January 2006
Connection protocol:
80 to 89 Connection protocol generic
90 to 127 Channel related messages
Reserved for client protocols:
128 to 191 Reserved
Local extensions:
192 to 255 Local extensions
8. IANA Considerations
This document is part of a set. The instructions for the IANA for
the SSH protocol, as defined in this document, [SSH-USERAUTH],
[SSH-TRANS], and [SSH-CONNECT], are detailed in [SSH-NUMBERS]. The
following is a brief summary for convenience, but note well that
[SSH-NUMBERS] contains the actual instructions to the IANA, which may
be superseded in the future.
Allocation of the following types of names in the SSH protocols is
assigned by IETF consensus:
o Service Names
* Authentication Methods
* Connection Protocol Channel Names
* Connection Protocol Global Request Names
* Connection Protocol Channel Request Names
o Key Exchange Method Names
o Assigned Algorithm Names
* Encryption Algorithm Names
* MAC Algorithm Names
* Public Key Algorithm Names
* Compression Algorithm Names
These names MUST be printable US-ASCII strings, and MUST NOT contain
the characters at-sign ("@"), comma (","), whitespace, control
characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
Names are case-sensitive, and MUST NOT be longer than 64 characters.
Names with the at-sign ("@") are locally defined extensions and are
not controlled by the IANA.
Ylonen & Lonvick Standards Track [Page 12]
RFC 4251 SSH Protocol Architecture January 2006
Each category of names listed above has a separate namespace.
However, using the same name in multiple categories SHOULD be avoided
to minimize confusion.
Message numbers (see Section 7) in the range of 0 to 191 are
allocated via IETF CONSENSUS, as described in [RFC2434]. Message
numbers in the 192 to 255 range (local extensions) are reserved for
PRIVATE USE, also as described in [RFC2434].
9. Security Considerations
In order to make the entire body of Security Considerations more
accessible, Security Considerations for the transport,
authentication, and connection documents have been gathered here.
The transport protocol [SSH-TRANS] provides a confidential channel
over an insecure network. It performs server host authentication,
key exchange, encryption, and integrity protection. It also derives
a unique session id that may be used by higher-level protocols.
The authentication protocol [SSH-USERAUTH] provides a suite of
mechanisms that can be used to authenticate the client user to the
server. Individual mechanisms specified in the authentication
protocol use the session id provided by the transport protocol and/or
depend on the security and integrity guarantees of the transport
protocol.
The connection protocol [SSH-CONNECT] specifies a mechanism to
multiplex multiple streams (channels) of data over the confidential
and authenticated transport. It also specifies channels for
accessing an interactive shell, for proxy-forwarding various external
protocols over the secure transport (including arbitrary TCP/IP
protocols), and for accessing secure subsystems on the server host.
9.1. Pseudo-Random Number Generation
This protocol binds each session key to the session by including
random, session specific data in the hash used to produce session
keys. Special care should be taken to ensure that all of the random
numbers are of good quality. If the random data here (e.g., Diffie-
Hellman (DH) parameters) are pseudo-random, then the pseudo-random
number generator should be cryptographically secure (i.e., its next
output not easily guessed even when knowing all previous outputs)
and, furthermore, proper entropy needs to be added to the pseudo-
random number generator. [RFC4086] offers suggestions for sources of
random numbers and entropy. Implementers should note the importance
of entropy and the well-meant, anecdotal warning about the difficulty
in properly implementing pseudo-random number generating functions.
Ylonen & Lonvick Standards Track [Page 13]
RFC 4251 SSH Protocol Architecture January 2006
The amount of entropy available to a given client or server may
sometimes be less than what is required. In this case, one must
either resort to pseudo-random number generation regardless of
insufficient entropy or refuse to run the protocol. The latter is
preferable.
9.2. Control Character Filtering
When displaying text to a user, such as error or debug messages, the
client software SHOULD replace any control characters (except tab,
carriage return, and newline) with safe sequences to avoid attacks by
sending terminal control characters.
9.3. Transport
9.3.1. Confidentiality
It is beyond the scope of this document and the Secure Shell Working
Group to analyze or recommend specific ciphers other than the ones
that have been established and accepted within the industry. At the
time of this writing, commonly used ciphers include 3DES, ARCFOUR,
twofish, serpent, and blowfish. AES has been published by The US
Federal Information Processing Standards as [FIPS-197], and the
cryptographic community has accepted AES as well. As always,
implementers and users should check current literature to ensure that
no recent vulnerabilities have been found in ciphers used within
products. Implementers should also check to see which ciphers are
considered to be relatively stronger than others and should recommend
their use to users over relatively weaker ciphers. It would be
considered good form for an implementation to politely and
unobtrusively notify a user that a stronger cipher is available and
should be used when a weaker one is actively chosen.
The "none" cipher is provided for debugging and SHOULD NOT be used
except for that purpose. Its cryptographic properties are
sufficiently described in [RFC2410], which will show that its use
does not meet the intent of this protocol.
The relative merits of these and other ciphers may also be found in
current literature. Two references that may provide information on
the subject are [SCHNEIER] and [KAUFMAN]. Both of these describe the
CBC mode of operation of certain ciphers and the weakness of this
scheme. Essentially, this mode is theoretically vulnerable to chosen
cipher-text attacks because of the high predictability of the start
of packet sequence. However, this attack is deemed difficult and not
considered fully practicable, especially if relatively long block
sizes are used.
Ylonen & Lonvick Standards Track [Page 14]
RFC 4251 SSH Protocol Architecture January 2006
Additionally, another CBC mode attack may be mitigated through the
insertion of packets containing SSH_MSG_IGNORE. Without this
technique, a specific attack may be successful. For this attack
(commonly known as the Rogaway attack [ROGAWAY], [DAI], [BELLARE]) to
work, the attacker would need to know the Initialization Vector (IV)
of the next block that is going to be encrypted. In CBC mode that is
the output of the encryption of the previous block. If the attacker
does not have any way to see the packet yet (i.e., it is in the
internal buffers of the SSH implementation or even in the kernel),
then this attack will not work. If the last packet has been sent out
to the network (i.e., the attacker has access to it), then he can use
the attack.
In the optimal case, an implementer would need to add an extra packet
only if the packet has been sent out onto the network and there are
no other packets waiting for transmission. Implementers may wish to
check if there are any unsent packets awaiting transmission;
unfortunately, it is not normally easy to obtain this information
from the kernel or buffers. If there are no unsent packets, then a
packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is
added to the stream every time the attacker knows the IV that is
supposed to be used for the next packet, then the attacker will not
be able to guess the correct IV, thus the attack will never be
successful.
As an example, consider the following case:
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains Record 1
[500 ms passes, no ACK]
TCP(seq=x, len=1000) ---->
contains Records 1,2
ACK
1. The Nagle algorithm + TCP retransmits mean that the two records
get coalesced into a single TCP segment.
2. Record 2 is not at the beginning of the TCP segment and never will
be because it gets ACKed.
3. Yet, the attack is possible because Record 1 has already been
seen.
Ylonen & Lonvick Standards Track [Page 15]
RFC 4251 SSH Protocol Architecture January 2006
As this example indicates, it is unsafe to use the existence of
unflushed data in the TCP buffers proper as a guide to whether an
empty packet is needed, since when the second write() is performed
the buffers will contain the un-ACKed Record 1.
On the other hand, it is perfectly safe to have the following
situation:
Client Server
------ ------
TCP(seq=x, len=500) ---->
contains SSH_MSG_IGNORE
TCP(seq=y, len=500) ---->
contains Data
Provided that the IV for the second SSH Record is fixed after the
data for the Data packet is determined, then the following should
be performed:
read from user
encrypt null packet
encrypt data packet
9.3.2. Data Integrity
This protocol does allow the Data Integrity mechanism to be disabled.
Implementers SHOULD be wary of exposing this feature for any purpose
other than debugging. Users and administrators SHOULD be explicitly
warned anytime the "none" MAC is enabled.
So long as the "none" MAC is not used, this protocol provides data
integrity.
Because MACs use a 32-bit sequence number, they might start to leak
information after 2**32 packets have been sent. However, following
the rekeying recommendations should prevent this attack. The
transport protocol [SSH-TRANS] recommends rekeying after one gigabyte
of data, and the smallest possible packet is 16 bytes. Therefore,
rekeying SHOULD happen after 2**28 packets at the very most.
9.3.3. Replay
The use of a MAC other than "none" provides integrity and
authentication. In addition, the transport protocol provides a
unique session identifier (bound in part to pseudo-random data that
is part of the algorithm and key exchange process) that can be used
by higher level protocols to bind data to a given session and prevent
Ylonen & Lonvick Standards Track [Page 16]
RFC 4251 SSH Protocol Architecture January 2006
lt;https://www.rfc-editor.org/info/rfc6838>.
[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>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[TLS] 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>.
10.2. Informative References
[CLOCKSKEW]
Acer, M., Stark, E., Felt, A., Fahl, S., Bhargava, R.,
Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz,
"Where the Wild Warnings Are: Root Causes of Chrome HTTPS
Certificate Errors", Proceedings of the 2017 ACM SIGSAC
Conference on Computer and Communications Security,
DOI 10.1145/3133956.3134007, October 2017,
<https://doi.org/10.1145/3133956.3134007>.
[CONSISTENCY]
Davidson, A., Finkel, M., Thomson, M., and C. A. Wood,
"Key Consistency and Discovery", Work in Progress,
Internet-Draft, draft-ietf-privacypass-key-consistency-01,
10 July 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-privacypass-key-consistency-01>.
[COOKIES] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The
Second-Generation Onion Router", May 2004,
<https://svn.torproject.org/svn/projects/design-paper/tor-
design.html>.
[FIELDING] Fielding, R. T., "Architectural Styles and the Design of
Network-based Software Architectures", January 2000,
<https://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[FORWARDED]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[HTTP/3] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[NTP] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[ODOH] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A.
Wood, "Oblivious DNS over HTTPS", RFC 9230,
DOI 10.17487/RFC9230, June 2022,
<https://www.rfc-editor.org/info/rfc9230>.
[ODOH-PETS]
Singanamalla, S., Chunhapanya, S., Hoyland, J., VavruĊĦa,
M., Verma, T., Wu, P., Fayed, M., Heimerl, K., Sullivan,
N., and C. A. Wood, "Oblivious DNS over HTTPS (ODoH): A
Practical Privacy Enhancement to DNS", PoPETS Proceedings
Volume 2021, Issue 4, pp. 575-592, DOI 10.2478/popets-
2021-0085, January 2021,
<https://www.petsymposium.org/2021/files/papers/issue4/
popets-2021-0085.pdf>.
[OHTTP-ANALYSIS]
Hoyland, J., "Tamarin Model of Oblivious HTTP", commit
6824eee, October 2022,
<https://github.com/cloudflare/ohttp-analysis>.
[PRIO] Corrigan-Gibbs, H. and D. Boneh, "Prio: Private, Robust,
and Scalable Computation of Aggregate Statistics", March
2017, <https://crypto.stanford.edu/prio/paper.pdf>.
[RANDOM] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
[TEMPLATE] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.
[UWT] Nottingham, M., "Unsanctioned Web Tracking", W3C TAG
Finding, July 2015,
<https://www.w3.org/2001/tag/doc/unsanctioned-tracking/>.
[X25519] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
Appendix A. Complete Example of a Request and Response
A 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 minimal; the purpose of this example is to show the
cryptographic operations. In this example, the Client is configured
with the Oblivious Relay Resource URI of
https://proxy.example.org/request.example.net/proxy, and the proxy is
configured to map requests to this URI to the Oblivious Gateway
Resource URI https://example.com/oblivious/request. The Target
Resource URI, i.e., the resource the Client ultimately wishes to
query, is https://example.com.
To begin the process, the Oblivious Gateway Resource generates a key
pair. In this example, the server chooses DHKEM(X25519, HKDF-SHA256)
and generates an X25519 key pair [X25519]. The X25519 secret key is:
3c168975674b2fa8e465970b79c8dcf09f1c741626480bd4c6162fc5b6a98e1a
The Oblivious Gateway Resource constructs a key configuration that
includes the corresponding public key as follows:
01002031e1f05a740102115220e9af918f738674aec95f54db6e04eb705aae8e
79815500080001000100010003
This key configuration is somehow obtained by the Client. Then, when
a Client wishes to send an HTTP GET request to the target
https://example.com, it constructs the following binary HTTP message:
00034745540568747470730b6578616d706c652e636f6d012f
The Client then reads the Oblivious Gateway 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 sending context that uses the server public
key. This context is constructed from the following ephemeral secret
key:
bc51d5e930bda26589890ac7032f70ad12e4ecb37abb1b65b1256c9c48999c73
The corresponding public key is:
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
The context is created with an info parameter of:
6d6573736167652f626874747020726571756573740001002000010001
Applying the Seal operation from the HPKE context produces an
encrypted message, allowing the Client to construct the following
Encapsulated Request:
010020000100014b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad1
9dec96c208b4726374e469135906992e1268c594d2a10c695d858c40a026e796
5e7d86b83dd440b2c0185204b4d63525
The Client then sends this to the Oblivious Relay Resource in a POST
request, which might look like the following HTTP/1.1 request:
POST /request.example.net/proxy HTTP/1.1
Host: proxy.example.org
Content-Type: message/ohttp-req
Content-Length: 78
<content is the Encapsulated Request above>
The Oblivious Relay Resource receives this request and forwards it to
the Oblivious Gateway Resource, which might look like:
POST /oblivious/request HTTP/1.1
Host: example.com
Content-Type: message/ohttp-req
Content-Length: 78
<content is the Encapsulated Request above>
The Oblivious Gateway 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 Gateway Resource does not need to initiate an
HTTP request to the Target Resource. The request can be served
directly by the Target Resource, which generates a minimal response
(consisting of just a 200 status code) as follows:
0140c8
The response is constructed by exporting a secret from the HPKE
context:
62d87a6ba569ee81014c2641f52bea36
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:
4b28f881333e7c164ffc499ad9796f877f4e1051ee6d31bad19dec96c208b472
c789e7151fcba46158ca84b04464910d
The salt and secret are both passed to the Extract function of the
selected KDF (HKDF-SHA256) to produce a pseudorandom key of:
979aaeae066cf211ab407b31ae49767f344e1501e475c84e8aff547cc5a683db
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):
5d0172a080e428b16d298c4ea0db620d
With the same KDF and pseudorandom key, an info field of "nonce" is
used to generate a 12-byte nonce:
f6bf1aeb88d6df87007fa263
The AEAD Seal() function is then used to encrypt the response, which
is added to the randomized nonce value to produce the Encapsulated
Response:
c789e7151fcba46158ca84b04464910d86f9013e404feea014e7be4a441f234f
857fbd
The Oblivious Gateway Resource constructs a response with the same
content:
HTTP/1.1 200 OK
Date: Wed, 27 Jan 2021 04:45:07 GMT
Cache-Control: private, no-store
Content-Type: message/ohttp-res
Content-Length: 38
<content is the Encapsulated Response>
The same response might then be generated by the Oblivious Relay
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.
Acknowledgments
This design is based on a design for Oblivious DNS (queries) over
HTTPS (DoH), described in [ODOH]. David Benjamin, Mark Nottingham,
and Eric Rescorla made technical contributions. The authors also
thank Ralph Giles, Lucas Pardue, and Tommy Pauly for invaluable
assistance.
Authors' Addresses
Martin Thomson
Mozilla
Email: mt@lowentropy.net
Christopher A. Wood
Cloudflare
Email: caw@heapingbits.net