jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-thomson-http-oblivious

Commentary: This may not be obvious , so perhaps good to note . 
 I 'll move most of the text to the client section , leaving a pointer in the proxy section . 
 It probably depends . One could fetch the HPKE key and apply policy for each OHTTP message , which would be equivalent to applying policy for each HTTP connection if you were not using OHTTP , or one could fetch and apply policy to the HPKE key for many OHTTP messages . The results are different . 
 this should be good to go . 
 Thanks for changing it up . I 'm not 100 % on the structure of this yet , but it is more important to get the info in place .
Since clients connect directly to the proxy instead of the target,
application configurations wherein clients make policy decisions
about target connections, e.g., to apply certificate pinning, are
incompatible with Oblivious HTTP.  In such cases, alternative
technologies such as HTTP CONNECT (Section 9.3.6 of HTTP) can be
used.  Applications could implement related policies on key
configurations and proxy connections, though these might not provide
the same properties as policies enforced directly on target
connections.  When this difference is relevant, applications can
instead connect directly to the target at the cost of either privacy
or performance.
Draft: draft-thomson-http-oblivious

Commentary: I wanted to add more then just interception text here . So I 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 .
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.
Draft: draft-thomson-http-oblivious

Commentary: This was vague enough that an example might help . 
 Yeah , this seems good . Do we want to explicitly mention cookies ?
Clients MUST NOT include identifying information in the request that
is encapsulated.
Clients MUST NOT include identifying information in the request that
is encapsulated.  Identifying information includes cookies COOKIES,
authentication credentials or tokens, and any information that might
reveal client-specific information such as account credentials.
Draft: draft-thomson-http-oblivious

Commentary: Just a few things I noticed when going through .
A client or oblivious proxy resource MUST NOT automatically attempt
to retry a failed request unless it receives a positive signal
indicating that the request was not processed or forwarded.  The
HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or
a GOAWAY frame (in either protocol version) are all sufficient
signals that no processing occurred.  Connection failures or
interruptions are not sufficient signals that no processing occurred.
The anti-replay mechanisms described in Section 8 of TLS are
generally applicable to oblivious HTTP requests.  Servers can use the
encapsulated keying material as a unique key for identifying
potential replays.
A client or oblivious proxy resource MUST NOT automatically attempt
to retry a failed request unless it receives a positive signal
indicating that the request was not processed or forwarded.  The
HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of 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.
The anti-replay mechanisms described in Section 8 of TLS are
generally applicable to oblivious HTTP requests.  Servers can use the
encapsulated keying material as a unique key for identifying
potential replays.  This depends on clients generating a new HPKE
context for every request.
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients.  A specific method for a client to acquire
key configurations is not included in this specification.  Clients
need to consider these tracking vectors when choosing a discovery
method.  Applications using this design should provide accommodations
to mitigate tracking.
Request resources are capable of linking requests depending on how
KeyConfigs are produced by servers and discovered by clients.
Specifically, servers can maliciously construct key configurations to
track individual clients.  A specific method for a client to acquire
key configurations is not included in this specification.  Clients
need to consider these tracking vectors when choosing a discovery
method.  Applications using this design should provide accommodations
to mitigate tracking use key configurations.
Draft: draft-thomson-http-oblivious

Commentary: 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 do n't think this has an effect on the security properties of OHTTP . That said , it may be worth noting explicitly , if we do n'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 .
A proxy MUST NOT add information about the client identity when
forwarding requests.  This includes the Via field, the Forwarded
field FORWARDED, and any similar information.
A proxy MUST NOT add information about the client identity when
forwarding requests.  This includes the Via field, the Forwarded
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.
Draft: draft-thomson-http-oblivious

Commentary: and . Given ( either assuming a fixed key ID , or looking up the KEM based on key ID ) , I think this is a nice simplification . It also authenticates more , even if redundant . ( The kemID is already part of the HPKE key schedule . ) I implemented this change and it 's straightforward . 
 Currently , an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request . This means that code parsing a request needs to know the ID -KEM mapping in order to parse things correctly , which is somewhat annoying . I propose we add KEMID to the request so that this mapping is n't needed to just parse the message . As a bonus , that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID . 
 We currently length - prefix it , but we do n't have to . Think about this a little . 
 Both the public key and encapsulated secret are fixed length . I think making these fixed length on the wire is good . However , it does require the parsing code to know the corresponding size , which depends on the KEM . This requires there to be a function to map the kem_id to the corresponding size(s ) . do you have such an API in your implementation ? I have one in mine , which would make this pretty straightforward to implement .
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF,
and AEAD respectively.  The definitions for these identifiers and the
semantics of the algorithms they identify can be found in HPKE.
The types HpkeKemId, HpkeKdfId, and HpkeAeadId identify a KEM, KDF,
and AEAD respectively.  The definitions for these identifiers and the
semantics of the algorithms they identify can be found in HPKE.  The
Npk parameter corresponding to the HpkeKdfId can be found in HPKE.
The Nenc parameter corresponding to the HpkeKdfId can be found in
HPKE.
the key identifier from the configuration, "keyID",
the key identifier from the configuration, "keyID", with the
corresponding KEM identified by "kemID",
Construct associated data, "aad", by concatenating the values of
"keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers
respectively, each in network byte order.
Construct associated data, "aad", by concatenating the values of
"keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and
three 16-bit integers, respectively, each in network byte order.
Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and
"ct" (indicated using the function "parse()" in pseudocode).  The
server is then able to find the HPKE private key, "skR",
corresponding to "keyID".
a.  If "keyID" does not identify a key, the server returns an
error.
Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID",
"enc", and "ct" (indicated using the function "parse()" in
pseudocode).  The server is then able to find the HPKE private
key, "skR", corresponding to "keyID".
a.  If "keyID" does not identify a key matching the type of
"kemID", the server returns an error.
Draft: draft-thomson-http-oblivious

Commentary: 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 . 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 .
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.
Draft: draft-thomson-http-oblivious

Commentary: 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 . 
 suggests that we need to consider how to time - bound server keys to limit the risk of secret key exposure .
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.
Draft: draft-thomson-http-oblivious

Commentary: This is n't anything that special , but this is a case where a bunch of our established defenses do n't work . 
 The new changes LGTM . Feel free to merge assuming you 're done with edits ! 
 This means that servers need anti - replay protections , especially if they are performing non - idempotent operations .
Encapsulated requests can be copied and replayed by the oblivious
proxy resource.  The design of oblivious HTTP does not assume that
the oblivious proxy resource will not replay requests.  In addition,
if a client sends an encapsulated request in TLS early data (see
Section 8 of TLS and RFC8470), a network-based adversary might be
able to cause the request to be replayed.  In both cases, the effect
of a replay attack and the mitigations that might be employed are
similar to TLS early data.
A client or oblivious proxy resource MUST NOT automatically attempt
to retry a failed request unless it receives a positive signal
indicating that the request was not processed or forwarded.  The
HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the
HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or
a GOAWAY frame (in either protocol version) are all sufficient
signals that no processing occurred.  Connection failures or
interruptions are not sufficient signals that no processing occurred.
The anti-replay mechanisms described in Section 8 of TLS are
generally applicable to oblivious HTTP requests.  Servers can use the
encapsulated keying material as a unique key for identifying
potential replays.
The mechanism used in TLS for managing differences in client and
server clocks cannot be used as it depends on being able to observe
previous interactions.  Oblivious HTTP explicitly prevents such
linkability.  Applications can still include an explicit indication
of time to limit the span of time over which a server might need to
track accepted requests.  Clock information could be used for client
identification, so reduction in precision or obfuscation might be
necessary.
The considerations in RFC8470 as they relate to managing the risk of
replay also apply, though there is no option to delay the processing
of a request.
Limiting requests to those with safe methods might not be
satisfactory for some applications, particularly those that involve
the submission of data to a server.  The use of idempotent methods
might be of some use in managing replay risk, though it is important
to recognize that different idempotent requests can be combined to be
not idempotent.
Idempotent actions with a narrow scope based on the value of a
protected nonce could enable data submission with limited replay
exposure.  A nonce might be added as an explicit part of a request,
or, if the oblivious request and target resources are co-located, the
encapsulated keying material can be used to produce a nonce.
The server-chosen "response_nonce" field ensures that responses have
unique AEAD keys and nonces even when requests are replayed.
Draft: draft-thomson-http-oblivious

Commentary: Just a missing word and some stuff that seemed like it could be better .
If a server does accept a large volume of requests from a proxy, it
needs to trust that the proxy does not allow abusive levels of
request volumes from clients.  That is, if a server allows requests
from the proxy to be exempt from rate limits, the server might want
to ensure that the proxy applies similar rate limiting when receiving
requests from clients.
If a server accepts a larger volume of requests from a proxy, it
needs to trust that the proxy does not allow abusive levels of
request volumes from clients.  That is, if a server allows requests
from the proxy to be exempt from rate limits, the server might want
to ensure that the proxy applies a rate limiting policy that is
acceptable to the server.
A proxy could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not what some clients want.
A proxy could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not be what some clients want.
Draft: draft-thomson-http-oblivious

Commentary: This is more background than I would normally like to include , but it seems prudent at this stage . The example usage bit might go eventually , but I can see us keeping some sort of applicability statement . 
 I recognize that / some conditions and use cases , but it would help readers like me to have even more . A separate   / readme would be fine too . In the meeting chat today , I heard the suggestion of requesting map tiles as another use case , which makes sense to me : asking for map tiles is itself pretty revealing if connected to the user 's identity ( it might reveal your current location , or a location where you 're going to be ) and can be pretty transactional / stateless . Maybe search queries are similar . Safe browsing lookups was also mentioned . Having more example use cases might help in resolving other questions , like whether to support multiple HTTP requests at a time , or non - HTTP message bodies , etc . Ideally , we could explain the conditions under which adoption of ohttp will be useful -- maybe , a privacy need for reducing linkability of multiple requests or of a single request from user identity , and HTTP requests that are typically stateless or single - shot in some way , and frequent or performant - requiring at a certain level . 
 some more examples . I think we can safely close this now , so I 'm going to go ahead and do that . Please reopen with concrete suggestions if you think the new text is insufficient ! 
 A little more text on the narrow applicability of this would be helpful . Some people originally interpreted this as having broader application than was ever intended . 
 can we close this with ? 
 Yep . I forgot to link it .
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (Section 11 of I-D.ietf-httpbis-semantics),
or even alternative services (RFC7838).  Oblivious HTTP seeks to
prevent this sort of linkage, which requires that applications not
carry state between requests.
Oblivious HTTP is primarily useful where privacy risks associated
with possible stateful treatment of requests are sufficiently
negative that the cost of deploying this protocol can be justified.
Oblivious HTTP is simpler and less costly than more robust systems,
like Prio (PRIO) or Tor (Dingledine2004), which can provide stronger
guarantees at higher operational costs.
Each oblivious request requires at least two regular HTTP
requests, which adds latency.
Each request is expanded in size with additional HTTP fields,
encryption-related metadata, and AEAD expansion.
Deriving cryptographic keys and applying them for request and
response protection takes non-negligible computational resources.
DNS queries.  DNS queries made to a recursive resolver reveal
information about the requester, particularly if linked to other
queries.
Telemetry submission.  Applications that submit reports about
their usage to their developers might use oblivious HTTP for some
types of moderately sensitive data.
Draft: draft-thomson-http-binary-message

Commentary: Stupid grammar stuff in the published version .
The content of messages is a sequence of bytes of any length.  Though
a known-length message has a limit, this limit is large enough that
it is unlikely to be a practical limitation.  There is there is no
limit to an indeterminate length message.
The content of messages is a sequence of bytes of any length.  Though
a known-length message has a limit, this limit is large enough that
it is unlikely to be a practical limitation.  There is no limit to
the size of content in an indeterminate length message.
Valid HTTP/1.1 messages require lines terminated with CRLF (the two
bytes 0x0a and 0x0d).  For simplicity and consistenct, the content of
these examples is limited to text, which also uses CRLF for line
endings.
Valid HTTP/1.1 messages require lines terminated with CRLF (the two
bytes 0x0a and 0x0d).  For simplicity and consistency, the content of
these examples is limited to text, which also uses CRLF for line
endings.
Draft: draft-thomson-http-oblivious

Commentary: 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 ca n't be used with multiple KEMs . 
 In principle it might be possible , but I think we should prohibit it .
Concatenate the three values of "aad", "enc", and "ct", yielding
an Encapsulated Request "enc_request".
Concatenate the values of "aad", "enc", and "ct", yielding an
Encapsulated Request "enc_request".
Servers MUST verify that the request padding consists of all zeroes
before processing the corresponding Message.
Export a secret "secret" from "context", using the string
"response" as a label.  The length of this secret is "Nk" - the
length of an AEAD key assocated with "context".
Export a secret "secret" from "context", using the string
"response" as context.  The length of this secret is "max(Nn,
Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce
associated with "context".
Plaintext Messages support arbitrary length padding.  Clients and
servers MAY pad HTTP messages as needed to hide metadata leakage
through ciphertext length.