jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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 <del> encapsulated requests.  In order to ensure that do not encapsulate </del> <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 <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> <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 <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> <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
Change:
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

Discussion:
-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> <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 <del> (PRIO) or Tor (Dingledine2004), which can provide stronger guarantees at higher operational costs. </del> <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 <del> of a similar system ODoH found that deploying proxies close to </del> <ins> of a similar system ODOH-PETS found that deploying proxies close to </ins> servers was most effective in minimizing additional latency. 8.2.
Change:
Comment by NAME How would that work? How would the client consent? Or show awareness? Or become aware ? Can't the Target Resource also not use padding in the response? But I guess they wouldn't know about being connected to obliviously or regularly, unless the Client tells the server within its encrypted payload request? Eg if a regular https server sees a certain field, it would/could know to do some padding? (one would assume ohttp relays are fairly well known on static IPs anyway, so the Client wouldn't be revealing much if it could ask the http server itself for random padding
There are two questions here, delays and padding. Both are areas in which the specification is not prescriptive. This is deliberate, mostly because these are areas where a single strategy would be inadvisable. Application needs vary. Well, in any number of ways. A telemetry submission service (see also STAR) might provide greater privacy benefit from batching requests that are forwarded from the client to gateway. In that model, the client might tolerate arbitrary delay (see URL for example). In other cases, the client still cares about a response, but it might be willing to hang around for some time (10s, 30s) for an answer. How the client consents to delays can also vary. It could be part of terms of service that are negotiated when the use of the relay is arranged. That sort of arrangement might cover all these points. If you are looking for protocol mechanisms, we've discussed explicit signaling as an extension. A client could use something like (see ) to indicate that within the protocol[^1]. An explicit signal demonstrates awareness for those cases where the delay might be conditional. [^1]: Note also that this sort of signaling might imply a need for the relay to remove that field, though perhaps all clients add it and so it doesn't reveal anything if forwarded. Yes. Section 6.3 references back to this text, but it's worth mentioning the gateway too. There are many things that might feed into a padding strategy. Sometimes this is something the gateway will know because they are configured for a particular application and can look at the payload to determine how to best pad. Clients can probably signal (within encapsulation) what they might prefer, if that would help. Again, it's too application-specific to say much of use.
Martin, The comment it isn’t my comment. Maybe there is another Pwouters in github Kind regards Paul Verstuurd vanaf mijn iPad
My apologies. I definitely got the wrong person there.
thanks
Flipping to approve, with or without my suggestion. Sorry again for my confusion.

Discussion:
This privileged position allows for richer feature extraction from encrypted data, which might improve traffic analysis. <del> can use padding to reduce the effectiveness of traffic analysis. </del> <ins> and can use padding to reduce the effectiveness of traffic analysis. </ins> Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message
Change:
The client relies on a very specific form of trust here, though maybe they have other means to ensure compliance, it's trust that operates here.
Comment by NAME How could a client "ensure" that? Couldn't this at best be "unless the Client can trust that [...]"
(OK, edited this so that it only includes one comment, not two mangled together.) The answer here is down to trust, so this comment is right. Will fix.
looks good.

Discussion:
The request the sends to the only requires minimal information; see http-usage.  The request that carries the and is sent to the MUST NOT <del> include identifying information unless the ensures that this </del> <ins> include identifying information unless the can trust that this </ins> information is removed by the relay.  A MAY include information only for the in header fields identified by the Connection header field if it trusts the relay to remove these as required by Section 7.6.1 of
Change:
If the key identifier isn't known to the oblivious request resource, or the message can't be decrypted, it probably wants to send a clear signal. The signal is definitely not encapsulated at that point, so clients have limited options available to them. As a first-order suggestion, a 4xx status code generally indicates to the client that it might want to review the information it used. However, more specific error codes might help in specific cases that we deem important or common. Top of the list: when the identified key has been decommissioned.
How does sound in terms of saying "the content was unusable". We could go further and recommend the use of if you think more detail is needed.

Discussion:
protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. <ins> An oblivious request resource needs to have a plan for replacing keys.  This might include regular replacement of keys, which can be assigned new key identifiers.  If an oblivious request resource receives a request that contains a key identifier that it does not understand or that corresponds to a key that has been replaced, the server can respond with an HTTP 422 (Unprocessable Content) status code. A server can also use a 422 status code if the server has a key that corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. </ins> 8. Words...
Change:
"and a set HPKE" => "and a set of HPKE"
Thanks for the quick review and approval, NAME I haven't used the GitHub UI for submitting PRs in a long time so please pardon my lack of understanding here but I still don't see a way to merge the PR. Does it also need a review from NAME ?
NAME it doesn't technically need a review from Martin. The pattern we seem to have landed on is that one of us merges once both approve, but this is simple enough that I just merged it now. Thanks for sending the PR!

Discussion:
3.1. A single consists of a key identifier, a public key, an identifier <del> for the KEM that the public key uses, and a set HPKE symmetric </del> <ins> for the KEM that the public key uses, and a set of HPKE symmetric </ins> algorithms.  Each symmetric algorithm consists of an identifier for a KDF and an identifier for an AEAD.
Change:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.

Discussion:
Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct". <del> Concatenate the three values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </del> <ins> Concatenate the values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </ins> Note that "enc" is of fixed-length, so there is no ambiguity in parsing this structure.

In pseudocode, this procedure is as follows: <del> Servers MUST verify that the request padding consists of all zeroes before processing the corresponding Message. </del> 5.2. Given an HPKE context "context", a request message "request", and a

"enc_response" as follows: Export a secret "secret" from "context", using the string <del> "response" as a label.  The length of this secret is "Nk" - the length of an AEAD key assocated with "context". </del> <ins> "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". </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

The client uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows: <del> 5.3. Plaintext Messages support arbitrary length padding.  Clients and servers MAY pad HTTP messages as needed to hide metadata leakage through ciphertext length. </del> 6. A client interacts with the oblivious proxy resource by constructing
Change:
And recommend key rotation as a mitigation strategy.
Compromise of the client after it sends the request can be used to recover the keys used to decrypt (or falsify) the response.
NAME suggests that we need to consider how to time-bound server keys to limit the risk of secret key exposure.

Discussion:
The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed. <ins> 8.5. This design does not provide post-compromise security for responses. A client only needs to retain keying material that might be used compromise the confidentiality and integrity of a response until that response is consumed, so there is negligible risk associated with a client compromise. A server retains a secret key that might be used to remove protection from messages over much longer periods.  A server compromise that provided access to the oblivious request resource secret key could allow an attacker to recover the plaintext of all requests sent toward affected keys and all of the responses that were generated. Accessing requests and responses also requires access to requests and responses, which implies either compromise of TLS connections or collusion with the oblivious proxy resource. The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. </ins> 9. Please update the "Media Types" registry at
Change:
A server that wants to undermine this process can ensure that clients are provided with individual keys. Though there is a limited number of key identifiers (though see also ), a server could extend the number of identifiers with a little bit of trial decryption. Or the server could just use this ability selectively. Though the draft deliberately avoids talking about how clients learn about keys, we might talk about the implications of acquiring keys from servers. If the server is responsible for issuing keys, then the server can target individuals with specific keys. NAME suggests that maybe we could have the proxy provide keys. This is not a bad way to deal with this problem, though it places more trust in the proxy as the proxy now needs to be trusted not to provide a key for which it has the secret key. That might still work if the key could be further authenticated by the server, but that's a rabbit hole of its own.

Discussion:
9. <ins> One goal of this design is that independent client requests are only linkable by the chosen KeyConfig.  The oblivious proxy and request resources can link requests using the same KeyConfig by matching KeyConfig.key_id.  The oblivious proxy can also link requests using the public key corresponding to KeyConfig.key_id.  The proxy cannot determine precisely which public key was used to encapsulate a request, given that multiple public keys may have matching key identifiers. Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. Specifically, servers can maliciously construct KeyConfigs to track individual clients.  While KeyConfig discovery is outside the scope of this specification, clients should consider this tracking vector in deployments.  Applications using this design should provide accommodations to mitigation this tracking vector. 10. </ins> 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", "message/ohttp-res", and "application/ohttp-keys". <del> 10.  References </del> <ins> 11.  References </ins> <del> 10.1.  URIs </del> <ins> 11.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types
Change:
The whole mess that is key configuration discovery needs real work. There are cases where trust suffices, but we can't rely on that here. What this does is tweak the language to more clearly note the lines of responsibility for this draft. I also noted that we didn't talk about trial decryption and tracking, so I added that. It seemed like we didn't need to mention multiple keys with the same identifier twice after that.

Discussion:
In order to ensure that clients do not encapsulate messages that other entities can intercept, the key configuration MUST be <del> authenticated and have integrity protection.  One way to ensure integrity for key configuration is for the oblivious request resource to serve content to the client directly, using HTTPS and the "application/ohttp-keys" media type; see ohttp-keys. </del> <ins> authenticated and have integrity protection. This document describes the "application/ohttp-keys" media type; see ohttp-keys.  This media type might be used, for example with HTTPS, as part of a system for configuring or discovering key configurations.  Note however that such a system needs to consider the potential for key configuration to be used to compromise client privacy; see privacy. </ins> Specifying a format for expressing the information a client needs to construct an encapsulated request ensures that different client

9. One goal of this design is that independent client requests are only <del> linkable by the chosen KeyConfig.  The oblivious proxy and request resources can link requests using the same KeyConfig by matching KeyConfig.key_id.  The oblivious proxy can also link requests using the public key corresponding to KeyConfig.key_id.  The proxy cannot determine precisely which public key was used to encapsulate a request, given that multiple public keys may have matching key identifiers. </del> <ins> linkable by the chosen key configuration.  The oblivious proxy and request resources can link requests using the same key configuration by matching KeyConfig.key_id, or, if the oblivious target resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An oblivious proxy can link requests using the public key corresponding to KeyConfig.key_id. </ins> Request resources are capable of linking requests depending on how KeyConfigs are produced by servers and discovered by clients. <del> Specifically, servers can maliciously construct KeyConfigs to track individual clients.  While KeyConfig discovery is outside the scope of this specification, clients should consider this tracking vector in deployments.  Applications using this design should provide accommodations to mitigation this tracking vector. </del> <ins> Specifically, servers can maliciously construct key configurations to track individual clients.  A specific method for a client to acquire key configurations is not included in this specification.  Clients need to consider these tracking vectors when choosing a discovery method.  Applications using this design should provide accommodations to mitigate tracking. </ins> 10.
Change:
But they should. Consider the case where clients have equal-sized messages, but are making requests using different key identifiers or different request targets. If that information could be linked to certain clients, encryption would increase the size of the anonymity set from the perspective of a passive observer for little extra cost.
Done. PTAL.
Clients and proxies create independent TLS connections to the upstream node in the OHTTP chain. This raises some interesting questions: What if the trust stores between client and proxy are disjoint? What if the proxy completely disables server authentication in its connection to the target? The does not assume a secure connection between proxy and target, so I don't think this has an effect on the security properties of OHTTP. That said, it may be worth noting explicitly, if we don't already do so.
Yeah, the same applies here. We rely on the proxy not leaking certain information, but that does not necessarily extend to a reliance on TLS for that hop. Worth noting.

Discussion:
A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded <del> field FORWARDED, and any similar information. </del> <ins> field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </ins> 8.2.1.
Change:
I wanted to add more then just interception text here. So I added a little about performance and the ODoH study made some of those costs clear enough to cite. I anticipate this section growing over time. Some of the material we might add is already in other sections of the doc (DoS management at the proxy, for example), but we might move that around some. I also expect the working group to focus rather narrowly on this topic. Let's leave this open so that we have something to point to for IETF discussions.

Discussion:
10. <ins> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy 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. Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.  While TLS might be intercepted successfully, interception middleboxes devices might not receive updates that would allow Oblivious HTTP to be correctly identified using the media types defined in media-types. Oblivious HTTP has a simple key management design that is not trivially altered to enable interception by intermediaries.  Clients that are configured to enable interception might choose to disable Oblivious HTTP in order to ensure that content is accessible to middleboxes. 11. </ins> 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", "message/ohttp-res", and "application/ohttp-keys". <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://www.iana.org/assignments/media-types