quicproquo/docs/src/cryptography/threat-model.md

# Threat Model

This page defines the attacker models quicprochat is designed to resist,
catalogues what is and is not protected, identifies known gaps in the current
implementation, and outlines future mitigations.

## Attacker Models

### 1. Passive Eavesdropper

**Capabilities:** Records all network traffic between clients and the server.
Can observe IP addresses, connection timing, message sizes, and encrypted
payloads. Cannot modify traffic.

**What they learn:**

- Connection metadata: which IP addresses connect to the server and when.
- Message timing and sizes: observable patterns (e.g., message frequency,
  payload lengths) that could reveal communication patterns.
- Encrypted payloads: TLS 1.3 ciphertext containing MLS ciphertext. Both layers
  of encryption must be broken to access content.

**What they cannot learn:**

- Message content: protected by MLS encryption inside TLS.
- Group membership details: MLS Commits are encrypted.
- Which specific recipient a message is destined for (from the network
  perspective, all messages go to the server).

**Residual risk:** Traffic analysis. Even without decryption, the timing and
size of messages can reveal communication patterns. For example, a message sent
by Alice followed shortly by a message to Bob may indicate they are in the same
group. See [Future Mitigations](#future-mitigations) for countermeasures.

### 2. Active Network Attacker (MITM)

**Capabilities:** Can intercept, modify, drop, and inject network traffic.
Positioned between the client and server (e.g., compromised router, ISP, or
state-level adversary).

**What they can do:**

- Attempt TLS 1.3 MITM: TLS 1.3 prevents this if the client validates the
  server's certificate. However, quicprochat currently uses **self-signed
  certificates**, which means the client has no CA chain to verify. On the first
  connection, a MITM could present their own certificate and intercept the
  session (trust-on-first-use vulnerability).
- Denial of service: drop or delay packets.
- Traffic analysis: same as passive eavesdropper, with the added ability to
  inject timing perturbations.

**What they cannot do (assuming no cert MITM):**

- Decrypt TLS traffic: TLS 1.3 uses authenticated ephemeral key exchange.
- Forge MLS messages: MLS Commits and application messages are signed by the
  sender's Ed25519 identity key. The attacker does not possess any member's
  signing key.
- Inject members into MLS groups: adding a member requires a valid KeyPackage
  signed by the new member's identity key.

**Current weakness:** Self-signed TLS certificates. See
[Known Gaps](#known-gaps).

### 3. Compromised Server

**Capabilities:** Full access to the server's memory, disk, and network
interfaces. Can read all data stored on the server, modify server behavior,
and observe all client connections.

**What the server sees:**

- Connection metadata: which clients connect, when, how often, from which IPs.
- Ed25519 public keys: used as delivery queue indices. The server knows the
  public identity key of every registered client.
- Message sizes and timing: the server forwards MLS messages and can observe
  their sizes and the timing of enqueue/fetch operations.
- Encrypted MLS blobs: the server stores and forwards MLS ciphertext but cannot
  decrypt it (the server is MLS-unaware by design, per ADR-004).

**What the server cannot do:**

- **Decrypt message content:** The server does not hold any MLS group keys. MLS
  application messages are encrypted end-to-end between group members. The
  server sees only opaque ciphertext.
- **Forge MLS messages:** MLS messages are signed by the sender's Ed25519 key.
  The server does not possess any member's signing key and cannot produce valid
  MLS signatures.
- **Read past messages:** Even if the server stored old MLS ciphertext, it
  cannot decrypt it. Forward secrecy at the MLS layer (epoch key deletion)
  ensures that even compromising a member's state in the future does not reveal
  past epoch keys.

**What the server can do maliciously:**

- **Traffic analysis:** Correlate senders and recipients based on timing,
  message sizes, and queue access patterns.
- **Selective denial of service:** Drop or delay specific messages or refuse
  service to specific clients.
- **Metadata correlation:** Link Ed25519 public keys to IP addresses and
  connection patterns.
- **Replay (limited):** Re-deliver an MLS message. MLS has replay protection
  via epoch numbers and message counters, so the recipient will reject the
  duplicate.
- **KeyPackage manipulation:** Withhold or substitute KeyPackages during the
  join flow. If the server substitutes a KeyPackage, the resulting MLS group
  would include the attacker's key, but the legitimate member would not be able
  to join (they would not receive a matching Welcome). This is detectable.

### 4. Compromised Client

**Capabilities:** Full access to a group member's device, including the MLS
group state, Ed25519 identity key, and any stored messages.

**What the attacker learns:**

- **Current epoch messages:** The attacker can decrypt all messages in the
  current MLS epoch from all group members (epoch keys are shared group secrets).
- **Identity key:** The attacker obtains the member's Ed25519 signing key and
  can impersonate the member (sign messages, create KeyPackages).

**What the attacker cannot learn:**

- **Past epoch messages:** Protected by [forward secrecy](forward-secrecy.md).
  Old epoch keys have been deleted by openmls.
- **Future epoch messages (after healing):** Protected by
  [post-compromise security](post-compromise-security.md). After the next
  Commit or Update, the ratchet tree is re-randomized and the attacker is
  locked out.

**Healing mechanism:**

1. The compromised member (or any other member) issues a Commit.
2. The ratchet tree is updated with fresh key material.
3. The attacker's stale state cannot derive the new epoch keys.
4. The attacker is locked out of future epochs.

The healing window is the time between the compromise and the next Commit. See
[Post-Compromise Security](post-compromise-security.md) for details.

## What Is Protected

| Asset | Protection Mechanism | Against |
|-------|---------------------|---------|
| Message content | MLS end-to-end encryption (AES-128-GCM) | All attacker models |
| Message integrity | MLS signing (Ed25519) | Forgery by server or network |
| Group membership changes | MLS Commits (signed, authenticated) | Unauthorized modification |
| Key exchange material | Single-use HPKE init keys | Replay, forward compromise |
| Transport confidentiality | TLS 1.3 (QUIC) | Passive eavesdropper |
| Transport integrity | TLS 1.3 AEAD | Active network attacker |
| Past messages | Forward secrecy (epoch key deletion) | Future client compromise |
| Future messages | Post-compromise security (ratchet tree update) | Past client compromise |

## What Is NOT Protected (Current State)

| Asset | Visibility | Observer |
|-------|-----------|----------|
| Transport metadata (who connects, when) | IP addresses, connection timing | Network adversary, server |
| Message timing and sizes | Observable in TLS records | Network adversary, server |
| Recipient identity | Server routes by Ed25519 public key | Server |
| Sender identity (partial) | Server can correlate connections to senders | Server |
| Number of groups a client belongs to | Observable via message patterns | Server (with analysis) |
| Client IP address | Visible in TCP/QUIC connection | Server, network adversary |

## Known Gaps

### Self-Signed TLS Certificates

The server uses self-signed TLS certificates generated at startup via `rcgen`.
Clients currently accept any server certificate without CA chain validation.
This makes the system vulnerable to a man-in-the-middle attack on the first
connection: an attacker positioned between the client and server can present
their own certificate and intercept all traffic.

**Impact:** Complete loss of transport confidentiality and integrity for affected
connections. MLS content remains protected (the MITM cannot decrypt MLS
ciphertext or forge MLS signatures), but the attacker can observe encrypted MLS
blobs, perform traffic analysis, and potentially block or delay messages.

**Mitigation path:** Implement certificate pinning (trust-on-first-use) or
integrate with a public CA (e.g., Let's Encrypt). Certificate transparency logs
could provide an additional detection mechanism.

### No Client Authentication on the Delivery Service

The Delivery Service requires a valid OPAQUE session token for all DS
operations. The session token is bound to the client's identity key, and the
server rejects enqueue and fetch operations that lack a valid token.

**Status:** Mitigated. Token-based authentication is enforced via the OPAQUE
login flow (methods 100-103). Unauthenticated enqueue attempts are rejected.

### Rate Limiting

The server enforces a sliding window rate limit on all RPC methods. Requests
exceeding the configured threshold per IP or per account are rejected with a
rate-limit error response.

**Status:** Mitigated. Rate limiting is active (sliding window, configurable
threshold, default 50 requests/second per IP). The `rate_limit_hit_total`
Prometheus metric tracks rejections. See [Monitoring](../operations/monitoring.md).

### BasicCredential Only

MLS `BasicCredential` contains only the raw Ed25519 public key bytes. There is
no certificate authority chain, no credential revocation mechanism, and no
binding to a human-readable identity (e.g., phone number, email).

**Impact:** No way to verify that a public key belongs to a specific person
without out-of-band verification (e.g., comparing fingerprints in person). An
attacker who compromises the Authentication Service could substitute public keys.

**Mitigation path:** Implement X.509-based MLS credentials with a certificate
chain, or integrate with a Key Transparency system that provides a verifiable
log of public key bindings.

### Classical-Only Transport

As discussed in [Post-Quantum Readiness](post-quantum-readiness.md), the
transport layer (QUIC/TLS 1.3) uses classical-only ECDHE. An adversary
performing harvest-now-decrypt-later (HNDL) could record transport traffic
today and decrypt it with a future quantum computer, revealing transport
metadata.

**Impact:** Future exposure of transport metadata (not content, assuming
hybrid KEM is active for MLS).

**Mitigation path:** Adopt post-quantum TLS (ML-KEM in TLS 1.3 handshake) when
`rustls` supports it.

## Implemented Mitigations

### Sealed Sender

**Status:** Implemented. The `--sealed-sender` flag encrypts the sender's
identity inside the MLS ciphertext. When enabled, the server routes by recipient
queue index only and cannot determine who sent the message. This reduces server
metadata visibility from "who sent to whom" to "someone sent to this recipient."

### OPAQUE Authentication

**Status:** Implemented. The OPAQUE protocol (RFC 9497) is the only supported
login mechanism. The server stores OPAQUE registration records; it never receives
or stores the client's password. Session tokens issued on login are required for
all authenticated RPCs.

### Username Enumeration Protection

**Status:** Implemented. All auth responses (including failures) are subject to
a 5ms timing floor, preventing timing-based username enumeration.

---

## Future Mitigations

### Private Information Retrieval (PIR)

**Goal:** Fetch messages without revealing the recipient's identity to the
server.

**Approach:** Use PIR protocols (e.g., SealPIR, SimplePIR) to query the
delivery queue without the server learning which queue was accessed.

**Benefit:** Combined with Sealed Sender, this would make the server metadata-blind:
it would know only that "someone sent something to someone."

**Trade-off:** PIR is computationally expensive and may increase latency
significantly, especially for large mailboxes.

### Key Transparency

**Goal:** Detect public key substitution attacks.

**Approach:** Publish all Ed25519 public keys in a verifiable, append-only log
(similar to Certificate Transparency for TLS). Clients can audit the log to
verify that their public key has not been replaced by an attacker.

**Benefit:** Detects attacks where the server (or an attacker who compromised
the server) substitutes a victim's public key with the attacker's key.

### Tor/I2P Integration

**Goal:** Hide client IP addresses from the server and network adversaries.

**Approach:** Route QUIC connections through the Tor network or I2P. The server
sees only the Tor exit node's IP, not the client's real IP.

**Benefit:** Prevents the server and network adversaries from linking
connections to physical locations or ISP accounts.

**Trade-off:** Significant latency increase. QUIC over Tor requires careful
configuration to avoid leaking the real IP through WebRTC-style mechanisms.

### Padding and Traffic Shaping

**Goal:** Defeat traffic analysis based on message sizes and timing.

**Approach:** Pad all messages to fixed sizes (or random sizes from a
distribution) and send dummy messages at regular intervals to mask real
communication patterns.

**Benefit:** Makes it harder for network adversaries and the server to infer
communication patterns from traffic analysis.

**Trade-off:** Increased bandwidth usage.

## Summary Table

| Threat | Current Protection | Gap | Planned Fix |
|--------|-------------------|-----|-------------|
| Passive eavesdropper | TLS 1.3 + MLS (2 layers) | Traffic analysis | Padding, Tor |
| Active MITM | TLS 1.3 (QUIC) | Self-signed certs | Cert pinning, CA |
| Compromised server | MLS E2E encryption + Sealed Sender | Metadata partially visible | PIR |
| Compromised client | FS + PCS | Current epoch exposed | Periodic Updates |
| Spam/flooding | Rate limiting + OPAQUE session tokens | -- | -- |
| Username enumeration | 5ms timing floor on all auth responses | -- | -- |
| Key substitution | None | BasicCredential only | Key Transparency |
| Quantum adversary (content) | Hybrid KEM (X25519 + ML-KEM-768) | Pre-v2 messages | -- |
| Quantum adversary (transport) | None | Classical TLS (ECDHE) | PQ TLS |

## Related Pages

- [Cryptography Overview](overview.md) -- algorithm inventory and security levels
- [Forward Secrecy](forward-secrecy.md) -- protecting past messages
- [Post-Compromise Security](post-compromise-security.md) -- protecting future messages
- [Post-Quantum Readiness](post-quantum-readiness.md) -- ML-KEM-768 and the PQ gap
- [Ed25519 Identity Keys](identity-keys.md) -- identity key used for MLS credentials
- [Key Lifecycle and Zeroization](key-lifecycle.md) -- key destruction guarantees