Decentralized Messaging Layer Security

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 23 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

...¶

DMLS allows group members to keep around old group state a little more safely, because the init secret of old epoch states is punctured. However, keeping an old epoch state around is still not as safe as deleting it in the first place. See Section 6 for more details.¶

While DMLS is thus safer to use in scenarios where members must be able to process old commits, it is still not as safe as the use of vanilla MLS with its strict deletion schedule.¶

Even when using DMLS, applications should take care that group state forks are short-lived and group members (and/or assisting servers) endeavour to resolve forks as soon as possible.¶

In contrast scenarios should be avoided where multiple forks are long-lived. For example, if two or more parts of a group are not in contact with one-another and effectively run their own fork of the same group.¶

2. Epoch identifiers

In MLS, each epoch is identified by a 64 bit unsigned integer, with the epoch increasing by one with each commit. The integer identifies epochs uniquely as long as there is only one chain of Commits. However, in a decentralized context there can be multiple commits for the same epoch, which means that an integer is not sufficient to uniquely identify an epoch. For example, if two group member send a commit at the same time with different subsets of group members receiving a different commit first. After processing the newly arrived Commit, all group members would be in the same epoch, but in different group states. For subsequently arriving messages, it is unclear from the integer designating the epoch, which state the message belongs to. In such scenarios it is important that epochs are uniquely identifiable.¶

The dmls_epoch can be used for this purpose.¶

pseudocode dmls_epoch = DeriveSecret(epoch_secret, "epoch") ¶

A dmls_epoch is represented by byte strings of length KDF.Nh (thus depending on the group's ciphersuite). The byte string identifying an epoch is derived from the epoch's epoch_secret.¶

3. DMLS Messages

As regular MLSMessages only contain integer-based epoch identifiers, this section introduces DMLSMessages, a simple wrapper that adds a dmls_epoch header to an MLSMessage.¶

struct {
  MLSMessage message;
  opaque dmls_epoch<V>;
} DMLSMessage

DMLSMessages MUST NOT contain MLSMessages with WireFormat other than mls_public_message and mls_private_message.¶

4. DMLS key schedule

DMLS uses a modified version of the MLS key schedule that allows the derivation of multiple init_secrets, where each init secret can be used to initialize a subsequent epoch.¶

The individual init_secrets are derived through a puncturable pseudorandom function (PPRF, see Section 5) keyed by the base_init_secret.¶

commit_confirmation = DeriveSecret(path_secret[n], "conf")

DeriveChildSecret(prf_key, label, input_secret, context) =
  DeriveFSSecret(prf_key, ExpandWithLabel(input_secret, label, context, KDF.Nh))

5. Puncturable pseudorandom function

A PPRF allows the derivation of keys in a forward secure way. In particular, a PRF that was evaluated with a given key and input can't be evaluated with those same parameters again. Storing the original input key thus doesn't harm the forward secrecy of (deleted) output keys.¶

The MLS Secret Tree as defined in [RFC9420] already represents a PPRF an needs to be modified only slightly for the purpose of this document.¶

In the context of MLS, the Secret Tree has as many leaves as the group has members. To derive child init secrets, the same tree is used but with KDF.Nh leaves.¶

The function DeriveFSSecret(secret, input) thus follows these steps:¶

• Check if secret and input are of length KDF.Nh¶

• With secret as the root node secret and input as the leaf index, derive the direct path nodes and the copath nodes as defined in Section 9 of [RFC9420]¶

• With leaf_node_secret as the resulting secret compute the final output using DeriveSecret(leaf_node_secret, "pprf")¶

6. Security Considerations

The use of a PPRF to derive init secrets for new epochs significantly improves forward secrecy in scenarios where clients need to be able to process multiple commits for a given epoch.¶

However, PPRF only improves forward secrecy for the init secret. Group members must still delay the deletion of other secrets such as the (private) decryption keys for the nodes in the ratchet tree. This delay in deletion compromises the forward secrecy of the protocol. Conversely, the fact that other group members might encrypt to those keys in turn weakens the protocol's post-compromise security.¶

It is thus still advisable to delete old epoch states as soon as the functional requirements of the application allows it.¶

A rule that will be safe for most applications, for example, is that an old epoch state can be deleted once each group member has sent a commit on at least one fork "upstream" of that epoch state. This signals that all group members have agreed to continue using this particular fork of the group state.¶

For effective forward secrecy and post-compromise security it is thus advisable to choose a state management algorithm where members converge on a shared fork rather than continuously using different forks of the same group.¶

7. IANA Considerations

This document has no IANA actions.¶

8. References

Acknowledgments

TODO acknowledge.¶

Author's Address