Control-plane messaging

10. Control-Plane Messaging

10.1. MLS PrivateMessage

Where a message is intended for members of an MLS group, SOVM SHOULD use MLS encrypted application messages rather than the custom SSP Epoch-2 group AEAD envelope.

This applies particularly to:

• membership-related application control;
• SOP manifests/access records where group delivery is appropriate;
• key-history packages;
• scope/domain control;
• small synchronization metadata.

10.2. No MLS Commit per ordinary message

MLS application messages MUST NOT advance the group epoch.

Ordinary messaging uses the MLS secret tree within the current epoch.

10.3. Outer transport wrapper

SSP/iroh MAY use a thin outer wrapper containing only information required to route opaque MLS bytes.

The wrapper SHOULD reveal as little semantic information as practical.

Conceptually:

destination routing token
message kind = opaque-mls
opaque MLS bytes

10.4. Store-and-forward

MLS does not itself provide a Delivery Service.

The existing SSP relay or another equivalent service continues to provide asynchronous storage and delivery.

The relay MUST NOT require access to MLS plaintext.

10.5. Padding

Where message padding is applied outside an existing fixed MLS padding rule, SOVM SHOULD use the Padmé target-length function rather than inventing ad-hoc bucket boundaries.

Padmé reduces length leakage to O(log log M) for maximum message size M with at most approximately 12% padding overhead and decreasing overhead at larger sizes.

Traffic analysis is reduced, not eliminated.

10.6. Non-group point-to-point cases

SOP/1 does not require every direct peer-control exchange to be encoded as an MLS application message if an already authenticated end-to-end transport and the application semantics make a point-to-point message more appropriate.

However, custom fleet-wide content encryption SHOULD NOT be reintroduced merely for convenience.