Compatibility, migration and operations
24. Compatibility and Migration
Section titled “24. Compatibility and Migration”24.1. SSP/1 semantics
Section titled “24.1. SSP/1 semantics”Revision 8 does not alter existing SSP event merge rules.
24.2. Existing custom Epoch-2 envelope design
Section titled “24.2. Existing custom Epoch-2 envelope design”The previously specified custom fleet-key envelope SHOULD be regarded as a migration source and compatibility mechanism rather than the preferred long-term cryptographic architecture if MLS is adopted.
A new protocol epoch or explicit capability is required.
24.3. Existing SSP bundles
Section titled “24.3. Existing SSP bundles”Existing Parquet event bundles remain valid under their defining RFC.
They MUST NOT be silently reinterpreted as SOP-PME-1 objects.
24.4. Table migration
Section titled “24.4. Table migration”Migration from SSP row replication to SOP object replication is explicit and per table.
24.5. Dual-stack transition
Section titled “24.5. Dual-stack transition”During migration a node MAY support:
- legacy SSP control envelope;
- MLS control messages;
- legacy event bundles;
- SOP-PME objects;
simultaneously, provided downgrade rules are explicit and fail closed where security requires the new mode.
25. Operational Considerations
Section titled “25. Operational Considerations”25.1. Complexity moved, not eliminated
Section titled “25.1. Complexity moved, not eliminated”MLS reduces bespoke cryptographic protocol but introduces group-state operations, durable sensitive storage, Welcome/Commit delivery, and fork handling.
This is a desirable trade if the implementation is robust.
25.2. Number of MLS groups
Section titled “25.2. Number of MLS groups”Too many cryptographic domains create:
- excess group state;
- excess KeyPackages;
- more membership commits;
- more key history;
- more mobile persistence.
Domain count SHOULD therefore remain small and policy-driven.
25.3. Key history growth
Section titled “25.3. Key history growth”Historical application KEK storage grows with security-relevant KEK generations, not with object count or routine MLS Commit count.
Because removals, compromise responses, and forward-only admissions should be rare, this should remain small.
25.4. Object DEK scale
Section titled “25.4. Object DEK scale”There may be many object DEKs.
Only wrapped DEKs need persistent catalog storage; the unwrapped keys SHOULD be short-lived in memory.
25.5. PME cost
Section titled “25.5. PME cost”Current DuckDB encrypted-Parquet support has non-trivial performance overhead relative to plaintext Parquet.
This MUST be benchmarked on representative hardware and data before final object-size targets are chosen.
25.6. Compaction remains expensive
Section titled “25.6. Compaction remains expensive”The dominant background cost is expected to remain read/decrypt/rewrite/ reencrypt compaction rather than MLS operations.
25.7. Membership latency
Section titled “25.7. Membership latency”A user adding/removing a node may need to wait for control-plane group state to converge before the new security state is effective across online peers.
That is acceptable for rare security-control operations.