Security and privacy considerations
23. Security and Privacy Considerations
Section titled “23. Security and Privacy Considerations”23.1. Threat model
Section titled “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.
23.2. Security target
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.