Coalescing requests

[martinthomson]

The design of the key-value server API, version 2, appears to include a way to bundle parallel requests in the same request. As a general rule, we tend to advise people using HTTP not to do that sort of thing. If the content needs to be processed independently, then separate requests is generally a good idea.

There is a traffic analysis exposure when multiple requests are made. Intermediaries will be able to observe the size of the separate queries and learn more information. In this case, the intermediary is the code that runs outside of the TEE. Request coalescing in HTTP can help protect against on-path attackers, but the operator of the TEE will learn sizes. I don't know whether this is enough of a serious attack to justify the bundling feature though.

[michaelkleber]

We did originally consider separate requests to better enforce the each-processed-independently goal. Factors we considered included:

1. People were sometimes in a very large number of Interest Groups, so that separating requests might kick up the Queries Per Second of the K/V server by a factor of 100. That amount of overhead seemed prohibitive on its own.
2. As you pointed out, the information leakage from lengths of 100 separate requests is substantially larger than from one request with the encrypted concatenation of their payloads.
3. The server running in the TEE includes infrastructure that we can guarantee breaks up the request so that each piece is processed independently (if you believe in TEE remote attestation in the first place).

These all combined to make it seem like the coalescing was worthwhile.

[martinthomson]

Under the threat model in which buyers and sellers are potentially malicious, how does this coalescing concretely help? Or is it only effective in non-malicious cases? That is, I don't see any way to prevent disaggregation if the buyers and sellers want it that way.

If there is mitigation for that sort of attack, it might pay to build a more intentional coalescing layer for TEE communication. What exists in the current design is a little hard to disentangle from its usage context. (That's a personal preference, but I find that reusable widgets with well-understood properties tend to hide complexity behind useful abstractions. And they tend to find other applications.)