jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-ohai-ohttp

Commentary: We debated this at some length . This defines an optional - to - use signaling method for the gateway so that it can inform the client when the key configuration is not acceptable . Clients can use this as a prompt to refresh their configuration . 
 ( Originally posted by in ): Any lifetime information that comes with a key is helpful , but in practice is insufficient for clients to drive key updates . Key rotation may not occur on a fixed schedule and it may not occur synchronously ( some gateway instances might not get the key at the right time . This means that clients can not distinguish between failures due to configuration mismatch or request tampering ( or whatever else might cause the gateway to reply without an encapsulated response ) . If the client ca n't distinguish then the client 's recovery implementation is a lot more complicated . Does it always try to forcibly update its configuration ? Does it implement some sort of backoff ? Can a relay abuse the client 's recovery implementation to somehow put the client into a state where it is stuck with an old configuration ? It seems vastly simpler to just be clear that the configuration is wrong as a signal to the client that it 's time to update . This was done in ODoH with a 401 response code . proposed a new problem statement , which I think is the right way to deal with this . Yes , there are potential privacy problems based on automated updates , but those depend on the client 's consistency story and is therefore not something new a signal would introduce . 
 This looks great -- thanks !
The problem type PROBLEM of "https://iana.org/assignments/http-
problem-types#ohttp-key" is defined.  An MAY use this problem type in
a response to indicate that an used an outdated or incorrect .
fig-key-problem shows an example response in HTTP/1.1 format.
As this response cannot be encrypted, it might not reach the .  A
cannot rely on the using this problem type.  A might also be
configured to disregard responses that are not encapsulated on the
basis that they might be subject to observation or modification by an
.  A might manage the risk of an outdated using a heuristic approach
whereby it periodically refreshes its if it receives a response with
an error status code that has not been encapsulated.
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).
Please update the "Media Types" registry at
https://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).
Please update the "HTTP Problem Types" registry at
https://iana.org/assignments/http-problem-types [2] for the types
"date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key).
IANA are requested to create a new entry in the "HTTP Problem Type"
registry established by PROBLEM.
Draft: draft-ietf-ohai-ohttp

Commentary: This starts by moving the good text from to the " Errors " section , where I realized that it duplicated some of that language . It was more complete , so I merged the two . I then some language about what happens to errors prior to decapsulation . This does n't define an error signaling format . Though that might be useful , it is also a lot more work and I 'm leery of scope creep in this document . My view : if you get an error , you have screwed up somewhere . You probably want to have a human look at what is going on . The privacy consequences of automated responses are difficult to work out properly . Hence this proposed change . 
 This is an improvement but still insufficient with respect to configuration mismatch signaling . 
 Let 's start with this one and I 'll look at addressing the open issue in a follow - up . 
 Thanks , I think this is clear enough now .
Errors detected by the after successfully removing encapsulation and
errors detected by the MUST be sent in an .
Errors detected by the after successfully removing encapsulation and
errors detected by the MUST be sent in an .  This might be because
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.
Errors in the encapsulation of requests mean that responses cannot be
encapsulated.  This includes cases where the is incorrect or
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.
Draft: draft-ietf-ohai-ohttp

Commentary: These bits are not connected to the rest of it and are unambiguously good .
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which must be used in conjunction with applications that do not carry
state between requests.
Oblivious HTTP has limited applicability.  Many uses of HTTP benefit
from being able to carry state between requests, such as with cookies
(RFC6265), authentication (HTTP), or even alternative services
(RFC7838).  Oblivious HTTP removes linkage at the transport layer,
which is only useful for an application that does not carry state
between requests.
Each request requires at least two regular HTTP requests, which
adds latency.
Each request requires at least two regular HTTP requests, which
could increase latency.
Draft: draft-ietf-ohai-ohttp

Commentary: RFC 9180 does use skR / pkR / skS / skR , so I did n'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 do n't have to grapple with whether it should be keyId or keyID .
the key identifier from the configuration, "keyID", with the
corresponding KEM identified by "kemID",
a selected combination of KDF, identified by "kdfID", and AEAD,
identified by "aeadID".
Construct a message header, "hdr", 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.
the key identifier from the configuration, "key_id", with the
corresponding KEM identified by "kem_id",
a selected combination of KDF, identified by "kdf_id", and AEAD,
identified by "aead_id".
Construct a message header, "hdr", by concatenating the values of
"key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer
and three 16-bit integers, respectively, each in network byte
order.
Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID",
"enc", and "ct" (indicated using the function "parse()" in
pseudocode).  The server is then able to find the HPKE private
key, "skR", corresponding to "keyID".
a.  If "keyID" does not identify a key matching the type of
"kemID", the server returns an error.
b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD
that the server is unwilling to use with "skR", the server returns
an error.
Build "info" by concatenating the ASCII-encoded string "message/
bhttp request", a zero byte, "keyID" as an 8-bit integer, plus
"kemID", "kdfID", and "aeadID" as three 16-bit integers.
Parses "enc_request" into "key_id", "kem_id", "kdf_id", "aead_id",
"enc", and "ct" (indicated using the function "parse()" in
pseudocode).  The server is then able to find the HPKE private
key, "skR", corresponding to "key_id".
a.  If "key_id" does not identify a key matching the type of
"kem_id", the server returns an error.
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.
Build "info" by concatenating the ASCII-encoded string "message/
bhttp request", a zero byte, "key_id" as an 8-bit integer, plus
"kem_id", "kdf_id", and "aead_id" as three 16-bit integers.
Draft: draft-ietf-ohai-ohttp

Commentary: This was the only case we used the TLS - style dot notation , but we do n't need to pull in a new concept .
Oblivious Relay and Gateway Resources can identify when requests use
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.
Oblivious Relay and Gateway Resources can identify when requests use
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.
Draft: draft-ietf-ohai-ohttp

Commentary: In Deployment Considerations / Performance Overhead ... Should that be " cryptographic " -"cryptographic complexity " or something like that ? 
 It should probably be " cryptographic overhead . " Nice catch !
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.
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.
Draft: draft-ietf-ohai-ohttp

Commentary: I presume the idea here is to add jitter to the system ( different delays for different requests ) rather than compound delays on a single request ? Even if not , this paragraph could probably benefit from some language fixups . There 's a missing word and " might not be what some clients want " could benefit from a rephrasing to make it stronger . 
 clearer , thanks
A relay could, as part of its function, add delays in order to
increase the anonymity set into which each message is attributed.
This could latency to the overall time clients take to receive a
response, which might not be what some clients want.
A relay could, as part of its function, delay requests before
forwarding them.  Delays might increase the anonymity set into which
each request is attributed.  Any delay also increases the time that a
client waits for a response, so delays SHOULD only be added with the
consent - or at least awareness - of clients.
Draft: draft-ietf-ohai-ohttp

Commentary: 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
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.
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
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.
Draft: draft-ietf-ohai-ohttp

Commentary: 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
dos.  It is also necessary to provide confidentiality protection for
the unprotected requests and responses, plus protections for traffic
analysis; see ta.
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
dos.
Draft: draft-ietf-ohai-ohttp

Commentary: 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 .
In order to achieve the privacy and security goals of the protocol a
client also needs to observe the guidance in client-responsibilities.
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.
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.
Draft: draft-ietf-ohai-ohttp

Commentary: Not even once , down from two . Using cookies is dumb , but we do n'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 does n'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 .
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.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the relay responsible for the
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.
Clients cannot carry connection-level state between requests as they
only establish direct connections to the relay responsible for the
Oblivious Relay resource.  However, the content of requests might be
used by a server to correlate requests.  Cookies COOKIES are the most
obvious feature that might be used to correlate requests, but any
identity information and authentication credentials might have the
same effect.  Clients also need to treat information learned from
responses with similar care when constructing subsequent requests,
which includes the identity of resources.
Draft: draft-ietf-ohai-ohttp

Commentary: 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
the AEAD associated with "context".  Generating "key" uses a label
of "key".
Use the same "Expand" function to extract a nonce "nonce" of
length "Nn" - the length of the nonce used by the AEAD.
Generating "nonce" uses a label of "nonce".
Encrypt "response", passing the AEAD function Seal the values of
"key", "nonce", empty "aad", and a "pt" input of "request", which
yields "ct".
Use the "Expand" function provided by the same KDF to extract an
AEAD key "key", of length "Nk" - the length of the keys used by
the AEAD associated with "context".  Generating "aead_key" uses a
label of "key".
Use the same "Expand" function to extract a nonce "nonce" of
length "Nn" - the length of the nonce used by the AEAD.
Generating "aead_nonce" uses a label of "nonce".
Encrypt "response", passing the AEAD function Seal the values of
"aead_key", "aead_nonce", an empty "aad", and a "pt" input of
"response", which yields "ct".
Draft: draft-ietf-ohai-ohttp

Commentary: 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 does n't use the term either . Doing some digging , it seemed like an older draft defined this term ( and others ) ; see But it seems like you moved away from that and this is a hangover 
 So this is n'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 ca n't vouch for the correctness of the crypto pieces though
Formats are described using notation from QUIC.
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.
The Nenc parameter corresponding to the HpkeKdfId can be found in
HPKE.
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.
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.
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).
Draft: draft-ietf-ohai-ohttp

Commentary: The text noted in was correct , but we did n'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 would n't really care . Now , perhaps I 'm mistaken and oHTTP does mandate TLS . If so , perhaps I 'm overlooking it . states many requirements but not the use of HTTPS . That seems implicit via However , that seems in conflict with , which says In summary , there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations .
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.
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.
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.
Draft: draft-ietf-ohai-ohttp

Commentary: error on first character of spec body . Made my day 
 Technically the second character ...
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.
An 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.