Open martinthomson opened 6 months ago
We did originally consider separate requests to better enforce the each-processed-independently goal. Factors we considered included:
These all combined to make it seem like the coalescing was worthwhile.
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.)
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.