Allow Veracruz programs to communicate with the outside world

[gbryant-arm]

The expressivity of Veracruz programs are controlled by the runtime. While this increases security guarantees, it limits their usability.
Is it possible to allow programs to communicate with the outside world (e.g. an external database) while controlling their expressivity? How?
This question introduces a whole bunch of challenges.

Enforcing traffic analysis on secure channels (e.g. TLS)

Programs should be able to communicate securely with an external server (e.g. a database). However malicious programs might want to collude with the external server to leak secret data or computation, hence the need to monitor communications.
TLS interception is a hot topic (cf. A survey and analysis of TLS interception mechanisms and motivations). Among the space of solutions, we could focus on the solutions implementing privacy-preserving network functions, in particular those leveraging TEEs (A Secure Middlebox Framework for Enabling Visibility Over Multiple Encryption Protocols is a good example).

This could take the form of an attestable, custom TLS stack running in the TEE, exposing an API to Veracruz programs and confidentially analysing plaintext traffic before it's encrypted (egress) or after it's decrypted (ingress).
Malicious programs can of course obfuscate their communications using steganography. There's no general solution against that although it could be mitigated by inspecting the programs.

Mitigating the linkability between a program and the external server, or the data provider and the external server

The external server communicating with the Veracruz programs may infer what program is being run based on the requests they make. Moreover, an attacker may trace a request back to the data provider by means of traffic correlation, thereby determining what computation the data provider is involved in.

Anonymity networks (Tor-like networks or proxies, or anything in between) could be used to mitigate the linkability between the data provider and the external server.
Additionally ORAM constructions could be leveraged to hide memory access patterns, therefore the real purpose of a request, from the untrusted external server.