Robust and Privacy-Preserving Delivery Service

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 28 December 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

TODO Introduction¶

2. Conventions and Definitions

The following abbreviations are used where convenient:¶

Local Service Provider (LSP):

The Service Provider preferred by the referenced user.¶

Remote Service Provider (RSP):

Any Service Provider which is not the LSP.¶

Hub:

The Service Provider which created and hosts a referenced group. Group messages and Welcome messages are always sent to the hub for sequencing and fanout.¶

Follower:

Service Providers that interact with a hub to allow their users to interact with a group which the hub hosts.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Partition Keys

A partition key is a short secret that group members export from the MLS key schedule. Whenever members send or receive group messages, they provide the partition key for the current epoch. Messages sent with a given partition key are only provided to users who request to receive messages with the same partition key. (Exceptions may be selectively made for external commits / proposals, given that the sender isn't in the group yet.)¶

The partition key acts as epoch-level access control, in addition to the group ID. Users which have been removed from a group may still be able to message the group, as they know the group ID. However, they will not know the correct partition key.¶

Service Providers MUST NOT implement hard-and-fast rules about which partition keys are acceptable. Instead, it should be considered as a general signal of abuse or spam.¶

4. Endpoints

The following endpoints are provided by a Delivery Service. All endpoints exposed by a Delivery Service are accessed by third-party Service Providers, for the purpose of learning about the Service Provider's users or interacting with a group for which the Service Provider is the hub.¶

struct {
  opaque user_id<V>;
  opaque bearer_token<V>;
  ProtocolVersion version;
  CipherSuite cipher_suite;
} KeyPackageRequest;

struct {
  KeyPackage key_package;
} KeyPackageResponse;

opaque PartitionKey<16>;
opaque ServiceProviderId<V>;

struct {
  MLSMessage welcome; // Welcome
  ServiceProviderId service_providers<V>;
} WelcomeData;

struct {
  PartitionKey next_partition_key;
  optional<MLSMessage> group_info; // GroupInfo
  optional<WelcomeData> welcome_data;
} CommitData;

struct {
  MLSMessage message; // PublicMessage or PrivateMessage
  PartitionKey partition_key;
  select (SendRequest.message.content_type) {
    case application:
    case proposal:
    case commit:
      CommitData commit_data;
  }
} SendRequest;

struct {
  KeyPackageRef key_package_refs<V>;
} WelcomeInitRequest;

struct {
  PartitionKey partition_key;
  uint32 counter;
} ReceiveRequest;

opaque MaskedPartitionKey<V>; // = Hash(partition_key)

struct {
  MLSMessage message; // PublicMessage or PrivateMessage
  select (Message.message.content_type) {
    case application:
    case proposal:
    case commit:
      MaskedPartitionKey next_partition_key;
      optional<MLSMessage> group_info; // GroupInfo
  }
} Message;

struct {
  Message messages<V>;
} Epoch;

struct {
  MaskedPartitionKey masked_partition_key;
  Epoch epoch;
} HintedEpoch;

struct {
  Epoch epoch;
  HintedEpoch hints<V>;
} ReceiveResponse;

struct {
  MLSMessage message; // PublicMessage
  CommitData commit_data;
} ExternalJoinRequest;

struct {
  opaque group_id<V>;
} GroupInfoRequest;

struct {
  MLSMessage group_info; // GroupInfo;
  optional<RatchetTree> ratchet_tree;
} GroupInfoResponse;

5. Fork Termination

The endpoints above are designed to gracefully support forks in the group state through the use of the partition key. Forks can occur when a buggy or malicious member sends a Commit which members of the group are unable to process, or that members of the group reject for violating policy. In this case, the malicious/buggy member would process its own Commit, moving to a new epoch with a new partition key, while all other group members ignore it and stay in the current epoch. Forks can also occur when a member attempts to externally join a group, and the Delivery Service sequences the external Commit to an incorrect partition key (such as one resulting from the previous case).¶

When a hub detects that the group state has forked, it MAY decide to terminate one of the branches by blocking further messages from being sent to its partition key. When or if to terminate a branch, is left to the discretion of the hub. Users MUST NOT respond to a branch termination by automatically issuing an external join to rejoin the group.¶

6. Policy Enforcement

Generally, a hub or follower DS is only able to enforce "negative" policy on the aspects of the group state that it has visiblity into. "Negative" policy consists of rules for rejecting messages which are unambiguously invalid. Examples of such rules might include rejecting application messages from a user that is muted, or rejecting a commit that contains an Add proposal for a banned user.¶

Keeping in mind that the group may fork when there are buggy or malicious clients, but that clients clearly indicate which fork they are sending their message to, the DS must always make policy enforcmenent decisions with respect to the group state as it exists in the indicated fork. If one fork of a group exists where a proposal was sent that updated the group metadata to ban a specific user, but another fork exists where this proposal was not sent (or not accepted), the ban must only apply in the fork that accepted the proposal.¶

A DS MUST NOT reject messages based on criteria that are not unambiguously known by the DS to be satisfied. In particular, a DS can not enforce a per-user rate limit on messages sent to the group for any users that are not local to the DS. When the DS has a local relationship with a user, the DS can authenticate the user and unambiguously rate-limit just them. However, a hub DS can not rate-limit a follower DS's users without speculating on an MLS message's content.¶

It's understood that hub servers will make arrangements with follower servers, where the follower server enforces the hub's policies in situations where the hub can not, as a precondition to interoperate. This includes rate limits but also for example, if one of the follower server's users are banned by the hub, enforcing that the banned user is not allowed in any groups hosted by the hub. (Noting that the hub would be unable to ban a follower server's user themselves, in cases where a group's handshake messages are encrypted.)¶

Ultimately, while a DS can reject some abusive messages, clients must be aware of the policy a group is under and enforce it themselves. Messages which violate the group's policy MUST be ignored and supressed by the UI, as if they were cryptographically invalid. Clients SHOULD report to their local DS when the hub or another follower is not meeting the preconditions to interoperate.¶

A DS MUST NOT enforce "positive" policy decisions, consisting of rules that require a given message to be accepted by the members of the group.¶

7. Example Flows

8. IANA Considerations

This document has no IANA actions.¶

9. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.¶

Author's Address