Draft: draft-ietf-ohai-ohttp

Commentary: noted that it was important to note that the  needs to be trusted if gateway ! = target . As a practical matter , that means that you probably want gateway = = target . 
 Hi , Since the gateways are seeing request / response pairs , there is a potential here for a side - channel attack at the gateway itself or at a relay . ( if I understood the draft correctly - if not , please clarify my misunderstanding here ) . Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps ? 
 Does the new text in address this concern ? 
 I do n't think so , because the claim is the gateway does not have intimate knowledge of the contents of the request / response . If that assertion is true , the gateway should n't be able to ascertain information about the actual contents from those pairs ( directly or indirectly , via a side - channel attack ) . If the burden is on the application developer to ensure that request / response pairs traversing the gateway are to be resilient to side - channel attacks of those pairings , then it would be good to explicitly call that out in this spec ( perhaps in the security considerations section ? ) Thoughts ? 
 the gateway necessarily sees all request and response pairs , and will therefore always learn information about each transaction . This is fundamental to the design . Whether or not the gateway uses that information for malicious purposes , e.g. , by providing different responses to different requests for the same target resource , depends on the trust model . And the change in addresses that . I do n't think further text is needed here . 
 " Finally , a relay can also generate responses , though it assumed to not be able to examine the content of a request ( other than to observe the choice of key identifier , KDF , and AEAD ) , so it is also assumed that it can not generate an Encapsulated Response . " I feel that a relay could certainly perform a side - channel attack here as well using R / R pairings . 
 Can you please be more specific here ? What type of attack could the relay do to violate client privacy that is not already documented in the draft ? 
 Typically in HTTPs scenarios , it is more difficult to perform side channel attacks as a flow observer , especially if multiplexing of requests and responses are performed . In this design , if I understand it correctly , the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place . If my understanding of the protocol is incorrect here , please feel free to point that out . 
 You seem to be describing fingerprinting attacks , wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying ( unencrypted ) data . Yes , the relay does have a more fine - grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries , and that might impact the efficacy of these attacks . This is partly already addressed in the document : We could extend this to note the relay 's view of message boundaries . I do n't think any additional text is needed for the gateway . 
 Whatever you feel is best . I think some language around the message level risks this creates vs non - relay scenarios might be helpful . Does the client intentionally break things up in a way that crosses the underlying application message boundaries ( e.g. more like packetization ) with a relay ? I have more questions about the gateway functionality that we can discuss separately . 
 This means that the client really needs to trust that the gateway does n't muck with it . As a practical matter , this incentivizes clients to choose a gateway that is effectively the same entity as the target . They do n't have to , but the amount of trust required of the gateway is higher if gateway and target are n't operated by the same entity . We touch on this , but we could be clearer about it .
The Oblivious Gateway Resource can be operated by a different entity
than the Target Resource.  However, this means that the client needs
to trust the Oblivious Gateway Resource not to modify requests or
responses.  This analysis concerns itself with a deployment scenario
where a single server provides both the Oblivious Gateway Resource
and Target Resource.
Nonsecure requests - such those with the "http" scheme as opposed to
the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and
Target Resources are operated by different entities as that would
expose both requests and response to modification or inspection by a
network attacker.
A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect clients
or resources; see replay.
A server is responsible for either rejecting replayed requests or
ensuring that the effect of replays does not adversely affect clients
or resources.