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

Commentary: We 'll hold this for the ( inevitable ) next update of the draft .
Because do not authenticate the when using Oblivious HTTP, MUST
maintain an explicit allowlist of target resources that the trusts an
Oblivious Gateway to respond for, and check requests against this
allowlist before sending them.  This ensures that are not abused to
forward traffic to arbitrary Target Resources.  See server-
responsibilities for similar responsibilities that apply to .
Because do not authenticate the when using Oblivious HTTP, MUST have
some mechanism to authorize an for use with a . One possible means of
authorization is an allowlist.  This ensures that are not abused to
forward traffic to arbitrary Target Resources. server-
responsibilities describes similar responsibilities that apply to .
If separate entities provide the and , these entities might need an
arrangement similar to that between server and relay for managing
denial of service; see dos.  Moreover, the SHOULD apply some form of
allowlist to ensure that the is not misused as a relay for HTTP
messages to an arbitrary .
If separate entities provide the and , these entities might need an
arrangement similar to that between server and relay for managing
denial of service; see dos.  Moreover, the SHOULD have some mechanism
to ensure that the is not misused as a relay for HTTP messages to an
arbitrary , such as an allowlist.
Draft: draft-ietf-ohai-ohttp

Commentary: Especially where it is unnecessary and misleading . 
 Better :)
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".
Use the "Expand" function provided by the same KDF to create an
AEAD key, "key", of length "Nk" - the length of the keys used by
the AEAD associated with "context".  Generating "aead_key" uses a
label of "key".
Use the same "Expand" function to create a nonce, "nonce", of
length "Nn" - the length of the nonce used by the AEAD.
Generating "aead_nonce" uses a label of "nonce".
Draft: draft-ietf-ohai-ohttp

Commentary: Following up from It seems like the key configuration lists a set of potential HPKE algorithms that the client can use . The section does say " a selected combination of KDF , identified by  , and AEAD , identified by aeadid " , but it 's easy to miss the selected word and even then its not apparent as to what the selection is from . I think it could be made clearer that the client can choose from a list of HPKE algorithms specified in the Key Configuration .
a selected combination of KDF, identified by "kdf_id", and AEAD,
identified by "aead_id".
a combination of KDF, identified by "kdf_id", and AEAD, identified
by "aead_id", that the selects from those in the .
Draft: draft-ietf-ohai-ohttp

Commentary: Corrected to mention response freshness , with a new citation Added note about timing of a retry revealing RTT Corrected figure title grammar 
 Nice addition on RTT timing
Including a "Date" header field in the response allows the to correct
clock errors by retrying the same request using the value of the
"Date" field provided by the .  The value of the "Date" field can be
copied if the request is fresh, with an adjustment based on the "Age"
field otherwise.  When retrying a request, the MUST create a fresh
encryption of the modified request, using a new HPKE context.
Including a "Date" header field in the response allows the to correct
clock errors by retrying the same request using the value of the
"Date" field provided by the .  The value of the "Date" field can be
copied if the response is fresh, with an adjustment based on the
"Age" field otherwise; see HTTP-CACHING.  When retrying a request,
the MUST create a fresh encryption of the modified request, using a
new HPKE context.
Retrying immediately allows the to measure the round trip time to the
. The observed delay might reveal something about the location of the
.  could delay retries to add some uncertainty to any observed delay.
Draft: draft-ietf-ohai-ohttp

Commentary: This is n't a suggestion , it 's a real risk to consider .
Moreover, relays MAY apply differential treatment to that engage in
abusive behavior, e.g., by sending too many requests in comparison to
other , or as a response to rate limits signalled from the gateway.
Any such differential treatment can reveal information to the gateway
that would not be revealed otherwise and therefore reduce the size of
the anonymity set of using a gateway.  For example, if a relay
chooses to rate limit or block an abusive , this means that any
requests which are not treated this way are known to be non-abusive
by the gateway.  should consider the likelihood of such differential
treatment and the privacy risks when using a relay.
Moreover, relays MAY apply differential treatment to that engage in
abusive behavior, e.g., by sending too many requests in comparison to
other , or as a response to rate limits signalled from the gateway.
Any such differential treatment can reveal information to the gateway
that would not be revealed otherwise and therefore reduce the size of
the anonymity set of using a gateway.  For example, if a relay
chooses to rate limit or block an abusive , this means that any
requests which are not treated this way are known to be non-abusive
by the gateway.  need to consider the likelihood of such differential
treatment and the privacy risks when using a relay.
Draft: draft-ietf-ohai-ohttp

Commentary: " and a set HPKE " = " and a set of HPKE " 
 Thanks for the quick review and approval , I have n't used the GitHub UI for submitting PRs in a long time so please pardon my lack of understanding here but I still do n't see a way to merge the PR . Does it also need a review from ? 
 it does n'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 !
A single consists of a key identifier, a public key, an identifier
for the KEM that the public key uses, and a set HPKE symmetric
algorithms.  Each symmetric algorithm consists of an identifier for a
KDF and an identifier for an AEAD.
A single consists of a key identifier, a public key, an identifier
for the KEM that the public key uses, and a set of HPKE symmetric
algorithms.  Each symmetric algorithm consists of an identifier for a
KDF and an identifier for an AEAD.
Draft: draft-ietf-ohai-ohttp

Commentary: Comment by In How does a client know this ? Preconfiguration ? Are we talking ms ?  ? minutes ? Any advise to implementers ? 
 It ca n't be less than 2s , because the granularity of the field does n't permit detecting anything finer than 1s . I 've done what I can . 
 This still does not seem to address : Maybe just cut off the “ unless ” part if there is no signal for this ?  
 also included which I think should address your concern : 
 Thanks . That commit does address the issue , mostly . I guess it moves it do an unspecified provisioning layer :P
SHOULD include a "Date" header field in Encapsulated Requests, unless
the does not use "Date" for anti-replay purposes.
SHOULD include a "Date" header field in Encapsulated Requests, unless
the has prior knowledge that indicates that the does not use "Date"
for anti-replay purposes.
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.
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.  Beyond allowing for
multiple round trip times - to account for retransmission - network
delays are unlikely to be significant in determining the size of the
window, unless all potential are known to have excellent time-
keeping.  A specific window size might need to be determined
experimentally.
Draft: draft-ietf-ohai-ohttp

Commentary: This came out of , where we realized that the relay padding is useful , but needs to employ different methods than client or gateway . The relay ca n't use binary HTTP padding ; it has to insert stuff at the HTTP layer . Include citations for padding in those documents . Note that these citations are slightly misleading . Most relays wo n't have access at the level necessary to add that padding . More likely , the relay will need to do as originally suggested , namely adding fields of an appropriate size . But we do n't have good citations for that , so I 'm cheaping out . ( Note that RFC 9112 , Section 7.1.1 talks about using chunk extensions for padding , but I 'm going to pretend that does n't exist ; it 's even less usable than the HTTP/2 and HTTP/3 options . ) 
 Take it or leave it !
and can use padding to reduce the effectiveness of traffic analysis.
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
format might need to include padding support.
and can use padding to reduce the effectiveness of traffic analysis.
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
format might need to include padding support.  can also use padding
for the same reason, but need to operate at the HTTP layer since they
cannot manipulate binary HTTP messages; for example, see HTTP2 or
HTTP3).
Draft: draft-ietf-ohai-ohttp

Commentary: 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 How could a client " ensure " that ? Could n'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 .
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
include identifying information unless the ensures that this
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
HTTP.  The needs to trust that the relay does not replicate the
source addressing information in the request it forwards.
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
include identifying information unless the can trust that this
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
HTTP.  The needs to trust that the relay does not replicate the
source addressing information in the request it forwards.
Draft: draft-ietf-ohai-ohttp

Commentary: Dingledine2004 -DMS2004 ODoH -ODOH - PETS 
 Comment by ODOH and ODoH seems very similar and likely to cause confusion . Rename one ? 
 thanks 
 Comment by 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 . seems right , but it does n't bear a date and appears to be a rendering from which is in turn just a snapshot ( currently ) . Aside from referential stability , the specification is less of a useful reference as it says less about what  is and gets buried in detail . I 'm inclined to leave as - is , or switch to " [ DMS2004 ] " to reference all author 's names . 
 ok
Oblivious HTTP is primarily useful where privacy risks associated
with possible stateful treatment of requests are sufficiently large
that the cost of deploying this protocol can be justified.  Oblivious
HTTP is simpler and less costly than more robust systems, like Prio
(PRIO) or Tor (Dingledine2004), which can provide stronger guarantees
at higher operational costs.
Oblivious HTTP is primarily useful where privacy risks associated
with possible stateful treatment of requests are sufficiently large
that the cost of deploying this protocol can be justified.  Oblivious
HTTP is simpler and less costly than more robust systems, like Prio
(PRIO) or Tor (DMS2004), which can provide stronger guarantees at
higher operational costs.
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 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 and servers avoids
adding significant additional delay due to network topology.  A study
of a similar system ODOH-PETS found that deploying proxies close to
servers was most effective in minimizing additional latency.
Draft: draft-ietf-ohai-ohttp

Commentary: YES rather than DISCUSS is good . Good feedback is gooder . 
 LGTM , thanks
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 .
The identity of an that will accept relay requests carrying an as
its content and forward the content in these requests to a
particular .  Oblivious HTTP uses a one-to-one mapping between ;
see proxy-state for more details.
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are not on the same origin.  If messages are
forwarded between these resources without the protections afforded by
HTTPS, they could be inspected or modified by a network attacker.
Note that two resources that share an origin do not guarantee that
requests are not forwarded without protection.
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are not on the same origin.  If messages are
forwarded between these resources without the protections afforded by
HTTPS, they could be inspected or modified by a network attacker.
Note that a request could be forwarded without protection if the two
resources share an origin.
Draft: draft-ietf-ohai-ohttp

Commentary: LGTM pending suggestion
Secondly, generic implementations are often configured to augment
requests with information about the , such as the Via field or the
Forwarded field FORWARDED.  A relay MUST NOT add information when
forwarding requests that might be used to identify , with the
exception of information that a is aware of; see differential.
Secondly, generic implementations are often configured to augment
requests with information about the , such as the Via field or the
Forwarded field FORWARDED.  A relay MUST NOT add information when
forwarding requests that might be used to identify , except for
information that a is aware of; see differential.
Nonsecure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are not on the same origin.  If messages are
forwarded between these resources without the protections afforded by
HTTPS, they could be inspected or modified by a network attacker.
Note that a request could be forwarded without protection if the two
resources share an origin.
Non-secure requests - such as those with the "http" scheme as opposed
to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway
and Target Resources are not on the same origin.  If messages are
forwarded between these resources without the protections afforded by
HTTPS, they could be inspected or modified by a network attacker.
Note that a request could be forwarded without protection if the two
resources share an origin.
Each active configuration partitions the anonymity set.  In practice,
it is infeasible to reduce the number of active configurations to
one.  Enabling diversity in choice of naturally increases the number
of active configurations.  A small number of configurations might
need to be active to allow for key rotation and server maintenance.
Each active configuration partitions the anonymity set.  In practice,
it is infeasible to reduce the number of active configurations to
one.  Enabling diversity in choice of naturally increases the number
of active configurations.  More than one configuration might need to
be active to allow for key rotation and server maintenance.
Draft: draft-ietf-ohai-ohttp

Commentary: This did n't have subject - object agreement previously .
An can maintain state for requests for a small window of time over
which it wishes to accept requests.  The can store all requests it
processes within this window.  Storing just the "enc" field of a
request, which should be unique to each request, is sufficient.  The
then rejects requests if the request is the same as one that was
previously answered within that time window, or if the "Date" header
field from the decrypted request is outside of the current time
window.
An can maintain state for requests for a small window of time over
which it wishes to accept requests.  The can store all requests it
processes within this window.  Storing just the "enc" field of a
request, which should be unique to each request, is sufficient.  The
can reject any request that is the same as one that was previously
answered within that time window or if the "Date" header field from
the decrypted request is outside of the current time window.
Draft: draft-ietf-ohai-ohttp

Commentary: See commits for details .
Connections between the , , and MUST use HTTPS in order to provide
unlinkability in the presence of a network observer.  The scheme of
the determines what is used between the Oblivious Gateway and Target
Resources, though using HTTPS is RECOMMENDED; see server-
responsibilities.
Requests from the to and from to MUST use HTTPS in order to provide
unlinkability in the presence of a network observer.  The scheme of
the determines what is used between the Oblivious Gateway and Target
Resources, though using HTTPS is RECOMMENDED; see server-
responsibilities.
A relay MAY add information to requests if the is aware of the nature
of the information that could be added.  The does not need to be
aware of the exact value added for each request, but needs to know
the range of possible values the relay might use.  Importantly,
information added by the relay - beyond what is already revealed
through encapsulated requests from - can reduce the size of the
anonymity set of at a gateway.
A relay MAY add information to requests if the is aware of the nature
of the information that could be added.  Any addition MUST NOT
include information that uniquely and permanently identifies the ,
including any pseudonymous identifier.  Information added by the
relay - beyond what is already revealed through encapsulated requests
from - can reduce the size of the anonymity set of at a gateway.
A does not need to be aware of the exact value added for each
request, but needs to know the range of possible values the relay
might use.  How a might learn about added information is not defined
in this document.
Draft: draft-ietf-ohai-ohttp

Commentary: Why is it that media type registration is a journey of discovery each and every time ? It 's like the coastline paradox : the closer you get , the more detail resolves . Also , each requirement makes sense in isolation , but if you need an entire RFC to explain it , maybe something has gone wrong . 
 🤷 ‍no strong feelings on this one .
Create a receiving HPKE context by invoking "SetupBaseR()" (HPKE)
with "skR", "enc", and "info".  This produces a context "rctxt".
Create a receiving HPKE context, "rctxt", by invoking
"SetupBaseR()" (HPKE) with "skR", "enc", and "info".
The retains the HPKE context, "rctxt", so that it can encapsulate a
response.
decrypt an by reversing this process.  That is, they first parse
"enc_response" into "response_nonce" and "ct".  They then follow the
same process to derive values for "aead_key" and "aead_nonce".
decrypt an by reversing this process.  That is, first parse
"enc_response" into "response_nonce" and "ct".  They then follow the
same process to derive values for "aead_key" and "aead_nonce", using
their sending HPKE context, "sctxt", as the HPKE context, "context".
In order to achieve the privacy and security goals of the protocol a
also needs to observe the guidance in client-responsibilities.
In order to achieve the privacy and security goals of the protocol a
also needs to observe the guidance in sec-client.
The media type defined in ohttp-keys represents keying material.  The
content of this media type is not active (see RFC6838), but it
governs how a might interact with an .  The security implications of
processing it are described in sec-client; privacy implications are
described in privacy.
The security implications of handling the message media types defined
in req-res-media is covered in other parts of this section in more
detail.  However, these message media types are also encrypted
encapsulations of HTTP requests and responses.
HTTP messages contain content, which can use any media type.  In
particular, requests are processed by an Oblivious , which - as an
HTTP resource - defines how content is processed; see HTTP.  HTTP
clients can also use resource identity and response content to
determine how content is processed.  Consequently, the security
considerations of HTTP also apply to the handling of the content of
these media types.
Please update the "Media Types" registry at
https://iana.org/assignments/media-types [2] 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 [2] for the media types
"application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req),
and "message/ohttp-res" (iana-res), following the procedures of
RFC6838.