Semi-Private Messages in the Messaging Layer Security (MLS) Protocol

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 19 April 2026.¶

Copyright Notice

Copyright (c) 2025 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

This document defines two extensions of MLS [RFC9420]. The first is the SemiPrivateMessage wire format, which allows an otherwise PrivateMessage to be shared with a predefined list of external receivers. It is restricted for use only with commits or proposals. The second is the external_receivers GroupContext extension that contains the list of external receivers and allows members to agree on that list.¶

SemiPrivateMessages are expected to be useful in federated environments where messages routinely cross multiple administrative domains, but the MLS Distribution Service needs to see the content of commits and proposals where group members would otherwise send handshakes using PublicMessage.¶

2. Conventions and Definitions

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.¶

This document uses terminology extensively from MLS [RFC9420] and the Safe Extensions framework, defined in Section 2 of [I-D.ietf-mls-extensions].¶

Whenever a hash function is mentioned, it refers to the hash function defined in the cipher suite in use for the relevant MLS group.¶

3. Syntax and Usage

The external_receivers GroupContext extension is used for all members to agree on the list of external receivers in the current epoch. Its construction mirrors the syntax of the external_senders extension in [RFC9420].¶

struct {
  HPKEPublicKey external_receiver_public_key;
  Credential credential;
} ExternalReceiver;

The mls_semiprivate_message wire format is advertised in the supported_wire_formats list in LeafNode.capabilities.extensions, (defined in Section 5 of [I-D.ietf-mls-extensions]). For SemiPrivateMessage to be used in a group, mls_semiprivate_message needs to be in the required_wire_formats list in the GroupContext.extension_types of that group, and there needs to be at least one entry in the external_receivers GroupContext extension.¶

SemiPrivateMessage substantially reuses the construction of PrivateMessage, but like a Welcome message also contains information (key_and_nonces) necessary to identify the sender leaf node and decrypt the SemiPrivateMessage struct's ciphertext. Note that the encrypted_sender_data cannot be decrypted by an external receiver, but the sender_leaf_index is included with key_and_nonces and is verified in another step. key_and_nonces is encrypted once for each external receiver in the external_receivers extension.¶

struct {
  opaque key<V>;
  opaque nonce<V>;
  opaque reuse_guard[4];
  uint32 sender_leaf_index;
} PerMessageKeyAndNonces;

partial_context_hash = hash(sender_leaf_index || nonce)

struct {
  opaque group_id<V>;
  uint64 epoch;
  opaque partial_context_hash<V>;
} SemiPrivateMessageContext;

PerMessageKeyAndNonces key_and_nonces;
SemiPrivateMessageContext semi_private_message_context;

encrypted_key_and_nonces = EncryptWithLabel(
  external_receiver_public_key,
  "SemiPrivateMessageReceiver",
  semi_private_message_context,   /* context */
  keys_and_nonces)

key_and_nonces = DecryptWithLabel(
  external_receiver_private_key,
  "SemiPrivateMessageReceiver",
  semi_private_message_context,  /* context */
  encrypted_keys_and_nonces.kem_output,
  encrypted_keys_and_nonces.ciphertext)

ExternalReceiverRef = hash(ExternalReceiver)

struct {
  ExternalReceiverRef external_receiver_ref;
  HPKECiphertext encrypted_keys_and_nonces;
} KeyForExternalReceiver;

framed_content_tbs_hash = hash(FramedContentTBS)

struct {
    opaque group_id<V>;
    uint64 epoch;
    ContentType content_type;
    opaque authenticated_data<V>;
    opaque partial_context_hash<V>;
    KeyForExternalReceiver keys_for_external_receivers<V>;
    opaque framed_content_tbs_hash<V>;
    opaque encrypted_sender_data<V>;
    opaque ciphertext<V>;
} SemiPrivateMessage;

struct {
    select (SemiPrivateMessage.content_type) {
        case proposal:
          Proposal proposal;
        case commit:
          Commit commit;
    };
    FramedContentAuthData auth;
    opaque padding[length_of_padding];
} SemiPrivateMessageContent;

struct {
    opaque group_id<V>;
    uint64 epoch;
    ContentType content_type;
    opaque authenticated_data<V>;
    opaque partial_context_hash<V>;
    KeyForExternalReceiver keys_for_external_receivers<V>;
    opaque framed_content_tbs_hash<V>;
} SemiPrivateContentAAD;

struct {
    ProtocolVersion version = mls10;
    WireFormat wire_format;
    select (MLSMessage.wire_format) {
        case mls_public_message:
            PublicMessage public_message;
        case mls_private_message:
            PrivateMessage private_message;
        ...
        case mls_semiprivate_message_:
            SemiPrivateMessage semiprivate_message;
    };
} MLSMessage;

4. Security Considerations

These two extensions provide a privacy improvement over sending handshake messages using PublicMessage. The handshake is shared with a specific list of receivers, and that list is visible as part of the GroupContext.¶

TODO More Security.¶

5. IANA Considerations

6. Normative References

[I-D.ietf-mls-extensions]

Robert, R., "The Messaging Layer Security (MLS) Extensions", Work in Progress, Internet-Draft, draft-ietf-mls-extensions-08, 21 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-mls-extensions-08>.

[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>.

[RFC9420]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

Appendix A. Change log

Author's Address