Parses "enc_request" into "keyID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to <del> "keyID".  If no such key exists, the server returns an error. </del>  Compute an HPKE context using "skR" and the encapsulated key "enc", yielding "context". 5.  In 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: oblivious target resource simplifies the interactions between those resources without affecting client privacy. <del> 5.1. </del>  Clients have the fewest direct responsibilities, though clients do need to ensure that they do not undermine the process. contain only minimal information as it only needs to include a method and the oblivious request resource URL. <del> 5.2. </del>  The proxy that serves the oblivious proxy resource has a very simple function to perform.  It forwards messages received at this resource forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information. <del> 5.2.1. </del>  As there are privacy benefits from having a large rate of requests forwarded by the same proxy (see ta), servers that operate the higher request rate might choose to authenticate the proxy to enable the higher rate. <del> 5.2.2. </del>  As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages A proxy that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched. <del> 5.3. </del>  A server that operates both oblivious request and oblivious target resources is responsible for removing request encapsulation, protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. <del> 6. </del>  Words... <del> 7. </del>  <del> TODO: Define a media type or types here. </del>

This is more or less implied already, but it is better to write it down. I've added stubs for some content types as well.
This probably covers a bunch of things, so I'll start with a few things that might want to be discovered automatically: Clients might want to ask the oblivious proxy resource which oblivious request resource it forwards to. Clients might want to learn about which oblivious target resources a particular oblivious request resource is willing to forward to. Clients might want to learn automatically about the public keys the oblivious request resource has (along with key identifiers, see ). Clients might want to ask about the oblivious proxy resources that forward to a particular oblivious request resource. This is a little tricky, because clients will need to exercise discretion in selecting from this set. This also risks exposing the existence of DoS exemption agreements between the oblivious request resource server and the oblivious proxy resource server. Clients might want to ask the oblivious target resource for an oblivious request resource (or by extension oblivious proxy resource) that it can use to reach that resource. If you look at this as link relations, this is two forward links, a key configuration, and two backward links. Defining link relation types for this might be a way to address this. Assuming that we also define a media type for a key configuration format, that is.
This seems to me to the fundamental challenge with this system, and a great many other systems. DHTs have been used to advertise resource availability, but the searched object is quite hard to blind from everyone. We could say that good is the enemy of great, only we've been at this a while, and neither have shown up.
NAME use of the word "system" is interesting here. OHTTP does not describe a system, but a protocol. The way that this protocol is deployed and used in practice, I think, defines the system. (The same argument goes for protocols like DoH.) So I don't see this as a challenge to the protocol design, but rather to how one might configure and use it in practice. And that seems rightfully out of scope.
NAME Document that practice a bit, then, if it is practice. I don't view the DoH document as a resounding success, fwiw. It left many questions unanswered, to the point that we had to spin up another working group just to address them. My fundamental question remains: does ohttp contribute more positive than negative? No use case in the document means no understanding of that. I do appreciate Martin and Eric's explanation on list. Perhaps that should be incorporated.
You might not find this satisfactory, but there is text in the draft about exactly the use cases that Ekr described. https://unicorn-URL has those two. Are you asking for more discussion of the relationship between various actors in those use cases?
Martin, the example you gave was really good. The trick is to show how the players interact.
Discussed at IETF 113 and the WG decided that we would continue the discovery discussion in relation to other drafts.
We aren't really able to carry informational status codes using this form of encapsulation. Sure, we could encode an informational status as a new message, but we don't have anywhere to include it, except as the content of a response, along with the final status code. That might not be helpful if you consider things like 100-continue. My recommendation is to make this limitation clear and prohibit the use of 100-continue.

Parses "enc_request" into "keyID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to  <ins> "keyID".  If no such key exists, the server returns an error; see errors. </ins> Compute an HPKE context using "skR" and the encapsulated key "enc", yielding "context". 5. <ins> A 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 (media-types), 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 ALT-SVC. 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 Section 7.6 of HTTP. 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 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 it detects before removing encapsulation of the request; see errors. 5.1. 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 request resource MUST generate an error if a 100-continue expectation is received. 5.2. 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 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. 6. Media types are used to identify encapsulated requests and responses. 6.1. The "message/ohttp-req" identifies an encapsulated binary HTTP request.  This is a binary format that is defined in request. message ohttp-req N/A None only "8bit" or "binary" is permitted see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 6.2. The "message/ohttp-res" identifies an encapsulated binary HTTP response.  This is a binary format that is defined in response. message ohttp-res N/A None only "8bit" or "binary" is permitted see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 7. </ins> In 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: oblivious target resource simplifies the interactions between those resources without affecting client privacy.  <ins> 7.1. </ins> Clients have the fewest direct responsibilities, though clients do need to ensure that they do not undermine the process. contain only minimal information as it only needs to include a method and the oblivious request resource URL.  <ins> 7.2. </ins> The proxy that serves the oblivious proxy resource has a very simple function to perform.  It forwards messages received at this resource forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information.  <ins> 7.2.1. </ins> As there are privacy benefits from having a large rate of requests forwarded by the same proxy (see ta), servers that operate the higher request rate might choose to authenticate the proxy to enable the higher rate.  <ins> 7.2.2. </ins> As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages A proxy that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.  <ins> 7.3. </ins> A server that operates both oblivious request and oblivious target resources is responsible for removing request encapsulation, protection for the unprotected requests and responses, plus protections for traffic analysis; see ta.  <ins> 8. </ins> Words...  <ins> 9. Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] with the registration information in media-types for the media types "message/ ohttp-req" and "message/ohttp-res". 10.  References 10.1.  URIs </ins>  <ins> [1] https://www.iana.org/assignments/media-types </ins>


Abstract <del> This 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. </del>  1. <del> The 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 Dingledine2004, 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 </del>  cryptographic computations. <del> This document describes a method of encapsulation for binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE). This protects the content of both requests and responses and enables a deployment architecture that can separate the identity of a </del>  requester from the request. <del> Though this scheme requires that servers and proxies (called relays in this document) 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 relay (see security), clients are assured that requests are not uniquely attributed to them or linked to other requests. </del>  2.

I found this helpful, do with it what you will.
I'll merge and fix lints afterwards.
LGTM. Thanks Mark.

Abstract  <ins> This document describes a system for forwarding encrypted HTTP messages.  This allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. </ins> 1.  <ins> A HTTP request reveals information about the client's identity to the server.  Some of that information is in the request content, and therefore under the control of the client.  However, the source IP address of the underlying connection reveals information that the client has only limited control over. Even where an IP address is not directly associated with an individual, the requests made from it can be correlated over time to assemble a profile of client behavior.  In particular, connection reuse improves performance, but provides servers with the ability to correlate requests that share a connection. Client-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and the Tor network Dingledine2004 provide additional options for clients. However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS connection to avoid the connection itself being used to correlate behavior.  This imposes considerable performance and efficiency overheads, due to the additional round trip to the server (at a minumum), additional data exchanged, and additional CPU cost of </ins> cryptographic computations.  <ins> This document defines two kinds of HTTP resources - Oblivious Relay Resources and Oblivious Gateway Resources - that process encapsulated binary HTTP messages BINARY using Hybrid Public Key Encryption (HPKE; HPKE).  They can be composed to protect the content of encapsulated requests and responses, thereby separating the identity of a </ins> requester from the request.  <ins> Although this scheme requires support for two new kinds of oblivious resources, it represents a performance improvement over options that perform just one request in each connection.  With limited trust placed in the Oblivious Relay Resource (see security), clients are assured that requests are not uniquely attributed to them or linked to other requests. </ins> 2.


A server operates both the Oblivious Gateway Resource and the Target Resource  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 6.2.3. <del> This document assumes that all communication between different Oblivious Client, Oblivious Relay Resource, and Oblivious Gateway Resource is protected by HTTPS.  This 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, it does not mitigate traffic analysis by such network observers. </del>  The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages

The text noted in was correct, but we didn't have a single place where we outlined this as a direct requirement. The day where HTTP presupposes TLS has come for some, but not all of us. Until then, we can be more careful.
The document uses the term TLS connection(s) in four places: My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care. Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. URL states many requirements but not the use of HTTPS. That seems implicit via URL However, that seems in conflict with URL, which says In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.

A server operates both the Oblivious Gateway Resource and the Target Resource <ins> Connections between the client, Oblvious Relay Resource, and Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.  The scheme of the encapsulated request detemrines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> 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 6.2.3.  <ins> 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. </ins> The time at which Encapsulated Request or response messages are sent can reveal information to a network observer.  Though messages


string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes. <del> Formats are described using notation from QUIC. </del>  3. request describes the process for constructing and processing an Encapsulated Request. <del> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </del>  An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. content.  response describes the process for constructing and processing an Encapsulated Response. <del> The Nenc and Nk parameters corresponding to the HpkeKdfId can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes; Nk refers to the size of the AEAD key for the HPKE ciphersuite, in bits. </del>  4.1.

In Section 4, there are two statements for Encapsulated Request and Encapsulate Response respectively These are the only places that is used. The HPKE spec doesn't use the term either. Doing some digging, it seemed like an older draft defined this term (and others); see URL But it seems like you moved away from that and this is a hangover
So this isn't ideal. It is also wrong. It would be HpkeKemId in the first instance and HpkeAeadId in the second. The second also refers to Nenc without using it. The second also neglected to mention Nn, which was in the algorithm. What a mess. I've cleaned it up, but would appreciate someone double-checking my work.
This addresses the issue I created, thanks. I can't vouch for the correctness of the crypto pieces though

string "s" is indicated using the function "encode_str(s)".  The function "len()" returns the length of a sequence of bytes.  <ins> Formats are described using notation from QUIC.  An extension to that notation expresses the number of bits in a field using a simple mathematical function. </ins> 3. request describes the process for constructing and processing an Encapsulated Request.  <ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </ins> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. content.  response describes the process for constructing and processing an Encapsulated Response.  <ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The Encapsulated Response nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.1.


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 <del> the AEAD associated with "context".  Generating "key" uses a label of "key". </del>  Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD. <del> Generating "nonce" uses a label of "nonce". </del>  Encrypt "response", passing the AEAD function Seal the values of <del> "key", "nonce", empty "aad", and a "pt" input of "request", which yields "ct". </del>  Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-

Section 4.2, prose says whereas the pseudo-code says
A few things here should improve readability: key -> aeadkey, nonce -> aeadnonce, then we should be sure to pass the response in rather than the request.
Nice catch on s/request/responseLGTM

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  <ins> the AEAD associated with "context".  Generating "aead_key" uses a label of "key". </ins> Use the same "Expand" function to extract a nonce "nonce" of length "Nn" - the length of the nonce used by the AEAD.  <ins> Generating "aead_nonce" uses a label of "nonce". </ins> Encrypt "response", passing the AEAD function Seal the values of  <ins> "aead_key", "aead_nonce", an empty "aad", and a "pt" input of "response", which yields "ct". </ins> Concatenate "response_nonce" and "ct", yielding an Encapsulated Response "enc_response".  Note that "response_nonce" is of fixed-


difference is relevant, applications can instead connect directly to the target at the cost of either privacy or performance. <del> Clients MUST NOT include identifying information in the request that is encrypted.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </del> Clients cannot carry connection-level state between requests as they only establish direct connections to the relay responsible for the <del> Oblivious Relay 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 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. </del>  Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not

Not even once, down from two. Using cookies is dumb, but we don't need to ban them so directly. There are tons of ways in which information from a previous request might leak across into the current one. The point is to highlight the risk of using them. A direct prohibition doesn't make sense if the use of the cookie is well understood (not that attaining such an understanding is likely to be easy).
In Section 6.1, the document states twice, in the space of two paragraphs, that clients MUST NOT use cookies. That seems a little excessive.
I'm OK with this relaxation. Clients who want to use OHTTP will presumably not do the dumb thing.

difference is relevant, applications can instead 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  <ins> 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. </ins> Clients MUST generate a new HPKE context for every request, using a good source of entropy (RANDOM) for generating keys.  Key reuse not


Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource respectively.  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 Relay Resource forwards the response according to the rules of an HTTP proxy; see HTTP.  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 unless it is responding to errors it detects before removing encapsulation of the request; see errors.  5.1. This encapsulation does not permit progressive processing of

So add some forward references.
Sections 6.1, 6.2 and 6.3 detail normative requirements that seem to apply to the actors duties outlined in section 5. Consider forward references to each respective section to aid implementers in discovery applicable considerations.

Gateway Resource also act as HTTP clients toward the Oblivious Gateway Resource and Target Resource respectively. <ins> In order to achieve the privacy and security goals of the protocol a client also needs to observe the guidance in client-responsibilities. </ins> 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 Relay Resource forwards the response according to the rules of an HTTP proxy; see HTTP. <ins> In order to achieve the privacy and security goals of the protocol an Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. </ins> 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 unless it is responding to errors it detects before removing encapsulation of the request; see errors. <ins> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities. </ins> 5.1. This encapsulation does not permit progressive processing of


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 <del> dos.  It is also necessary to provide confidentiality protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. </del>  Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and

Especially when we already address this point a few paragraphs above and we then directly contradict it in the next one.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.

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  <ins> dos. </ins> Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and


A client or Oblivious Relay 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 <del> HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred. Connection failures or interruptions are not sufficient signals that no processing occurred. </del>  The anti-replay mechanisms described in TLS are generally applicable to Oblivious HTTP requests.  The encapsulated keying material (or The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response.  IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.

This would have been easier had I not forgotten how to do this.
Does this ref need to be normative?
oh, it seems this relates to a the registration of buried down in Section 10.2. Is this still valid?
Yes it is, though I realize that we also buried the IANA considerations a little too deep.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.

A client or Oblivious Relay 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  <ins> HTTP/2 REFUSED_STREAM error code (HTTP2), the HTTP/3 H3_REQUEST_REJECTED error code (HTTP3), or a GOAWAY frame with a low enough identifier (in either protocol version) are all sufficient signals that no processing occurred.  Connection failures or interruptions are not sufficient signals that no processing occurred. </ins> The anti-replay mechanisms described in TLS are generally applicable to Oblivious HTTP requests.  The encapsulated keying material (or The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <ins> 10.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.


When a response is received from the Oblivious Gateway Resource, the Oblivious Relay Resource forwards the response according to the rules <del> of an HTTP proxy; see HTTP. </del>  In order to achieve the privacy and security goals of the protocol an Oblivious Relay Resource also needs to observe the guidance in relay- information that does not reveal information about the encapsulated response.  In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.

Pretty much what you might expect; see Section 7.6 of [HTTP]. NAME WDYT?
The draft says An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response. What happens if that encapsulated response is zero-length? The section seems ambiguous on this point. To encapsulate a response the gateway resource needs to hold the private hpke key for every endpoint it services, even if that response is a simple status code with no body content, as is common with POST requests. For security, it would be nice if it were possible to restrict the private key to an offline process. That is, instead of the gateway performing decapsulation itself, it writes the encapsulated request directly to the target and returns success unconditionally. Then a separate process, running in a more restricted environment, performs decapsulation and analysis of the client requests. The attack surface is reduced, and vulnerabilities in the gateway implementation are less serious because it cannot leak the keys. One way to do this is to have the gateway return to the relay with no response body, and have the relay forward that back to the client. The client would have to assume success in this case. For some applications, this "best effort" submission could be an acceptable trade off for better data path integrity.
The Encapsulated Response encoding currently does not admit a zero-length (empty) response. It includes at least max(Nn, Nk)+Nt (ciphertext tag size) bytes. This is an interesting use case. I can imagine changing the Encapsulated Response type to admit successful zero-length responses to signal "I received your request and will process it later." This isn't authenticated any differently from non-2xx responses from the gateway, so I don't think it's a problem that the HPKE context is not used to generate the response here. I suppose the main question (to me) is whether or not clients should be configured to expect this behavior. What happens if a client gets an empty 200 response when it expected a non-empty response? Should it retry? Should it only accept this if the client is configured this way? The latter is probably doable. NAME NAME thoughts?
I could see allowing it the client has a configuration to handle it specially, but in general, I think that a client wouldn't expect an empty response that is still a 200, since it doesn't have any expected content type, etc.
The encapsulated request and response is effectively just HTTP. IIUC this is a proposal to change the HTTP interaction model to fire-and-forget. I.e. infer that when something on the path claims it delivered something, the client should accept that. Why do we want to change HTTP? A way to emulate this, without changing HTTP semantics, is to have the Gateway synthesize an encapsulated response itself. Then the client doesn't need to handle an empty response. If you cared for signalling, the Gateway could include a field in the synthesized response that indicted this had happened.
Agreed with Lucas on this
The use case is to hide the private key from the Gateway. Is this possible without access to the key?
NAME I don't think this is a change to HTTP at all. It's just a change to the HTTP usage here. It is totally feasible for the relay to return a 200 response to the client that means "I accepted your relay request and will forward it later." This seems totally valid and indeed something we might want for applications that don't need a response to the client and want the relay to do some sort of batching. If we wanted to support this, maybe we could use a separate content type for the response that is along the lines of an acknowledgement, rather than a response with actual content.
That's fair. But then we should not be overloading the OHTTP interaction model. Rather, when the Gateway responds with a 200, it always contains an enclosed response as today. And if you want a different interaction, then return a different status code like : This 202 representation is not the enclosed request - it could be empty.
Oh, perfect! I didn't know 202 existed. That sounds like it would work here without any sort of change, beyond maybe a note saying that it's possible to use?
Personally I'd lean more towards being explicit that this could happen, and is effectively a conditional terminal branch of the sequence at step 6 https://ietf-wg-URL But that's just my 2c
Being explicit makes it more likely this path will be implemented uniformly.
Specifying the operation of the protocol for a 202 is possible, but I doubt we could do that trivially. A relay can send 202. This introduces some interesting consequences for end-to-end reliability. A gateway might also send 202 (it takes the request, stores it, responds). The gateway concerns are approximately the same. As NAME observes, this might allow the gateway to operate without the private key, which is a very useful feature for something like STAR. If we deal with this case in this document, we'll have to cover all bases. I see three options: We specify the necessary behaviour here, in full. We describe the general sort of circumstance in which it might be advantageous to have the client not wait around for a full end-to-end response. We explain that the relay/gateway needs to understand the application for which it is forwarding requests and that 202 responses are generally not acceptable. We explain that by responding with 202 the relay/gateway takes responsibility for the forwarding of the request and any necessary actions that might be needed to improve reliability, including retries. We explain that clients that use such a relay/gateway need to be aware of what the relay/gateway might do and that this means that they will not get any end-to-end signal that provides them with a reliable indication that their request was processed. We specify a separate extension, with all of the above. We leave this extension to each application of the protocol, which can address each of the above points as it chooses. That application can do less about addressing those concerns as it might specify the use of 202 at only one of the nodes. I'm guessing that this is for STAR, so it does make a degree of sense to have the gateway to store requests and respond with 202. As a telemetry system, the loss of reliability is essentially zero (you don't get an end-to-end confirmation that the key you chose worked, so it's not perfect, but that's deliberate and more of a feature than a bug in that case). So I'm inclined to suggest that STAR deal with describing this.
Yeah, my concern is that this could be feature creep and delay this document further, when it's already achieved the starting goals. Punting to another document seems fair to me. What I might expect here is some brief service about how a gateway responds when there is no response from the target. This thread started with the draft excerpt: Ignoring fancy usecases, there are failure cases for the the Gateway: fail to resolve the target, or fail to connect to it, or fail receive a complete response. In other HTTP intermediation, returning a 5xx (e.g. 502, 504) is common for such cases. If the gateway did that here, I'm not clear what expectations there on the response - the MUST requirement for the 200 case can't apply right?
The MUST there is implicitly conditional on the gateway receiving a response. We can add a sentence saying that if the gateway doesn't receive a response it can encapsulate an appropriate error response (like 504).
I've opened . It doesn't address this specific concern, but it will deal with the problem Lucas identified.
I threw together describing an unreliable variant of OHTTP that satisfies the use case motivating this issue. NAME (and others), please have a look! Contributions from everyone are welcome.
The unreliable-ohttp draft addresses my motivating use case, and there's at least some clarifying text about error handling for the Relay, so I'm satisfied this is addressed.

When a response is received from the Oblivious Gateway Resource, the Oblivious Relay Resource forwards the response according to the rules  <ins> of an HTTP proxy; see HTTP.  In case of timeout or error, the Oblivious Relay Resource can generate a response with an appropriate status code. </ins> In order to achieve the privacy and security goals of the protocol an Oblivious Relay Resource also needs to observe the guidance in relay- information that does not reveal information about the encapsulated response. <ins> 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 HTTP), which is then encapsulated in the same way as a successful response. </ins> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.


8.1. <del> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology.  A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </del>  8.2.

In Deployment Considerations / Performance Overhead... Should that be "cryptographic" -> "cryptographic complexity" or something like that?
It should probably be "cryptographic overhead." Nice catch!

8.1.  <ins> Using Oblivious HTTP adds both cryptographic overhead and latency to requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between clients and servers avoids adding significant additional delay due to network topology. A study of a similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. </ins> 8.2.


successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use <del> the same configuration by matching "KeyConfig.key_id" or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </del>  Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active

This was the only case we used the TLS-style dot notation, but we don't need to pull in a new concept.

successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use  <ins> the same configuration by matching the key ID from the key configuration or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. </ins> Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active


Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </del>  the public key from the configuration, "pkR", and <del> a selected combination of KDF, identified by "kdfID", and AEAD, identified by "aeadID". </del>  The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of <del> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </del>  Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header. Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", </del>  "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private <del> key, "skR", corresponding to "keyID". </del>  <del> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </del>  <del> 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. </del>  Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, "keyID" as an 8-bit integer, plus "kemID", "kdfID", and "aeadID" as three 16-bit integers. </del>  Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".

RFC 9180 does use skR/pkR/skS/skR, so I didn't change everything to use snake_case, but this is more consistent with how we identify things in other places. Also, it reads better and we don't have to grapple with whether it should be keyId or keyID.

Clients encapsulate a request "request" using values from a key configuration:  <ins> the key identifier from the configuration, "key_id", with the corresponding KEM identified by "kem_id", </ins> the public key from the configuration, "pkR", and  <ins> a selected combination of KDF, identified by "kdf_id", and AEAD, identified by "aead_id". </ins> The client then constructs an Encapsulated Request, "enc_request", from a binary encoded HTTP request, "request", as follows: Construct a message header, "hdr", by concatenating the values of  <ins> "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. </ins> Build "info" by concatenating the ASCII-encoded string "message/ bhttp request", a zero byte, and the header. Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server:  <ins> Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id", </ins> "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private  <ins> key, "skR", corresponding to "key_id". </ins>  <ins> a.  If "key_id" does not identify a key matching the type of "kem_id", the server returns an error. </ins>  <ins> b.  If "kdf_id" and "aead_id" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </ins> Build "info" by concatenating the ASCII-encoded string "message/  <ins> 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. </ins> Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE) with "skR", "enc", and "info".  This produces a context "rctxt".


HTTP message encapsulation uses HPKE for request and response encryption. <del> An encapsulated HTTP request contains a binary-encoded HTTP message BINARY and no other fields; see fig-req-pt. </del>  An Encapsulated Request is comprised of a key identifier and a HPKE- protected request message.  HPKE protection includes an encapsulated in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. <del> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. </del>  Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and three 16-bit integers, respectively, each in network byte order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del>  Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and <del> nonce associated with "context". </del>  Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". Evolution of the format of Encapsulated Requests and Responses is supported through the definition of new formats that are identified <del> by new media types. </del>  5. Clients can use padding to reduce the effectiveness of traffic analysis.  Padding is a capability provided by binary HTTP messages; <del> see BINARY. </del>  6.3. 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" <del> label; see repurposing-the-encapsulation-format. </del>  6.5. 9. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  Client and target 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 hpke-encapsulation, provided that the content type of the encrypted payload is appropriately reflected in the HPKE info and context strings.  For example, if a future specification were to use the encryption mechanism in this specification for DNS messages, identified by the "application/dns-message" media type, then the HPKE info string SHOULD be "application/dns-message request" for request encryption, and the HPKE export context string should be "application/dns-message response" for response encryption. 10. </del> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <del> 10.1. </del>  The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP. <del> 10.2. </del>  The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request. <del> 10.3. </del>  The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <del> 10.4. </del>  IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <del> 11.  References </del>  <del> 11.1.  URIs </del>  [1] https://www.iana.org/assignments/media-types

This is a lot more disruptive, but I think it is a clearer description of how you might repurpose this design. I'm still a little unsure about using application/dns-message, but I can live with it.
If this is acceptable, I might cherry-pick some of the other changes from rather than take it wholesale.
OK, I think that I understand what you are looking for and I agree, we can say more about that. But we probably don't need to say heaps more. Is the latest commit what you are looking for?
NAME I think it's closer, but I genuinely don't see why noting precisely where things need to change in the spec is harmful. I prefer Tommy's original change here.
Yeah, this still doesn't solve the problem of letting implementers know which parts of the encapsulated request processing are the bits that can become generic to handle other media types. Another way to look at this is, for another spec to define how to use another media type, it should be easy to simply say "the OHTTP spec explains the couple places where the media type can be changed from BHTTP to something else — and this use of OHTTP tells you to use a different media type in those spots". We should avoid having new specs like this need to wholesale copy the sections of the OHTTP document that define how to use HPKE, etc, and just have one subtle difference.
I'm not seeing that. I realize that I missed the padding piece (though I don't consider that particularly important, it's worth mentioning). For a generic format, the only adaptation required is replacing the constant strings. This describes how that might work. That we don't burden the reader of the algorithm piece with this detail at the time is a feature, not a bug, as far as I'm concerned.
I don't consider it a burden. I think it's an important piece for someone who's implementing OHTTP since it has API implications. For example, one could implement the main encap and decap algorithms using the fixed "message/bhttp" content type and then find they have to either duplicate code later on adjust their encap and decap APIs (or something else) to accommodate another type of application encoding. The inline hints from the original suggestion in suggest that implementers might want to allow for changes to the content type string so they don't run into this situation down the road, and they're minimally invasive hints at that.
I've added the pointers, as requested. (I only skipped one on the decapsulation process as that seemed redundant.)
Thanks, latest changes look good to me

HTTP message encapsulation uses HPKE for request and response encryption.  <ins> This document defines how a binary-encoded HTTP request BINARY is encapsulated.  This Encapsulated Request format is identified by the iana-req.  Alternative encapsulations or message formats are indicated using the media type. The content of ""message/ohttp-req"" request encapsulation contains only a binary HTTP message; see fig-req-pt. </ins> An Encapsulated Request is comprised of a key identifier and a HPKE- protected request message.  HPKE protection includes an encapsulated in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes.  <ins> This document defines how a binary-encoded HTTP request BINARY is encapsulated.  This Encapsulated Response format is identified by the iana-res.  Alternative encapsulations or message formats are indicated using the media type. The content of ""message/ohttp-res"" response encapsulation contains only a binary HTTP message; see fig-res-pt. </ins> Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and three 16-bit integers, respectively, each in network byte order. Build "info" by concatenating the ASCII-encoded string "message/  <ins> bhttp request", a zero byte, and the header.  Note: repurposing discusses how alternative message formats might use a different "info" value. </ins> Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and  <ins> nonce associated with "context".  Note: repurposing discusses how alternative message formats might use a different "context" value. </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". Evolution of the format of Encapsulated Requests and Responses is supported through the definition of new formats that are identified  <ins> by new media types.  New media types might be defined to use similar encapsulation with a different HTTP message format than in BINARY; see repurposing for guidance on reusing this encapsulation. Alternatively, a new encapsulation method might be defined. 4.4. The encrypted payload of an OHTTP 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. </ins> 5. Clients can use padding to reduce the effectiveness of traffic analysis.  Padding is a capability provided by binary HTTP messages;  <ins> see BINARY.  If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message format might need to include padding support. </ins> 6.3. 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"  <ins> label; see repurposing. </ins> 6.5. 9.  Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res).  <ins> 9.1. </ins> The "application/ohttp-keys" media type identifies a key configuration used by Oblivious HTTP.  <ins> 9.2. </ins> The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request.  <ins> 9.3. </ins> The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response.  <ins> 9.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types


4. <del> HTTP message encapsulation uses HPKE for request and response encryption. </del>  <del> An encapsulated HTTP request contains a binary-encoded HTTP message BINARY and no other fields; see fig-req-pt. </del>  <del> An is comprised of a 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 is shown in fig-enc-request. request describes the process for constructing and processing an . </del>  The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. <del> An encrypted HTTP response includes a binary-encoded HTTP message BINARY and no other content; see fig-res-pt. </del>  <del> Responses are bound to requests and so consist only of AEAD-protected content.  response describes the process for constructing and processing an . </del>  The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). <del> 4.1. </del>  encapsulate a request "request" using values from a : order. Build "info" by concatenating the ASCII-encoded string "message/ <del> bhttp request", a zero byte, and the header. </del>  Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields In pseudocode, this procedure is as follows: <del> 4.2. </del>  Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows: Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and <del> nonce associated with "context". </del>  Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows: <del> 4.3. </del>  Media types are used to identify Encapsulated Requests and Responses; see iana-req and iana-res 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 <del> by new media types. </del>  5. can use padding to reduce the effectiveness of traffic analysis. Padding is a capability provided by binary HTTP messages; see BINARY.  6.3. 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" <del> label; see repurposing-the-encapsulation-format. </del>  6.5. 9. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  and target 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 hpke-encapsulation, provided that the content type of the encrypted payload is appropriately reflected in the HPKE info and context strings.  For example, if a future specification were to use the encryption mechanism in this specification for DNS messages, identified by the "application/dns-message" media type, then the HPKE info string SHOULD be "application/dns-message request" for request encryption, and the HPKE export context string should be "application/dns-message response" for response encryption. 10. </del> Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). <del> 10.1. </del>  The "application/ohttp-keys" media type identifies a used by Oblivious HTTP. <del> 10.2. </del>  The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request. <del> 10.3. </del>  The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response. <del> 10.4. </del>  IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM. <del> 11.  References </del>  <del> 11.1.  URIs </del>  [1] https://www.iana.org/assignments/media-types

This adds a little structure to the section on encapsulation and tries to make the relationship between different media types more distinct. This builds on top of (which we are going to merge soon) because that hits all the same text and we have already effectively agreed to those changes. You can review to see what the substance of these changes are. Alternatively, just look at the top of the "HPKE Encapsulation" section (the other changes are unrelated).
I spent some time being confused because (content type) and (the hpke info tag) are so similar. Is it possible to align these two? Section 9, Repurposing the Encapsulation Format, mentions changing the hpke info for other protocols, so I suppose is re-using the content-type from the binary http draft at this layer, while the outer Content-Type is specific to this draft's application? I can see the logic there, but some clarifying text about the two being different would have been helpful.
We kept them separate because they refer to different things. The "message/ohttp-req" content type refers to the type of HTTP request sent from client to gateway, whereas the "message/bhttp request" content type refers to the type of content that's encapsulated to the gateway. We can probably improve this distinction in the text. Thanks for flagging this.
I did a little rewriting of some of the key framing text for another issue, does the following help at all? URL
The new references to the repurposing section in that commit are helpful. The extra wording you linked doesn't help much I think. It's confusing that the both encapsulates a and is called an 'encapsulated request/response'. So when you say, the word 'contains' is ambiguous: is it that the directly contains the binary HTTP message, or is that the HPKE AEAD contains the binary HTTP message? I understand it's the second one, but on first reading this kind of layer confusion was hard to keep track of. Maybe something about the media type containing the encrypted message along with the necessary parameters to convey the encapsulation would help?
I took a swing at this in . Am I getting closer?

4.  <ins> 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: </ins>  <ins> An format defined in req-format is identified by the iana-req. </ins>  <ins> An format defined in res-format is identified by the iana-res. Alternative encapsulations or message formats are indicated using the media type; see req-res-media and repurposing. 4.1. A message in ""message/ohttp-req"" format protects a binary HTTP request message; see fig-req-pt. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An is comprised of a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated KEM shared secret (or "enc"); and the HPKE-protected binary HTTP request message. An is shown in fig-enc-request. request describes the process for constructing and processing an . </ins> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE.  Nenc refers to the size of the encapsulated KEM shared secret, in bytes.  <ins> 4.2. </ins>  <ins> A message in ""message/ohttp-res"" format protects a binary HTTP response message; see fig-res-pt. This plaintext Response is encapsulated into a message in ""message/ ohttp-res"" form by generating an .  An is comprised of a nonce and the AEAD-protected binary HTTP response message. An is shown in fig-enc-response. response describes the process for constructing and processing an . </ins> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk).  <ins> 4.3. </ins> encapsulate a request "request" using values from a : order. Build "info" by concatenating the ASCII-encoded string "message/  <ins> bhttp request", a zero byte, and the header.  Note: repurposing discusses how alternative message formats might use a different "info" value. </ins> Create a sending HPKE context by invoking "SetupBaseS()" (HPKE) with the public key of the receiver "pkR" and "info".  This yields In pseudocode, this procedure is as follows:  <ins> 4.4. </ins> Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows: Export a secret "secret" from "context", using the string "message/bhttp response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and  <ins> nonce associated with "context".  Note: repurposing discusses how alternative message formats might use a different "context" value. </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce". The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:  <ins> 4.5. </ins> Media types are used to identify Encapsulated Requests and Responses; see iana-req and iana-res 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  <ins> by new media types.  New media types might be defined to use similar encapsulation with a different HTTP message format than in BINARY; see repurposing for guidance on reusing this encapsulation. Alternatively, a new encapsulation method might be defined. 4.6. The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  The and 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. </ins> 5. can use padding to reduce the effectiveness of traffic analysis. Padding is a capability provided by binary HTTP messages; see BINARY. <ins> If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message format might need to include padding support. </ins> 6.3. 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"  <ins> label; see repurposing. </ins> 6.5. 9.  Please update the "Media Types" registry at https://www.iana.org/assignments/media-types [1] for the media types "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res).  <ins> 9.1. </ins> The "application/ohttp-keys" media type identifies a used by Oblivious HTTP.  <ins> 9.2. </ins> The "message/ohttp-req" identifies an encrypted binary HTTP request. This is a binary format that is defined in request.  <ins> 9.3. </ins> The "message/ohttp-res" identifies an encrypted binary HTTP response. This is a binary format that is defined in response.  <ins> 9.4. </ins> IANA are requested to create a new entry in the "HTTP Problem Type" registry established by PROBLEM.  <ins> 10.  References </ins>  <ins> 10.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types


The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target <del> URI is the .  The content of this request is copied from the .  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay- responsibilities for more information on relay responsibilities. </del>  When a response is received from the , the forwards the response according to the rules of an HTTP proxy; see HTTP.  In case of

Forwarding an empty request will always yield a failure on the gateway, so just don't do it.
A request without a body is basically malformed, and the gateway will treat it that way. I think relays should be encouraged to reject malformed requests (invalid method, content type, or content body) so this burden doesn't fall on the gateway.
This seems a little bit strange to single out. Do we really need to mandate this? If the relay forwards the request anyway, the gateway will be unable to decrypt it. This creates a shorter and more immediate feedback loop, but it sort of leads to the next question: how much validation do we rely on the relay to do? What if the content-type is not acceptable? Enforcing that choice might be sensible, but it can also lead to ossification, where the relay's view of what is acceptable prevents new options from being deployed. I would have said that it would be better to say something like "A [relay] MAY reject requests that are obviously invalid, such as a request with no content." Obviously, the relay is going to do some amount of denial of service protection on behalf of the gateway, and blocking empty content is a fairly trivial thing to do there, but so is 1 byte of content or a content-type of . We probably don't need to enumerate all the ways and nor do we need to be so strict about what to do.
Your proposed text works for me.
OK, I'll work out how to make that change. I want to submit an update today.
NAME already applied the suggestion!
Yeah, this is much better.
Perfect, thanks!Seems fine. What was the motivation here?

The interacts with the as an HTTP client by constructing a request using the same restrictions as the request, except that the target  <ins> URI is the .  The content of this request is copied from the .  An MAY reject requests that are obviously invalid, such as a request with no content.  The MUST NOT add information to the request without the being aware of the type of information that might be added; see relay-responsibilities for more information on relay responsibilities. </ins> When a response is received from the , the forwards the response according to the rules of an HTTP proxy; see HTTP.  In case of


Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies <del> (RFC6265), authentication (HTTP), or even alternative services </del>  (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header <del> fields SEMANTICS. </del>  The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from

Duplicate reference: RFC6265, mentioned in 'RFC6265', was also mentioned in 'COOKIES'. Duplicate reference: RFC9110, mentioned in 'SEMANTICS', was also mentioned in 'HTTP'.

Oblivious HTTP has limited applicability.  Many uses of HTTP benefit from being able to carry state between requests, such as with cookies  <ins> (COOKIES), authentication (HTTP), or even alternative services </ins> (RFC7838).  Oblivious HTTP removes linkage at the transport layer, which is only useful for an application that does not carry state between requests. additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header  <ins> fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from


Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or <del> outdated.  The can generate and send a response with an error status to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </del>  5.3.

Might as well say that.
From NAME Section 5.3: Should there be any indication that such errors in processing should be considered as bad requests (and hence return an appropriate error status code) or is this obvious?

Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or  <ins> outdated.  The can generate and send a response with a 4xx status code to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </ins> 5.3.


Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows: <del> Export a secret "secret" from "context", using the string "message/bhttp 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".  Note: repurposing discusses how </del>  alternative message formats might use a different "context" value. Generate a random value of length "max(Nn, Nk)" bytes, called

From NAME Please add a reference to section 5.3 of [HPKE]; it could be confusing at a first glance to have both the context from the exporter function in 5.3 of [HPKE] and the HPKE context here named "context".

Given an HPKE context "context", a request message "request", and a response "response", servers generate an "enc_response" as follows:  <ins> Export a secret, "secret", from "context", using the string "message/bhttp response" as the "exporter_context" parameter to "context.Export"; see HPKE.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context".  Note: repurposing discusses how </ins> alternative message formats might use a different "context" value. Generate a random value of length "max(Nn, Nk)" bytes, called


5. A interacts with the by constructing an .  This is included as the <del> content of a POST request to the .  This request MUST only contain those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, those fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </del>  The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from

Remove a "MUST" in this sentence and lean more heavily on the requirement later.
From NAME It seems to me these two sentences contraddict each other: MUST only contain these fields, and MAY include additional fields. Do I read this wrong? (and same for the response later in the section)

5. A interacts with the by constructing an .  This is included as the  <ins> content of a POST request to the .  This request only needs those fields necessary to carry the : a method of POST, a target URI of the , a header field containing the content type (see (iana-req), and the as the request content.  In the request to the , MAY include additional fields.  However, additional fields MUST be independent of the and MUST be fields that the will remove before forwarding the towards the target, such as the Connection or Proxy-Authorization header fields HTTP. </ins> The role in this protocol acts as an HTTP client both with respect to the and the .  For the request the makes to the , this diverges from


field from the decrypted request is outside of the current time window. <del> SHOULD allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks. </del>  MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to

This really just needs a good explanation of what might happen.
From NAME I understand the goal of the sentence above, but I am not sure the SHOULD is appropriate here - in particular if I think about the above as an interoperability requirement, I don't think it gives enough information to the implementer of what is recommended here. If this was to give for example a default time window, it would be a different story. Can we rephrase? (You can also leave as is, but I think it will come up again in IESG review with no change)

field from the decrypted request is outside of the current time window.  <ins> might need to allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks.  Insufficient tolerance of time differences could result in valid requests being unnecessarily rejected. </ins> MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to


This design does not provide post-compromise security for responses. <del> A 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 </del>  compromise. A server retains a secret key that might be used to remove protection attacker or that the attacker is able to compromise these TLS connections. <del> The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </del>  6.8. One goal of this design is that independent requests are only linkable by their content.  However, the choice of configuration might be used to correlate requests.  A configuration includes the <del> URI, the Oblivious Gateway (KeyConfig), and URI.  A configuration is active if can successfully use it for interacting with with a target. </del>  Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching the key ID from the or the URI. need to be active to allow for key rotation and server maintenance. privacy depends on having each configuration used by many other .  It <del> is critical prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </del>  creating small groupings of that might weaken privacy protections. A specific method for a to acquire configurations is not included in

From NAME First and only time KeyConfig appear in the text. Section 6.7: Missing "to" after "used" Section 6.7: Remove the first "affected" Section 7: Missing "to" before prevent, remove "of"

This design does not provide post-compromise security for responses.  <ins> A only needs to retain keying material that might be used to compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a </ins> compromise. A server retains a secret key that might be used to remove protection attacker or that the attacker is able to compromise these TLS connections.  <ins> The total number of messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 6.8. One goal of this design is that independent requests are only linkable by their content.  However, the choice of configuration might be used to correlate requests.  A configuration includes the  <ins> URI, the Oblivious Gateway , and URI.  A configuration is active if can successfully use it for interacting with with a target. </ins> Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching the key ID from the or the URI. need to be active to allow for key rotation and server maintenance. privacy depends on having each configuration used by many other .  It  <ins> is critical to prevent the use of unique configurations, which might be used to track of individual , but it is also important to avoid </ins> creating small groupings of that might weaken privacy protections. A specific method for a to acquire configurations is not included in


An acts as a gateway for requests to the (see HTTP).  The one exception is that any information it might forward in a response MUST <del> be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del>  An , if it receives any response from the , sends a single 200 response containing the encapsulated response.  Like the request from

This is based on the observation from NAME that we're presuming a specific processing order at the gateway, which is unnecessary.

An acts as a gateway for requests to the (see HTTP).  The one exception is that any information it might forward in a response MUST  <ins> be encapsulated, unless it is responding to errors that do not relate to processing the contents of the encapsulated request; see errors. </ins> An , if it receives any response from the , sends a single 200 response containing the encapsulated response.  Like the request from


Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway <del> and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker. </del>  6.4.

As NAME observes in his review, "same entity" is more or less meaningless when it comes to ensuring that forwarding doesn't happen in the clear. This narrows the recommendation to a concrete "same origin", but notes that even that is not sufficient in all cases.

Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway  <ins> 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 two resources that share an origin do not guarantee that requests are not forwarded without protection. </ins> 6.4.


identifier for that key and the HPKE algorithms that are used with that key. <del> The identity of an that will accept relay requests carrying an encapsulated request as its content and forward the content in these requests to a single . See proxy-state for more information about the mapping between . </del>  This information allows the to make a request of a with that resource having only a limited ability to correlate that request with the IP 3. A needs to acquire information about the of the in order to send <del> encapsulated requests.  In order to ensure that do not encapsulate </del>  messages that other entities can intercept, the MUST be authenticated and have integrity protection. Errors detected by the after successfully removing encapsulation and errors detected by the MUST be sent in an .  This might be because <del> the request is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. </del>  Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or Connections between the , Oblvious Relay Resource, and MUST use HTTPS in order to provide unlinkability in the presence of a network <del> observer.  The scheme of the encapsulated request determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </del>  To achieve the stated privacy goals, the cannot be operated by the same entity as the . However, colocation of the and simplifies the

We weren't always capitalizing "Encapsulated Request". This does more, in direct opposition to the changes in . If we don't take that (it seems we at an impasse there), then we should at least be consistent.
NAME I resolved conflicts, but please double check the intro paragraph that had Mark's proposed changes.

identifier for that key and the HPKE algorithms that are used with that key.  <ins> The identity of an that will accept relay requests carrying an as its content and forward the content in these requests to a single . See proxy-state for more information about the mapping between . </ins> This information allows the to make a request of a with that resource having only a limited ability to correlate that request with the IP 3. A needs to acquire information about the of the in order to send  <ins> Encapsulated Requests.  In order to ensure that do not encapsulate </ins> messages that other entities can intercept, the MUST be authenticated and have integrity protection. Errors detected by the after successfully removing encapsulation and errors detected by the MUST be sent in an .  This might be because  <ins> the is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. </ins> Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or Connections between the , Oblvious Relay Resource, and MUST use HTTPS in order to provide unlinkability in the presence of a network  <ins> observer.  The scheme of the determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> To achieve the stated privacy goals, the cannot be operated by the same entity as the . However, colocation of the and simplifies the


format-key-config shows a single . <del> The definitions for the identifiers used in HPKE and the semantics of the algorithms they identify can be found in HPKE.  The "Npk" parameter is determined by the choice of HPKE KEM, which can also be found in HPKE. </del>  3.2. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated <del> KEM shared secret (or "enc"); and the HPKE-protected binary HTTP </del>  request message. An is shown in fig-enc-request. request describes the process for constructing and processing an . <del> The Nenc parameter corresponding to the KEM used in HPKE can be found in HPKE or the HPKE KEM IANA registry [1].  Nenc refers to the size of the encapsulated KEM shared secret, in bytes. </del>  4.2. An is shown in fig-enc-response. response describes the process for constructing and processing an . <del> The Nn and Nk values correspond to parameters of the AEAD used in HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del>  4.3. 9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [3] for the media types </del>  "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [4] for the types </del>  "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1. 10.1.  URIs <del> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </del>  <del> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </del>  <del> [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </del>  Index

We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...

format-key-config shows a single .  <ins> That is, a consists of the following fields: </ins> 3.2. This plaintext Request is encapsulated into a message in ""message/ ohttp-req"" form by generating an .  An comprises a key identifier; HPKE parameters for the chosen KEM, KDF, and AEAD; the encapsulated  <ins> KEM shared secret (or "enc"); and an HPKE-protected binary HTTP </ins> request message. An is shown in fig-enc-request. request describes the process for constructing and processing an .  <ins> That is, an comprises a Key Identifier, HPKE KEM ID, HPKE KDF ID, HPKE AEAD ID, Encapsulated KEM Shared Secret, and HPKE-Protected Request.  The Key Identifier, HPKE KEM ID, HPKE KDF ID, and HPKE AEAD ID fields are defined in key-config.  The Encapsulated KEM Shared Secret is the output of the "Encap()" function for the KEM, which is "Nenc" bytes in length, as defined in HPKE. </ins> 4.2. An is shown in fig-enc-response. response describes the process for constructing and processing an .  <ins> That is, an 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 HPKE or the HPKE AEAD IANA registry [1]. "Nn" and "Nk" refer to the size of the AEAD nonce and key respectively, in bytes. </ins> 4.3. 9. Please update the "Media Types" registry at  <ins> https://iana.org/assignments/media-types [2] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at  <ins> https://iana.org/assignments/http-problem-types [3] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1. 10.1.  URIs  <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </ins>  <ins> [2] https://iana.org/assignments/media-types </ins>  <ins> [3] https://iana.org/assignments/http-problem-types </ins> Index


-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and <del> the Tor network Dingledine2004 provide additional options for clients. </del>  However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS 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 <del> (PRIO) or Tor (Dingledine2004), which can provide stronger guarantees at higher operational costs. </del>  Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between and servers avoids adding significant additional delay due to network topology.  A study <del> of a similar system ODoH found that deploying proxies close to </del>  servers was most effective in minimizing additional latency. 8.2.

Dingledine2004 -> DMS2004 ODoH -> ODOH-PETS
Comment by NAME ODOH and ODoH seems very similar and likely to cause confusion. Rename one?
thanks
Comment by NAME Using "[Dingledine2004]" as description identifier for TOR is a bit weird :P
This is entirely appropriate given the nature of the reference. This is a reference to a paper, not a specification for Tor, so using "[TOR]" could be misleading. It's possible that we could cite a specification, but it's really hard to pin that down properly. URL seems right, but it doesn't bear a date and appears to be a rendering from URL which is in turn just a snapshot (currently URL). Aside from referential stability, the specification is less of a useful reference as it says less about what Tor is and gets buried in detail. I'm inclined to leave as-is, or switch to "[DMS2004]" to reference all author's names.
ok

-configured HTTP proxies can provide a degree of protection against IP address tracking, and systems like virtual private networks and  <ins> the Tor network DMS2004 provide additional options for clients. </ins> However, even when IP address tracking is mitigated using one of these techniques, each request needs to be on a completely new TLS 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  <ins> (PRIO) or Tor (DMS2004), which can provide stronger guarantees at higher operational costs. </ins> Oblivious HTTP is more costly than a direct connection to a server. Some costs, like those involved with connection setup, can be requests relative to a simple HTTP request-response exchange. Deploying relay services that are on path between and servers avoids adding significant additional delay due to network topology.  A study  <ins> of a similar system ODOH-PETS found that deploying proxies close to </ins> servers was most effective in minimizing additional latency. 8.2.