---
creation-date: 2024-03-15
tags: notes/paper
date-published: 2021
---
# paper-Zero Knowledge Middleboxes
link: https://eprint.iacr.org/2021/1022
## abstract
A **zero knowledge middle box** (ZKMB) is a network middlebox that enforces network usage policies on encrypted traffic. Clients send zkps to the MB that their network traffic is complient, revealing nothing about the traffic itself. This paper:
- demonstrates a protocol that works with TLS 1.3, making the ZKMB entirely abstracted from servers (but not clients, who bear the cost of computing and submitting proofs).
- designs a zkp for TLS 1.3 session keys.

The primary proposed use case a ZKMB is to filter domain queries.

Overhead for operating a middlebox is claimed to be between 2 and 5 ms to verify each proof, and several seconds for the client to generate each proof. \[The Groth 16 SRS\] is hundreds of MBs. This is not claimed to be suitable for production.

## conclusion
The authors state challenges and restate experimental results, using with Groth16 as a proof system.

implemetation challenges:
- representing the TLS handshake as a circuit (tedious)
- embedding DNS filtering as a circuit

performance challenges:
- **network bottlenecking:** 2-5 ms verification time corresponds to 200-500 proofs per second. Network middlebox links would need to be parallelized to reliably handle traffic, or else introduce a bottleneck point.
- Authors propose optimistically passing traffic, and blocking traffic from a client that retrospectively fails a proof check.
- **slow client runtime** - 14 seconds to prove a TLS conn, and several seconds for proving any packets satisfy DNS constraints. Authors suggest amortizing handshake cost across a long lasting DNS session does at least somewhat ameliorate the cost.
- **The Groth16 SRS is hundreds of megabytes**. There is also the issue of how the user obtains the SRS:
- Each middlebox generates it's own SRS. The client must download and store the new SRS when joining a new network.
- A trusted entity, e.g. browser vendors, generate and package the SRS. This would require different browser vendors to concur on browser standard middlebox compliance. Difficult, but not inconceivable; though this would further complicates SRS provisioning and browser updates.
- A transparent (non-SRS) or universal (single general SRS) proof system would solve SRS-provisioning related issues, and allow for faster proving times, but typically produce larger proofs and slower verifier times.

## evaluation
Is it worth continuing to read? If I am interested in circuit formalization for DNS filtering, TLS handshakes, or HTTP firewalls.

They wrote their circuits in [xjsnark](https://github.com/akosba/xjsnark), which I've never heard of. It appears to be an abandoned academic DSL framework for developing snarks.

They may further provide better motivation for why a network would implement this, which I'm curious about. Read the intro, then likely bail.

## introduction
Model includes a *client* communicating with a *server* over a local network. Traffic is encrypted. A (stateless) *middlebox* forwards traffic and enforces some policy.

Authors purport that existing middleboxes require unencrypted traffic to enforce rules, but that the ZKMB would not require clients to downgrade traffic similarly.

Standard probably reasonable assumptions provided.

A **sophisticated client would be able to thwart the middlebox**. The authors sidestep this concern. Techniques described:
- VPNs
- hidden proxies
- inner-encryption
- Tor (which uses both hidden proxies and inner encryption)
- "stenography"

**Why would a provider adopt a ZKMB model?** Authors claim that: "most network administrators do not want to surveil."

Setting aside prohibitive proving and verification costs, it seems implicitly argued that a ZKMB would allow network operators to give plausible deniability that they follow some legal constraint as far as possible, though that itself is truly not very far.

Interesting points. Rest of paper interesting only for formalization specifics, so now we bail.

## terms
A **zero knowledge middle box** (ZKMB) is a network middlebox that enforces network usage policies on encrypted traffic. Clients send zkps to the MB that their network traffic is complient, revealing nothing about the traffic itself.