Potential Side-channel attacks...

[vparla]

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?

[martinthomson]

Does the new text in #143 address this concern?

[vparla]

I don'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 shouldn'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?

[chris-wood]

@vparla 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 #143 addresses that. I don't think further text is needed here.

[vparla]

"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 cannot generate an Encapsulated Response."
I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.

[chris-wood]

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?

[vparla]

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.

[chris-wood]

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:

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.

We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.

[vparla]

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.