Draft: draft-ietf-ohai-ohttp

Commentary: 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 . 
 LGTM . Spelling out names in full is a pain , but probably worthwhile .
This document assumes that all communication between different
entities 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.
As the time at which Encapsulated Request or response messages are
sent can reveal information to a network observer.  Though messages
exchanged between the Oblivious Relay Resource and the Oblivious
Gateway Resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
relay.
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.
The time at which Encapsulated Request or response messages are sent
can reveal information to a network observer.  Though messages
exchanged between the Oblivious Relay Resource and the Oblivious
Gateway Resource might be sent in a single connection, traffic
analysis could be used to match messages that are forwarded by the
relay.
A relay can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.
Traffic analysis is not restricted to network observers.  A malicious
Oblivious Relay Resource could use traffic analysis to learn
information about otherwise encrypted requests and responses relayed
between clients and gateways.  An Oblivious Relay Resource terminates
TLS connections from clients, so they see message boundaries.  This
privileged position allows for richer feature extraction from
encrypted data, which might improve traffic analysis.
Clients can use padding to reduce the effectiveness of traffic
analysis.  Padding is a capability provided by binary HTTP messages;
see BINARY.