Venue: ICLR 2020 Conference

Reviews:

final_score: rating: null
review_content: I thank the authors for the detailed rebuttal.
Nevertheless, I think that many misconceptions remain, which I describe below:

* On the LAN vs WAN setting:
While one issue in a WAN is bandwidth, the much bigger problem is *latency*. After every layer, the server hosting the SGX enclave has to send data to the server hosting the second GPU, and wait for the GPU's reply before moving on to the next layer. In a WAN, the roundtrip latency will be in the 5-150 millisecond range depending on how geographically close the servers are. Now, multiply this by the number of layers. Running the entire computation inside SGX will always be faster.

Your rebuttal mentions the need of a good network line. Paying more money will indeed get you more bandwidth, but latency is fundamentally limited by the speed of light.
    
* On non-collusion in a LAN:
The real-world example you give with Facebook's password protections doesn't really relate to your case. Here, Facebook is trying to protect against an outsider adversary. But Facebook obviously has access to the contents of both servers, so this doesn't protect the data from Facebook.
The challenge in Goten is to make sure that no single entity can see the data processed by the two GPUs. If these two GPUs both belong to the same company (e.g., Facebook), then you need to trust that company for privacy. But if you do trust this company for privacy, you can just have them run the entire computation in the clear.
    
* On access control:
You mention that one way to ensure non-collusion within an organization is to enforce access-control of the servers. Again, this doesn't actually provide any security from the organization itself, which is in charge of the access control. But even so, at this point you could also just run the whole computation in the clear in a single GPU (without SGX) and restrict access to this GPU using the same access control strategies. Using two servers and SGX doesn't buy you anything in this scenario.
    
* On optimizing CaffeScone:
Even if optimizing this baseline is not the main goal of your paper, it is still necessary to make the point that Goten is practical. The question is basically: if a company wants to spend resources to deploy private ML, should they implement an optimized Goten, or an optimized CaffeScone? If the optimized CaffeScone achieves similar performance, they'll be more likely to use that as it is much simpler to deploy and doesn't require non-colluding servers.
review_title: Response to author comments

final_score: rating: 1: Reject
review_content: The paper proposes a method for privacy-preserving training and evaluation of DNNs. The method is based on a combination of hardware support from a trusted execution enclave (Intel SGX) and an algorithm for offloading intensive computation to unsecure GPU devices and communicating with the trusted environment without losing security guarantees during communication.  Compared to related work on a similar system (Slalom), the proposed system enables secure training in addition to inference.  The approach is based on the use of additive secret sharing to relegate chunks of computation to independent GPU servers.

The evaluation presents experiments that report timings of the proposed system against a baseline. Throughput (images/second) improvements of 8-9x are reported, but the contrast point is unclear (it appears to be CaffeSCONE, but there are several unclear points, summarized below). In addition, a set of results reporting a speed up ratio against attained accuracy of a trained VGG11 network, and a set of results reporting speed up against arithmetic intensity of the workload are given.

I lean towards rejection of this draft, as it has several weaknesses:
- The connection between the evaluation (which mostly focuses on the speed benefits) and the claimed contributions is tenuous at best. This issue is further compounded by clarity issues in the experiments and their description
- The empirical results are unclear due to differences between simulation of SGX capability vs hardware support of SGX capability. It is not clear what part of the results is influenced significantly by this disparity, and more importantly whether all the comparisons are done in an equal footing (for example the reported results comparing CaffeSCONE with Goten are performed in two different regimes). As a byproduct, there is a confusing "scaling factor" described by the authors that is applied to the timings.
- A brief mention is made of the fact that the proposed system does not in fact provide correctness guarantees (unlike CaffeSCONE), but this is dismissed by reference to utilizing the same trick used by Slalom.  However, this trick is not described or motivated.
- The writing in the current draft is of relatively low quality, significantly impacting the readability of the paper and making it hard to understand the contributions and whether they are backed by the presented results.

review_title: Official Blind Review #2

final_score: rating: 6: Weak Accept
review_content: The paper builds a privacy-preserving training framework within a Trusted Execution Environment (TEE) such as Intel SGX. The work is heavily inspired from Slalom, which does privacy-preserving inference in TEEs. The main drawbacks of Slalom when extending to training are (1) weight quantization needs to be dynamics as they change during training, and (2) pre-processing step of Slalom to compare u = f(r) isn't effective as the weights change, and running this within TEE is no better than running the full DNN within TEE. In addition, Goten also makes the weights private as opposed to Slalom. Overall, this is a very important contribution towards privacy preserving training and the paper takes a strong practical and implementation-focused approach by considering issues arising due to memory limitations in TEE and the performance implications of default Linux paging.

The paper comes up with a novel outsourcing protocol with two non-colluding servers for offloading linear operations in a fully privacy-preserving way and does detailed analysis of the performance implications. Similar to a lot of other methods for training with quantization, the weights are stored and updated in floats while the computation is performed using quantized values. The experimental results suggest a strong improvement over the CaffeSCONE baseline. One drawback with experiments is the lack of comparison with Slalom for inference if Goten is assumed to be a framework for both training and prediction in a privacy-preserving way.

Another downside of the paper is that a few sections could be improved with their explanation, and there is quite a bit of redundancy in going over the downsides of Slalom and why it can't be used for secure training. For instance,
- Section 1.1: "Our results (referring to Section 4.2) show that CaffeSCONE’s performance greatly suffer from the enclave’s memory limit as it needs an inefficient mechanism to handle excessive use of memory not affordable by the enclave". Here, it's not clear which mechanism is inefficient. Are we talking about mechanisms in CaffeSCONE for reducing memory usage while training and if so, are they somehow inefficient? Or does it mean to imply that we can't train a DNN fully within an enclave due to memory limits?
-  Last paragraph of section 2.2 is unclear. "CaffeSCONE guarantees the correctness of both training and prediction. Goten does not provide it as we present it due to page limitation, but we can resort to the trick used by Slalom". What does the last sentence mean? Does Goten guarantee correctness during training and prediction or not? And what trick from Slalom are we referring to? The blinding trick used for privacy or the Freivalds' algorithm used for correctness?

Overall a strong contribution with supporting experimental results, but the certain parts need further explanation or rewriting for higher rating.

Pros:
- An important contribution in the direction of fully private DNN training and inference within a TEE. Draws inspirations from Slalom and mainly addresses the challenges left to extend the approach to training.
- Motivation and reasons for why Slalom can't be used for training is very well laid out.
- In addition to input and output activations, Goten also preserves the privacy of the weights.
- Good baseline for comparison using CaffeSCONE.
- Implementation factors considered and analyzed such as tricks as using SGX-aware paging instead of naive Linux paging.
- Strong experiments and benchmarks

Cons:
- Some sections are not explained well and unclear as mentioned earlier.
- How does the inference performance of Goten compare to Slalom given the same privacy and correctness guarantees? This isn't clear from the experiments section.

Minor comments:
- "Slalom" is mis-spelt in line 4 of the abstract.
- There appear to be typos and grammatical errors at many places in the paper. Further proof-reading might be helpful.
review_title: Official Blind Review #3

final_score: rating: 1: Reject
review_content: 
Summary
========
This paper proposes a framework for privacy-preserving training of neural networks, by leveraging trusted execution environments and untrusted GPU accelerators.
The system builds heavily on the prior Slalom system, and uses standard MPC techniques (three non-colluding servers, multiplication triplets) to extend Slalom's inference-only protocol to privacy-preserving training.
This is a valuable and hard to reach goal. Unfortunately, the paper's evaluation fails to deliver on its strong promises, by ignoring the high network communication between the non-colluding servers.
Specifically, all experiments were conducted with three servers co-located in a public cloud's LAN. In this setting, it is hard to argue that non-collusion is a valid security assumption as the cloud provider controls all servers (alternatively, if the cloud provider is trusted, then there is no need for any trusted execution or cryptography). If the same experiments were conducted on a WAN, the communication costs would alleviate any savings in computation time.

For these reasons, I lean strongly towards rejection of this paper. 

Detailed comments
=================
Extending the ideas in Slalom to support privacy-preserving training is a good research question, and Tramer and Boneh had discussed some of the challenges and limitations towards this in their original paper.
Getting rid of the pre-processing stage for blinding factors by leveraging non-colluding servers is a well-known trick from the MPC literature, but it does not seem easily applicable here. 
The problem is that the servers need to communicate an amount of data proportional to the size of each internal layer of the network, for each forward and backward pass. If the servers communicate over a standard WAN, the communication time will be much too high to be competitive with the CaffeScone baseline.
In a LAN, as in this paper's experiments, the network latency is low enough for the network costs to be dominated by computation. But this begs the question of whether servers running in a same LAN (e.g., hosted by a single cloud provider) can really be considered non-colluding. In the considered setup, the cloud provider (Google in this case), could just observe the communication between all servers, thereby breaking privacy.

Another security issue with proposed scheme is the lack of computation integrity. This corresponds to the so-called "honest-but-curious" threat model which often appears in the MPC literature, and this should be acknowledged and motivated.

On the experimental side, the considered baseline, CaffeScone, seems pretty weak. In particular, any optimizations that the authors implement for Goten (e.g., better paging) should also be added to their baseline for a fair comparison.
The numbers in Figure 3 show that the baseline could be optimized a lot further.  A gap between hardware/simulation modes of ~6x seems indicative of sub-optimal paging. Even the single-core, simulation mode throughput numbers seem low for CIFAR10.

The experimental setup is quite confusing. Running the baseline and Goten in different environments (e.g., different CPUs) and then re-normalizing throughputs is somewhat convoluted and prone to mistakes. Why not run all experiments on the same setup?
Similarly, converting between results in SGX's hardware and simulation modes is also not very indicative. The authors note (p. 8) that in SGX's simulation mode "code compilation is almost the same as hardware mode except that the program is not protected by SGX, which is fine for our purpose since the DNN training and prediction algorithms are publicly known". This is fundamentally incorrect!
SGX's simulation mode provides absolutely no security guarantees. It simply compiles the code using the SGX libraries and ensures that the enclaved code performs no untrusted operations, but it does not provide any hardware protections whatsoever. In particular, code running in simulation mode will not be affected by the overhead of SGX's paging, as the memory is never encrypted.
As a result, performance results in simulation mode are usually not indicative of performance in hardware mode. Trying to convert runtimes from simulation mode to hardware mode by comparing times of specific layers is also prone to many approximation errors. 

Finally, I had some trouble understanding the way in which Goten quantization works. Section 3.3. mentions that values are treated as floats, but then mentions the use of 53 bits of precision. Did you mean double-precision floats here? But then, aren't modern GPU optimized mainly for single-precision float operations? Section 3.3. also says that the quantization ensures that there are nearly no overflows. What happens when an overflow occurs? I guess that because of the randomized blinding, a single overflow would result in a completely random output. How do you deal with this during training?

Minor
=====
- Typo in abstract: Slaom -> Slalom
- I don't understand the purpose of footnote 3 in Appendix B.2. First, the bibliographic entry for (Volos et al. 2018) explicitly says that the paper was published in OSDI 2018, a top-tier peer-reviewed conference. Regardless, claiming a date for a first unpublished draft of your paper is a little unusual and somewhat meaningless. I'm sure Volos et al. had a draft of their paper ready in late 2017 or even earlier if they submitted to OSDI in XXX 2018. If you want to timestamp your paper, post in to arXiv or elsewhere online.
review_title: Official Blind Review #1

Meta-review: This paper proposes a framework for privacy-preserving training of neural networks within a Trusted Execution Environment (TEE) such as Intel SGX. The reviewers found that this is a valuable research directions, but found that there were significant flaws in the experimental setup that need to be addressed. In particular, the paper does not run all the experiments in the same setup, which leads to the use of scaling factor in some cases. The reviewers found that this made it difficult to make sense of the results. The writing of this paper should be streamlined, along with the experiments before resubmission.
Decision: Reject