Draft: draft-ietf-ohai-ohttp

Commentary: This talks about the odd case where target and gateway are separate . The primary insight here is that the target is just a regular HTTP resource and the requests from the gateway are n't special . Problems only occur if the gateway is privileged in some way . If abuse comes via the gateway , then the target would ordinary block the client , which tends to affect a bunch of bystanders in this model . So there is pressure to do something special for the gateway . In that case , the target is trusting the gateway in some way . Explain that . The heading here is the only case where we use the short names of the entities , but I ca n't stand short headings . 
 The changes are a big step forward in the right direction , but the flow seems a little weird as the text in the first part of the security section is about co - located gateway / target . Strongly suggest to move the new text at the end of the whole section and add a forward reference in the text : ( from the intro in the security section ) 
 And , just to be clear , the PR text addresses my concern . My comment about the flow is just editorial . 
 I 've taken the suggestion to move the text ( with forward references ) and made a few tweaks : . and rewritten some text from the top of the security considerations that better fit the new section . a forward reference to this section . and rewritten text in to the applicability section . ( Originally this was just to correct a misspelling , but I think this makes more sense in the new home . ) can you double - check my work . With this , I think we 're ready to revise the draft and ask the IESG to finalize their ballot .
This interaction provides authentication and confidentiality
protection between the and the Oblivious Gateway, but importantly not
between the and the . While the is a distinct HTTP resource from the
, they are both logically under the control of the Oblivious Gateway,
since the can unilaterally dictate the responses returned from the to
the . This arrangement is shown in fig-overview.  See security for
more information about and Oblivious Relay, and Oblivous Gateway
resources in running this protocol.
This interaction provides authentication and confidentiality
protection between the and the Oblivious Gateway, but importantly not
between the and the . While the is a distinct HTTP resource from the
, they are both logically under the control of the Oblivious Gateway,
since the can unilaterally dictate the responses returned from the to
the . This arrangement is shown in fig-overview.
In addition to these limitations, security describes operational
constraints that are necessary to realize the goals of the protocol.
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.
separate-target discusses the security implications for a case where
different servers operate the and .
Requests from the to and from to MUST use HTTPS in order to provide
unlinkability in the presence of a network observer.
This document generally assumes that the same entity operates the and
the .  However, as the performs generic HTTP processing, the use of
forwarding cannot be completely precluded.
The scheme specified in the determines the security requirements for
any protocol that is used between the Oblivious Gateway and Target
Resources.  Using HTTPS is RECOMMENDED; see server-responsibilities.
A that is operated on a different server from the is an ordinary HTTP
resource.  A can privilege requests that are forwarded by a given if
it trusts the operator of the to only forward requests that meet the
expectations of the .  Otherwise, the treats requests from an no
differently than any other HTTP client.
For instance, an might - possibly with the help of - be trusted not
to forward an excessive volume of requests.  This might allow the to
accept a greater volume of requests from that relative to other HTTP
clients.
An could implement policies that improve the ability of the to
implement policy exemptions, such as only forwarding requests toward
specific Target Resources according to an allowlist; see server-
responsibilities.