Security and privacy considerations

23. Security and privacy considerations

23.1. Threat model

SOP considers:

• hostile relay infrastructure;
• hostile object storage;
• hostile network observers;
• stolen storage media;
• stolen locked nodes;
• compromised authorized nodes;
• malicious fleet peers;
• removed nodes;
• traffic analysis;
• replay;
• rollback;
• ciphertext substitution;
• malicious manifests or access records;
• metadata leakage;
• equality leakage;
• plaintext spill;
• cryptographic state persistence bugs.

Ciphertext substitution is countered differently on the two object planes. SOP-BLOB-1 binds chunk position inside the AEAD, so a substituted or relocated chunk fails authentication for a decryptor holding nothing but the object’s DEK. SOP-PME-1 carries no module AAD (Section 11.3), so mandatory storage_id verification (Section 11.10) is its only defense; an implementer MUST NOT reason from one plane to the other.

23.2. Security target

A production implementation SHOULD target:

Adversary position	What it obtains
External object-store compromise	Opaque encrypted Parquet. No content key, no plaintext footer, no semantic path names.
Relay compromise	Opaque MLS / SOP ciphertext. Routing and traffic metadata only.
Locked-node storage theft	Encrypted SOP objects and encrypted key stores.
Out-of-scope fleet node	No applicable domain-group secret, no applicable domain KEK, no object DEK.
Removed node	No new group epochs, no future domain KEKs.
Authorized unlocked-node compromise	Currently authorized plaintext may be exposed.

23.3. MLS is not authorization policy

RFC 9420 provides group cryptographic mechanisms but applications remain responsible for access-control decisions.

SOP MUST validate SSP policy before merging group membership changes.

23.4. Forward secrecy versus historical storage

MLS application messaging benefits from MLS’s forward-secret key schedule.

SOP historical data intentionally remains decryptable by nodes granted historical access.

These are different security properties and MUST NOT be conflated.

23.5. Post-compromise security

MLS updates can provide post-compromise recovery for future MLS group secrets when the protocol assumptions are met.

They cannot remove SOP keys or plaintext already exfiltrated by a compromised node.

23.6. Metadata

SOP treats the following as potentially sensitive user data:

• schema names;
• table names;
• column names;
• statistics;
• row counts;
• timestamps;
• producer site;
• partition values;
• delete keys;
• domain labels;
• access patterns.

23.7. Traffic analysis

Neither MLS nor PME hides all transfer timing, peer relationship, or object size information.

For object and applicable control-message length padding, SOP adopts Padmé rather than defining bespoke bucket boundaries.

Implementations MAY additionally use:

• batching;
• delayed transfer;
• private relays;
• relay-preferred modes;

for higher-sensitivity domains.

Padmé reduces size leakage but does not hide transfer timing, peer relationships, object reuse, or access frequency.

23.8. Key-store deletion

The security properties of OpenMLS depend in part on its storage provider actually removing obsolete secret state when requested.

A production storage provider MUST be reviewed specifically for journaling, backup, copy-on-write, and secure-deletion behavior.

Where physical deletion cannot be guaranteed, the design SHOULD rely on encrypted storage with independently erasable wrapping keys to approximate cryptographic deletion.

23.9. Backup

Automatic node backup can accidentally duplicate:

• OpenMLS state;
• historical domain keys;
• hardware-unwrapped key material;
• application databases.

Backup behavior MUST be part of the threat model and platform integration.

23.10. Recovery

SOP does not introduce a vendor-held recovery/decryption key.

Any recovery architecture that gives a vendor or another third party the ability to derive user data keys changes the fleet-private trust model and requires a separate RFC.

23.11. Compelled access (non-normative)

This section is commentary. It carries no RFC 2119 keywords deliberately: a representation about what can be compelled is jurisdiction-dependent and contingent on legislation, and a MUST that is later falsified is a misrepresentation rather than a bug. Nothing in Sections 5.2 through 5.4, and nothing in the substrate signature profile, depends on this section.

Where the key lives changes what a production order can reach — for hardware roots, and for production of an existing copy. A node root generated in and non-extractable from a secure element cannot be surrendered as an object, because no copy exists at the operator, in a backup, or anywhere any party could be ordered to produce. That reasoning is scoped: it holds against orders for an existing copy (US possession-custody-control, EU e-Evidence, UK overseas production orders), and it does not hold for software or hosted-node roots, which SOVM/1 deliberately keeps (Section 5.2.3) and for which a copy does exist and a host can be compelled.

Compelled signing is a technical distinction, not a uniformly lighter legal one. That an attacker must possess the device and satisfy local authentication is a fact about the architecture. Its legal weight varies: in the US, compelling a passcode is testimonial and often privileged, so the design helps; in key-disclosure regimes — UK RIPA Part III, French Penal Code 434-15-2 — key and plaintext are equal alternatives and the distinction collapses. What the design buys everywhere is that compulsion becomes overt, in-person and participation-requiring rather than covert and directed at the company.

The absence of an escrow capability is a posture, not an immunity. Not building key escrow is a deliberate design choice and a data-minimisation one (GDPR Article 25). It is defensible; it is not a shield. Jurisdictions exist whose statutes reach the capability to build or assist — UK IPA s.253, Australia TOLA s.317T, China Counter-Terrorism Law Article 18 — and against those the honest statement is that an operator has chosen not to hold the capability, not that it cannot be asked to acquire one. Closing that gap is not a protocol matter and this specification does not attempt it.