From 586e061b1f55fd68f1175141064cf739180916c5 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Mon, 11 May 2026 22:22:55 +0200 Subject: [PATCH 1/3] docs: add protocol configuration page Documents the configuration surface of the core TLSNotary protocol crates: TlsClientConfig, VerifierConfig, ProveConfig, MpcTlsConfig (MPC mode) and ProxyTlsConfig (Proxy mode), plus sizing guidance and the online-vs-deferred decryption explanation. --- docs/protocol/configuration.md | 126 +++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 docs/protocol/configuration.md diff --git a/docs/protocol/configuration.md b/docs/protocol/configuration.md new file mode 100644 index 0000000..0ac5b17 --- /dev/null +++ b/docs/protocol/configuration.md @@ -0,0 +1,126 @@ +--- +sidebar_position: 7 +--- + +# Configuration + +This page documents the configuration options exposed by the core TLSNotary protocol crates. Higher-level wrappers (the SDK, the notary server, the browser extension) re-export these settings, sometimes with their own defaults — refer to their documentation for the user-facing surface. + +The protocol supports two TLS commitment modes — **MPC** and **Proxy** — with very different configuration surfaces. The asymmetry follows directly from how each mode works: MPC mode pre-allocates resources to run an interactive protocol with the `Prover` during the live TLS connection, whereas Proxy mode merely relays ciphertext. + +## Mode-independent configuration + +These configurations apply regardless of the commitment mode. + +### `TlsClientConfig` + +Configures the TLS client that the `Prover` runs. + +| Field | Required | Description | +|----------------|----------|--------------------------------------------------------------------------------------------------------------------------| +| `server_name` | yes | The DNS name (or IP) of the server. Used for SNI and certificate verification. | +| `root_store` | yes | Root certificates used to verify the server certificate chain. | +| `client_auth` | no | Optional certificate chain and private key for TLS client authentication (mutual TLS). | + +### `VerifierConfig` + +Configures the `Verifier`. + +| Field | Required | Description | +|--------------|----------|-----------------------------------------------------------------------------------| +| `root_store` | yes | Root certificates the `Verifier` will accept when validating the server's chain. | + +### `ProveConfig` + +Built against a finished transcript, controls what the `Prover` discloses to the `Verifier` during the proving phase. + +| Field | Description | +|----------------------|-------------------------------------------------------------------------------------------------------| +| `server_identity` | Whether to prove the server identity (i.e. reveal the server name to the `Verifier`). | +| `reveal` | Byte ranges of the sent and received transcript to reveal. | +| `transcript_commit` | Configuration of the transcript commitments (see [Commit Strategy](./commit_strategy.md)). | + +By default, no ranges are revealed and the server identity is hidden (see [Server Identity Privacy](./server_identity_privacy.md)). + +## MPC mode (`MpcTlsConfig`) + +In MPC mode the `Prover` and `Verifier` jointly run the TLS protocol over MPC. Resources for the MPC computation must be allocated up front, so the session is bounded by data limits configured in advance. + +### Data and record limits + +| Field | Required | Default | Description | +|-----------------------------|----------|----------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `max_sent_data` | yes | — | Maximum bytes the `Prover` may send to the server during the session. | +| `max_recv_data` | yes | — | Maximum bytes the `Prover` may receive from the server during the session. | +| `max_recv_data_online` | no | 32 | Of the received bytes, how many may be decrypted **while the TLS connection is active**. Must be `≤ max_recv_data`. | +| `max_sent_records` | no | Derived from `max_sent_data` | Maximum number of TLS records (≤ 16KB each) the `Prover` may send. | +| `max_recv_records_online` | no | Derived from `max_recv_data_online` | Maximum number of received TLS records decrypted online. | + +Each of these sets a hard cap: exceeding it aborts the session. The record-count fields exist because TLS data is framed into records, and the MPC layer must reserve resources per record as well as per byte. The defaults are derived heuristically from the data limits and rarely need to be set explicitly. + +The relationship between `max_recv_data` and `max_recv_data_online` is explained under [Online vs deferred decryption](#online-vs-deferred-decryption) below. + +### Deferred decryption + +| Field | Default | Description | +|--------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `defer_decryption_from_start` | `true` | If `true`, application-data decryption is deferred from the moment the TLS connection starts; if `false`, decryption runs online via MPC from the first byte. | + +When deferred decryption is enabled, only `max_recv_data_online` bytes of application data are decrypted under MPC during the live connection — the rest are buffered as ciphertext and decrypted by the `Prover` locally after the connection ends. See [Online vs deferred decryption](#online-vs-deferred-decryption). + +### Network setting + +| Field | Variants | Default | Description | +|------------|-------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------| +| `network` | `Bandwidth`, `Latency` | `Latency` | Tunes the sub-protocols (notably the PRF) for either fewer round-trips at the cost of more bytes, or lower bandwidth at more RTTs. | + +Pick `Bandwidth` for high-bandwidth, high-RTT links (e.g., cross-region over fiber). Pick `Latency` for low-bandwidth or RTT-cheap links (e.g., LAN, mobile). + +## Proxy mode (`ProxyTlsConfig`) + +In Proxy mode the `Verifier` proxies the TLS connection, observes encrypted traffic, and later verifies a zero-knowledge proof from the `Prover` that the plaintext matches the ciphertext. There is no MPC preprocessing and no per-session resource allocation, so the configuration surface is minimal. + +| Field | Required | Description | +|---------------|----------|-----------------------------------------------------------------------------------| +| `server_name` | yes | The DNS name of the server the `Prover` will connect to through the proxy. | + +Session size in Proxy mode is bounded only by the underlying TLS connection — there are no `max_sent_data` / `max_recv_data` knobs because there is nothing to preallocate. + +## Online vs deferred decryption + +The trickiest part of MPC-mode sizing is the split between `max_recv_data_online` and `max_recv_data`. Understanding it is easier when you separate two roles the limits play. + +**As DoS protection.** Every limit bounds what a malicious `Prover` can force the `Verifier` to do. The `Verifier` decides how much it is willing to spend on a session and refuses anything that exceeds those caps. + +**As an MPC preprocessing budget.** The MPC layer needs to pre-generate cryptographic material proportional to the amount of data the session will handle. Larger limits mean more preprocessing time and bandwidth before the TLS connection even opens. + +The three data limits play these roles differently: + +- **`max_sent_data`** — drives MPC preprocessing for encryption. All bytes the `Prover` sends must be encrypted under MPC during the live connection (the server is waiting), so there is no "free" tier here. +- **`max_recv_data_online`** — drives MPC preprocessing for decryption. Bytes counted here are decrypted via MPC while the TLS connection is active. +- **`max_recv_data`** — the total receive cap. The portion above `max_recv_data_online` is **not** decrypted via MPC; instead, after the TLS connection closes, the `Verifier` reveals its share of the server's keys to the `Prover`, who then decrypts the buffered ciphertext locally. This is **deferred decryption**, and it is essentially free in MPC terms. + +Deferred decryption is safe because revealing the key share only happens *after* the TLS connection has been authenticated and closed: the `Prover` can no longer forge anything the server would have accepted, and the ciphertext-plus-MAC is already committed. + +### Why have any online decryption at all? + +Two reasons: + +1. **TLS protocol traffic.** A small amount of received protocol data (Finished messages, alerts, etc.) must be decrypted online for the handshake to complete. The defaults reserve room for this. +2. **In-session logic.** If the application reads part of the response before it knows what to send next (e.g., extract a CSRF token, follow a redirect, paginate based on a cursor in the body), those bytes must be decrypted online. Set `max_recv_data_online` to cover the parts of the response your client actually inspects mid-session. + +### What changes when `defer_decryption_from_start = false` + +When deferred decryption is disabled from the start, all received bytes are decrypted online via MPC. Effectively `max_recv_data_online` is forced up to `max_recv_data`, and preprocessing cost grows with the full receive limit. This is rarely what you want for large responses. + +## Sizing guidance + +A quick checklist for choosing MPC-mode limits: + +1. Estimate **outgoing data**: request line, headers, body. Set `max_sent_data` to that figure plus a margin (e.g. 2×). Every byte here costs preprocessing. +2. Estimate **total incoming data**: response headers + body, plus overhead. Set `max_recv_data` to that. This is mostly a DoS cap if you use deferred decryption. +3. Estimate **incoming data you must read mid-session** (typically: just the parts that influence what you send next, or zero if you fire-and-forget). Set `max_recv_data_online` to that. Keep this small. +4. Leave `defer_decryption_from_start` at its default (`true`) unless you have a specific reason to disable it. +5. Pick `network` based on your link. Default `Latency` is fine for most local or mobile testing. + +The lower these numbers, the faster the session starts and the less bandwidth is consumed before the TLS connection opens. From 8cd4e991f83a5d3637ab51a26ab70332cc210c60 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Tue, 19 May 2026 11:13:42 +0200 Subject: [PATCH 2/3] docs(configuration): tighten prose and fix a few inaccuracies Editorial pass over the protocol configuration page --- docs/protocol/configuration.md | 59 ++++++++++++++++------------------ 1 file changed, 28 insertions(+), 31 deletions(-) diff --git a/docs/protocol/configuration.md b/docs/protocol/configuration.md index 0ac5b17..dd2431e 100644 --- a/docs/protocol/configuration.md +++ b/docs/protocol/configuration.md @@ -1,16 +1,15 @@ --- sidebar_position: 7 --- - # Configuration -This page documents the configuration options exposed by the core TLSNotary protocol crates. Higher-level wrappers (the SDK, the notary server, the browser extension) re-export these settings, sometimes with their own defaults — refer to their documentation for the user-facing surface. +This page documents the configuration options exposed by the core TLSNotary protocol crates. The SDK re-exports these settings — sometimes with its own defaults — and tools built on top of it (such as the browser extension) inherit that surface. Refer to the SDK and tool-specific documentation for the user-facing options. -The protocol supports two TLS commitment modes — **MPC** and **Proxy** — with very different configuration surfaces. The asymmetry follows directly from how each mode works: MPC mode pre-allocates resources to run an interactive protocol with the `Prover` during the live TLS connection, whereas Proxy mode merely relays ciphertext. +The protocol supports two modes — **MPC** and **Proxy** — with very different configuration surfaces. ## Mode-independent configuration -These configurations apply regardless of the commitment mode. +These configurations apply regardless of the mode. ### `TlsClientConfig` @@ -18,13 +17,13 @@ Configures the TLS client that the `Prover` runs. | Field | Required | Description | |----------------|----------|--------------------------------------------------------------------------------------------------------------------------| -| `server_name` | yes | The DNS name (or IP) of the server. Used for SNI and certificate verification. | +| `server_name` | yes | The DNS name (or IP) of the server. | | `root_store` | yes | Root certificates used to verify the server certificate chain. | -| `client_auth` | no | Optional certificate chain and private key for TLS client authentication (mutual TLS). | +| `client_auth` | no | Optional certificate chain and private key for TLS client authentication (mutual TLS, mTLS). | ### `VerifierConfig` -Configures the `Verifier`. +Configures what the `Verifier` accepts during the TLS handshake. | Field | Required | Description | |--------------|----------|-----------------------------------------------------------------------------------| @@ -36,7 +35,7 @@ Built against a finished transcript, controls what the `Prover` discloses to the | Field | Description | |----------------------|-------------------------------------------------------------------------------------------------------| -| `server_identity` | Whether to prove the server identity (i.e. reveal the server name to the `Verifier`). | +| `server_identity` | Whether to reveal the configured `server_name` to the `Verifier`. | | `reveal` | Byte ranges of the sent and received transcript to reveal. | | `transcript_commit` | Configuration of the transcript commitments (see [Commit Strategy](./commit_strategy.md)). | @@ -58,15 +57,15 @@ In MPC mode the `Prover` and `Verifier` jointly run the TLS protocol over MPC. R Each of these sets a hard cap: exceeding it aborts the session. The record-count fields exist because TLS data is framed into records, and the MPC layer must reserve resources per record as well as per byte. The defaults are derived heuristically from the data limits and rarely need to be set explicitly. -The relationship between `max_recv_data` and `max_recv_data_online` is explained under [Online vs deferred decryption](#online-vs-deferred-decryption) below. +The relationship between `max_recv_data` and `max_recv_data_online` is explained under [Online vs deferred decryption](#online-vs-deferred-decryption). ### Deferred decryption | Field | Default | Description | |--------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| -| `defer_decryption_from_start` | `true` | If `true`, application-data decryption is deferred from the moment the TLS connection starts; if `false`, decryption runs online via MPC from the first byte. | +| `defer_decryption_from_start` | `true` | If `true`, application-data decryption is deferred until after the TLS connection closes; if `false`, decryption runs online via MPC from the first byte. | -When deferred decryption is enabled, only `max_recv_data_online` bytes of application data are decrypted under MPC during the live connection — the rest are buffered as ciphertext and decrypted by the `Prover` locally after the connection ends. See [Online vs deferred decryption](#online-vs-deferred-decryption). +When deferred decryption is enabled, only `max_recv_data_online` received bytes are decrypted under MPC during the live connection — the rest are buffered as ciphertext and decrypted by the `Prover` locally after the connection ends. The default 32-byte budget covers the TLS protocol messages that must be processed online (Finished, alerts); raise it only if the `Prover` needs to read application data mid-session. See [Online vs deferred decryption](#online-vs-deferred-decryption). ### Network setting @@ -74,21 +73,11 @@ When deferred decryption is enabled, only `max_recv_data_online` bytes of applic |------------|-------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------| | `network` | `Bandwidth`, `Latency` | `Latency` | Tunes the sub-protocols (notably the PRF) for either fewer round-trips at the cost of more bytes, or lower bandwidth at more RTTs. | -Pick `Bandwidth` for high-bandwidth, high-RTT links (e.g., cross-region over fiber). Pick `Latency` for low-bandwidth or RTT-cheap links (e.g., LAN, mobile). - -## Proxy mode (`ProxyTlsConfig`) - -In Proxy mode the `Verifier` proxies the TLS connection, observes encrypted traffic, and later verifies a zero-knowledge proof from the `Prover` that the plaintext matches the ciphertext. There is no MPC preprocessing and no per-session resource allocation, so the configuration surface is minimal. - -| Field | Required | Description | -|---------------|----------|-----------------------------------------------------------------------------------| -| `server_name` | yes | The DNS name of the server the `Prover` will connect to through the proxy. | - -Session size in Proxy mode is bounded only by the underlying TLS connection — there are no `max_sent_data` / `max_recv_data` knobs because there is nothing to preallocate. +Only switch to `Bandwidth` for high-bandwidth, high-RTT links (e.g., cross-region over fiber). Keep the default `Latency` in all other situations (LAN, mobile, low-bandwidth links). -## Online vs deferred decryption +### Online vs deferred decryption -The trickiest part of MPC-mode sizing is the split between `max_recv_data_online` and `max_recv_data`. Understanding it is easier when you separate two roles the limits play. +Sizing the split between `max_recv_data_online` and `max_recv_data` is easier once you separate the two roles these limits play: **As DoS protection.** Every limit bounds what a malicious `Prover` can force the `Verifier` to do. The `Verifier` decides how much it is willing to spend on a session and refuses anything that exceeds those caps. @@ -102,25 +91,33 @@ The three data limits play these roles differently: Deferred decryption is safe because revealing the key share only happens *after* the TLS connection has been authenticated and closed: the `Prover` can no longer forge anything the server would have accepted, and the ciphertext-plus-MAC is already committed. -### Why have any online decryption at all? +#### Why have any online decryption at all? Two reasons: 1. **TLS protocol traffic.** A small amount of received protocol data (Finished messages, alerts, etc.) must be decrypted online for the handshake to complete. The defaults reserve room for this. 2. **In-session logic.** If the application reads part of the response before it knows what to send next (e.g., extract a CSRF token, follow a redirect, paginate based on a cursor in the body), those bytes must be decrypted online. Set `max_recv_data_online` to cover the parts of the response your client actually inspects mid-session. -### What changes when `defer_decryption_from_start = false` +#### What changes when `defer_decryption_from_start = false` -When deferred decryption is disabled from the start, all received bytes are decrypted online via MPC. Effectively `max_recv_data_online` is forced up to `max_recv_data`, and preprocessing cost grows with the full receive limit. This is rarely what you want for large responses. +When deferred decryption is disabled from the start, all received bytes are decrypted online via MPC. Effectively `max_recv_data_online` is forced up to `max_recv_data`, and preprocessing cost grows with the full receive limit. Only disable deferred decryption if your specific use case requires it — online MPC decryption is slow, and on large responses the TLS connection can stay open long enough for the server to time it out. -## Sizing guidance +### Sizing guidance A quick checklist for choosing MPC-mode limits: -1. Estimate **outgoing data**: request line, headers, body. Set `max_sent_data` to that figure plus a margin (e.g. 2×). Every byte here costs preprocessing. -2. Estimate **total incoming data**: response headers + body, plus overhead. Set `max_recv_data` to that. This is mostly a DoS cap if you use deferred decryption. +1. Estimate **outgoing data**: request line, headers, body. Set `max_sent_data` to that figure plus a margin. Every byte here costs preprocessing. +2. Estimate **total incoming data**: response headers + body, plus overhead. Set `max_recv_data` to that. With deferred decryption, this cap is essentially free in MPC-preprocessing terms — it just bounds the session size (and the `Verifier` will reject if it exceeds its own policy). 3. Estimate **incoming data you must read mid-session** (typically: just the parts that influence what you send next, or zero if you fire-and-forget). Set `max_recv_data_online` to that. Keep this small. 4. Leave `defer_decryption_from_start` at its default (`true`) unless you have a specific reason to disable it. -5. Pick `network` based on your link. Default `Latency` is fine for most local or mobile testing. +5. Pick `network` based on your link. Default `Latency` is best for most use cases. The lower these numbers, the faster the session starts and the less bandwidth is consumed before the TLS connection opens. + +## Proxy mode (`ProxyTlsConfig`) + +Proxy mode requires no MPC preprocessing and no per-session resource allocation, so the configuration surface is minimal. + +| Field | Required | Description | +|---------------|----------|-----------------------------------------------------------------------------------| +| `server_name` | yes | The DNS name of the server the `Prover` will connect to through the proxy. | From d5a89ccbce60829ed0b4afffe8e742d87402d488 Mon Sep 17 00:00:00 2001 From: Hendrik Eeckhaut Date: Wed, 27 May 2026 10:33:04 +0200 Subject: [PATCH 3/3] docs(configuration): clarify deferred decryption and ProverControl - Fix inaccurate claim that the session is rejected when max_recv_data_online != max_recv_data with defer_decryption_from_start=false (it actually aborts mid-stream at runtime). - Document ProverControl for toggling online decryption mid-session. - Tighten Network setting recommendation and minor prose cleanup. --- docs/protocol/configuration.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/docs/protocol/configuration.md b/docs/protocol/configuration.md index dd2431e..a1e4c74 100644 --- a/docs/protocol/configuration.md +++ b/docs/protocol/configuration.md @@ -5,7 +5,7 @@ sidebar_position: 7 This page documents the configuration options exposed by the core TLSNotary protocol crates. The SDK re-exports these settings — sometimes with its own defaults — and tools built on top of it (such as the browser extension) inherit that surface. Refer to the SDK and tool-specific documentation for the user-facing options. -The protocol supports two modes — **MPC** and **Proxy** — with very different configuration surfaces. +The protocol supports two modes, **MPC** and **Proxy**, with very different configuration surfaces. ## Mode-independent configuration @@ -65,7 +65,9 @@ The relationship between `max_recv_data` and `max_recv_data_online` is explained |--------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------| | `defer_decryption_from_start` | `true` | If `true`, application-data decryption is deferred until after the TLS connection closes; if `false`, decryption runs online via MPC from the first byte. | -When deferred decryption is enabled, only `max_recv_data_online` received bytes are decrypted under MPC during the live connection — the rest are buffered as ciphertext and decrypted by the `Prover` locally after the connection ends. The default 32-byte budget covers the TLS protocol messages that must be processed online (Finished, alerts); raise it only if the `Prover` needs to read application data mid-session. See [Online vs deferred decryption](#online-vs-deferred-decryption). +With deferred decryption enabled, received bytes are buffered as ciphertext and decrypted by the `Prover` locally after the connection closes. `max_recv_data_online` is a preprocessing budget for the few bytes that still need online decryption: TLS protocol messages (Finished, alerts). The default of 32 bytes covers this; raise it only if the `Prover` needs to read application data mid-session. See [Online vs deferred decryption](#online-vs-deferred-decryption). + +`defer_decryption_from_start` sets the initial mode. The protocol also exposes a [`ProverControl`](https://github.com/tlsnotary/tlsn/blob/main/crates/tlsn/src/prover/control.rs) handle that lets the application toggle online decryption mid-session. This is useful when only a specific window of the response needs to be inspected online. Picking the exact toggle point is currently up to the consumer. ### Network setting @@ -73,7 +75,7 @@ When deferred decryption is enabled, only `max_recv_data_online` received bytes |------------|-------------------------|------------|----------------------------------------------------------------------------------------------------------------------------------------| | `network` | `Bandwidth`, `Latency` | `Latency` | Tunes the sub-protocols (notably the PRF) for either fewer round-trips at the cost of more bytes, or lower bandwidth at more RTTs. | -Only switch to `Bandwidth` for high-bandwidth, high-RTT links (e.g., cross-region over fiber). Keep the default `Latency` in all other situations (LAN, mobile, low-bandwidth links). +Keep the default `Latency` for typical connections. Switch to `Bandwidth` only on links that are both high-bandwidth and high-latency. ### Online vs deferred decryption @@ -85,9 +87,9 @@ Sizing the split between `max_recv_data_online` and `max_recv_data` is easier on The three data limits play these roles differently: -- **`max_sent_data`** — drives MPC preprocessing for encryption. All bytes the `Prover` sends must be encrypted under MPC during the live connection (the server is waiting), so there is no "free" tier here. -- **`max_recv_data_online`** — drives MPC preprocessing for decryption. Bytes counted here are decrypted via MPC while the TLS connection is active. -- **`max_recv_data`** — the total receive cap. The portion above `max_recv_data_online` is **not** decrypted via MPC; instead, after the TLS connection closes, the `Verifier` reveals its share of the server's keys to the `Prover`, who then decrypts the buffered ciphertext locally. This is **deferred decryption**, and it is essentially free in MPC terms. +- **`max_sent_data`**: drives MPC preprocessing for encryption. All bytes the `Prover` sends must be encrypted under MPC during the live connection (the server is waiting), so there is no "free" tier here. +- **`max_recv_data_online`**: drives MPC preprocessing for decryption. Bytes counted here are decrypted via MPC while the TLS connection is active. +- **`max_recv_data`**: the total receive cap. The portion above `max_recv_data_online` is **not** decrypted via MPC; instead, after the TLS connection closes, the `Verifier` reveals its share of the server's keys to the `Prover`, who then decrypts the buffered ciphertext locally. This is **deferred decryption**, and it is essentially free in MPC terms. Deferred decryption is safe because revealing the key share only happens *after* the TLS connection has been authenticated and closed: the `Prover` can no longer forge anything the server would have accepted, and the ciphertext-plus-MAC is already committed. @@ -100,14 +102,14 @@ Two reasons: #### What changes when `defer_decryption_from_start = false` -When deferred decryption is disabled from the start, all received bytes are decrypted online via MPC. Effectively `max_recv_data_online` is forced up to `max_recv_data`, and preprocessing cost grows with the full receive limit. Only disable deferred decryption if your specific use case requires it — online MPC decryption is slow, and on large responses the TLS connection can stay open long enough for the server to time it out. +When deferred decryption is disabled from the start, all received bytes are decrypted online via MPC. In this mode you'll typically want `max_recv_data_online = max_recv_data`; otherwise the session aborts mid-stream as soon as more bytes are received than the online budget allows. Preprocessing cost grows with the full receive limit. Only disable deferred decryption if your specific use case requires it. Online MPC decryption is slow, and on large responses the TLS connection can stay open long enough for the server to time it out. ### Sizing guidance A quick checklist for choosing MPC-mode limits: 1. Estimate **outgoing data**: request line, headers, body. Set `max_sent_data` to that figure plus a margin. Every byte here costs preprocessing. -2. Estimate **total incoming data**: response headers + body, plus overhead. Set `max_recv_data` to that. With deferred decryption, this cap is essentially free in MPC-preprocessing terms — it just bounds the session size (and the `Verifier` will reject if it exceeds its own policy). +2. Estimate **total incoming data**: response headers + body, plus overhead. Set `max_recv_data` to that. With deferred decryption, this cap is essentially free in MPC-preprocessing terms. It just bounds the session size (and the `Verifier` will reject if it exceeds its own policy). 3. Estimate **incoming data you must read mid-session** (typically: just the parts that influence what you send next, or zero if you fire-and-forget). Set `max_recv_data_online` to that. Keep this small. 4. Leave `defer_decryption_from_start` at its default (`true`) unless you have a specific reason to disable it. 5. Pick `network` based on your link. Default `Latency` is best for most use cases.