Internet Engineering Task Force (IETF) B. Beurdouche
Request for Comments: 9750 Inria & Mozilla
Category: Informational E. Rescorla
ISSN: 2070-1721
E. Omara
S. Inguva
A. Duric
April 2025
The Messaging Layer Security (MLS) protocol (RFC 9420) provides a group key agreement protocol for messaging applications. MLS is designed to protect against eavesdropping, tampering, and message forgery, and to provide forward secrecy (FS) and post-compromise security (PCS).
メッセージングレイヤーセキュリティ（MLS）プロトコル（RFC 9420）は、メッセージングアプリケーション向けのグループキー合意プロトコルを提供します。MLSは、盗聴、改ざん、メッセージの偽造から保護し、前方秘匿性（FS）および侵害後のセキュリティ（PCS）を提供するように設計されています。
This document describes the architecture for using MLS in a general secure group messaging infrastructure and defines the security goals for MLS. It provides guidance on building a group messaging system and discusses security and privacy trade-offs offered by multiple security mechanisms that are part of the MLS protocol (e.g., frequency of public encryption key rotation). The document also provides guidance for parts of the infrastructure that are not standardized by MLS and are instead left to the application.
このドキュメントでは、一般的なセキュアグループメッセージングインフラストラクチャでMLSを使用するためのアーキテクチャについて説明し、MLSのセキュリティ目標を定義します。グループメッセージングシステムの構築に関するガイダンスを提供し、MLSプロトコルの一部である複数のセキュリティメカニズム（例：公開暗号化キーのローテーション頻度）によって生じるセキュリティとプライバシーのトレードオフについて議論します。また、MLSによって標準化されておらず、アプリケーションに委ねられているインフラストラクチャ部分についてのガイダンスも提供します。
While the recommendations of this document are not mandatory to follow in order to interoperate at the protocol level, they affect the overall security guarantees that are achieved by a messaging application. This is especially true in the case of active adversaries that are able to compromise clients, the Delivery Service (DS), or the Authentication Service (AS).
このドキュメントの推奨事項は、プロトコルレベルでの相互運用性のために従うことが必須ではありませんが、メッセージングアプリケーションによって達成される全体的なセキュリティ保証に影響を与えます。これは、クライアント、配信サービス（DS）、または認証サービス（AS）を侵害できる能動的な攻撃者が存在する場合に特に当てはまります。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準化過程（Standards Track）の仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の成果物です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）によって公開が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のいずれかのレベルの候補となるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9750.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9750で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2025 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメントに関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の発行日における有効な規定に従います。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eに記載されている改訂BSDライセンスのテキストを含める必要があり、改訂BSDライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. General Setting
2.1. Protocol Overview
2.2. Abstract Services
3. Overview of Operation
3.1. Step 1: Account Creation
3.2. Step 2: Initial Keying Material
3.3. Step 3: Adding Bob to the Group
3.4. Step 4: Adding Charlie to the Group
3.5. Other Group Operations
3.6. Proposals and Commits
3.7. Users, Clients, and Groups
4. Authentication Service
5. Delivery Service
5.1. Key Storage and Retrieval
5.2. Delivery of Messages
5.2.1. Strongly Consistent
5.2.2. Eventually Consistent
5.2.3. Welcome Messages
5.3. Invalid Commits
6. Functional Requirements
6.1. Membership Changes
6.2. Parallel Groups
6.3. Asynchronous Usage
6.4. Access Control
6.5. Handling Authentication Failures
6.6. Recovery After State Loss
6.7. Support for Multiple Devices
6.8. Extensibility
6.9. Application Data Framing and Type Advertisements
6.10. Federation
6.11. Compatibility with Future Versions of MLS
7. Operational Requirements
8. Security and Privacy Considerations
8.1. Assumptions on Transport Security Links
8.1.1. Integrity and Authentication of Custom Metadata
8.1.2. Metadata Protection for Unencrypted Group Operations
8.1.3. DoS Protection
8.1.4. Message Suppression and Error Correction
8.2. Intended Security Guarantees
8.2.1. Message Secrecy and Authentication
8.2.2. Forward Secrecy and Post-Compromise Security
8.2.3. Non-Repudiation vs. Deniability
8.2.4. Associating a User's Clients
8.3. Endpoint Compromise
8.3.1. Compromise of Symmetric Keying Material
8.3.2. Compromise by an Active Adversary with the Ability to
Sign Messages
8.3.3. Compromise of Authentication with Access to a Signature
Key
8.3.4. Security Considerations in the Context of a Full State
Compromise
8.4. Service Node Compromise
8.4.1. General Considerations
8.4.2. Delivery Service Compromise
8.4.3. Authentication Service Compromise
8.5. Considerations for Attacks Outside of the Threat Model
8.6. No Protection Against Replay by Insiders
8.7. Cryptographic Analysis of the MLS Protocol
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Contributors
Authors' Addresses
End-to-end security is used in the vast majority of instant messaging systems and is also deployed in systems for other purposes such as calling and conferencing. In this context, "end-to-end" captures the notion that users of the system enjoy some level of security -- with the precise level depending on the system design -- even in the face of malicious actions by the operator of the messaging system.
エンドツーエンドのセキュリティは、インスタントメッセージングシステムの大部分で使用されており、通話や会議などの他の目的のシステムにも展開されています。この文脈において、「エンドツーエンド」とは、メッセージングシステムの運用者による悪意のある行為があったとしても、システムのユーザーがある程度のセキュリティ（正確なレベルはシステム設計に依存する）を享受できるという概念を表しています。
Messaging Layer Security (MLS) specifies an architecture (this document) and a protocol [RFC9420] for providing end-to-end security in this setting. MLS is not intended as a full instant messaging protocol but rather is intended to be embedded in concrete protocols, such as the Extensible Messaging and Presence Protocol (XMPP) [RFC6120]. Implementations of the MLS protocol will interoperate at the cryptographic level, though they may have incompatibilities in terms of how protected messages are delivered, contents of protected messages, and identity/authentication infrastructures. The MLS protocol has been designed to provide the same security guarantees to all users, for all group sizes, including groups of only two clients.
メッセージングレイヤーセキュリティ（MLS）は、この設定でエンドツーエンドのセキュリティを提供するためのアーキテクチャ（本書）とプロトコル[RFC9420]を規定します。MLSは、完全なインスタントメッセージングプロトコルとしてではなく、Extensible Messaging and Presence Protocol（XMPP）[RFC6120]などの具体的なプロトコルに組み込まれることを意図しています。MLSプロトコルの実装は、暗号化レベルで相互運用しますが、保護されたメッセージの配信方法、保護されたメッセージの内容、およびID/認証インフラストラクチャの点では互換性がない場合があります。MLSプロトコルは、2つのクライアントのみのグループを含むすべてのグループサイズに対して、すべてのユーザーに同じセキュリティ保証を提供するように設計されています。
MLS provides a way for _clients_ to form _groups_ within which they can communicate securely. For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other. A group may be as small as two clients (e.g., for simple person-to-person messaging) or as large as hundreds of thousands. A client that is part of a group is a _member_ of that group. As groups change membership and group or member properties, they advance from one _epoch_ to another and the cryptographic state of the group evolves.
MLSは、_クライアント（clients）_が_グループ（groups）_を形成し、その中で安全に通信できる方法を提供します。たとえば、一連のユーザーは、携帯電話やラップトップ上のクライアントを使用してグループに参加し、相互に通信する場合があります。グループは、2つのクライアント（単純な1対1のメッセージングなど）から数十万のクライアントまで、さまざまな規模になります。グループの一部であるクライアントは、そのグループの_メンバー（member）_です。グループのメンバーシップやグループまたはメンバーのプロパティが変更されると、グループは1つの_エポック（epoch）_から次のエポックへと進み、グループの暗号学的状態が進化します。
The group is represented as a tree, which represents the members as the leaves of a tree. It is used to efficiently encrypt to subsets of the members. Each member has a state called a _LeafNode_ object holding the client's identity, credentials, and capabilities.
グループはツリーとして表現され、メンバーはそのツリーの葉（リーフ）として表されます。これは、メンバーのサブセットに対して効率的に暗号化を行うために使用されます。各メンバーは、クライアントのID、資格情報、および機能を保持する_LeafNode_オブジェクトと呼ばれる状態を持っています。
Various messages are used in the evolution from epoch to epoch. A _Proposal_ message proposes a change to be made in the next epoch, such as adding or removing a member. A _Commit_ message initiates a new epoch by instructing members of the group to implement a collection of proposals. Proposals and Commits are collectively called _handshake messages_. A _KeyPackage_ provides keys that can be used to add the client to a group, including a public encryption key and a signature key (both stored in the KeyPackage's LeafNode object). A _Welcome_ message provides a new member to the group with the information to initialize their state for the epoch in which they were added.
エポックからエポックへの進化には、さまざまなメッセージが使用されます。_Proposal（提案）_メッセージは、メンバーの追加や削除など、次のエポックで行う変更を提案します。_Commit（コミット）_メッセージは、グループのメンバーに一連の提案を適用するよう指示することで、新しいエポックを開始します。提案とコミットはまとめて_ハンドシェイクメッセージ（handshake messages）_と呼ばれます。_KeyPackage_は、公開暗号化キーと署名キー（両方ともKeyPackageのLeafNodeオブジェクトに格納されています）など、クライアントをグループに追加するために使用できるキーを提供します。_Welcome_メッセージは、グループへの新しいメンバーに対し、そのメンバーが追加されたエポックの状態を初期化するための情報を提供します。
Of course most (but not all) applications use MLS to send encrypted group messages. An _application message_ is an MLS message with an arbitrary application payload.
もちろん、ほとんどの（すべてではありませんが）アプリケーションはMLSを使用して暗号化されたグループメッセージを送信します。_Application Message（アプリケーションメッセージ）_は、任意のアプリケーションペイロードを持つMLSメッセージです。
Finally, a _PublicMessage_ contains an integrity-protected MLS handshake message, while a _PrivateMessage_ contains a confidential, integrity-protected handshake or application message.
最後に、_PublicMessage_には整合性保護されたMLSハンドシェイクメッセージが含まれていますが、_PrivateMessage_には機密性があり整合性保護されたハンドシェイクまたはアプリケーションメッセージが含まれています。
For a more detailed explanation of these terms, please consult the MLS protocol specification [RFC9420].
これらの用語のより詳細な説明については、MLSプロトコル仕様[RFC9420]を参照してください。
MLS is designed to operate within the context of a messaging service, which may be a single service provider, a federated system, or some kind of peer-to-peer system. The service needs to provide two services that facilitate client communication using MLS:
MLSは、メッセージングサービスのコンテキスト内で動作するように設計されています。これは、単一のサービスプロバイダー、フェデレーションシステム、またはある種のピアツーピアシステムである可能性があります。このサービスは、MLSを使用したクライアント間の通信を促進する2つのサービスを提供する必要があります。
* An Authentication Service (AS), which is responsible for attesting to bindings between application-meaningful identifiers and the public key material used for authentication in the MLS protocol. The AS must also be able to generate credentials that encode these bindings and validate credentials provided by MLS clients.
* 認証サービス（AS）：アプリケーションにとって意味のある識別子と、MLSプロトコルでの認証に使用される公開鍵マテリアルとの間のバインディング（紐付け）を証明する責任があります。ASは、これらのバインディングをエンコードした資格情報を生成し、MLSクライアントから提供された資格情報を検証できる必要があります。
* A Delivery Service (DS), which can receive and distribute messages between group members. In the case of group messaging, the DS may also be responsible for acting as a "broadcaster" where the sender sends a single message which is then forwarded to each recipient in the group by the DS. The DS is also responsible for storing and delivering initial public key material required by MLS clients in order to proceed with the group secret key establishment that is part of the MLS protocol.
* 配信サービス（DS）：グループメンバー間でメッセージを受信および配布できます。グループメッセージングの場合、DSは「ブロードキャスター」として機能し、送信者が送信した単一のメッセージをグループ内の各受信者に転送する責任を負うこともあります。DSはまた、MLSプロトコルの一部であるグループ秘密鍵の確立を進めるためにMLSクライアントが必要とする初期公開鍵マテリアルを保存および配信する責任もあります。
For presentation purposes, this document treats the AS and DS as conventional network services. However, MLS does not require a specific implementation for the AS or DS. These services may reside on the same server or different servers, they may be distributed between server and client components, and they may even involve some action by users. For example:
説明のために、このドキュメントではASとDSを従来のネットワークサービスとして扱います。ただし、MLSはASまたはDSの特定の実装を必要としません。これらのサービスは、同じサーバーまたは異なるサーバーに存在する場合もあれば、サーバーコンポーネントとクライアントコンポーネントの間で分散される場合もあり、ユーザーによるアクションを伴う場合さえあります。例えば：
* Several secure messaging services today provide a centralized DS and rely on manual comparison of clients' public keys as the AS.
* 今日のいくつかのセキュアメッセージングサービスは、集中型DSを提供し、ASとしてクライアントの公開鍵の手動比較に依存しています。
* MLS clients connected to a peer-to-peer network could instantiate a decentralized DS by transmitting MLS messages over that network.
* ピアツーピアネットワークに接続されているMLSクライアントは、そのネットワークを介してMLSメッセージを送信することにより、分散型DSをインスタンス化できます。
* In an MLS group using a Public Key Infrastructure (PKI) for authentication, the AS would comprise the certificate issuance and validation processes, both of which involve logic inside MLS clients as well as various existing PKI roles (e.g., Certification Authorities).
* 認証に公開鍵基盤（PKI）を使用するMLSグループでは、ASは証明書の発行および検証プロセスで構成されます。これには、MLSクライアント内のロジックと、既存のさまざまなPKIロール（認証局など）の両方が関与します。
It is important to note that the AS can be completely abstract in the case of a service provider which allows MLS clients to generate, distribute, and validate credentials themselves. As with the AS, the DS can be completely abstract if users are able to distribute credentials and messages without relying on a central DS (as in a peer-to-peer system). Note, though, that in such scenarios, clients will need to implement logic that assures the delivery properties required of the DS (see Section 5.2).
MLSクライアントが資格情報を自身で生成、配布、および検証できるサービスプロバイダーの場合、ASは完全に抽象的である可能性があることに注意することが重要です。ASと同様に、ユーザーが中央のDSに依存せずに資格情報やメッセージを配布できる場合（ピアツーピアシステムのように）、DSは完全に抽象的になる可能性があります。ただし、そのようなシナリオでは、クライアントはDSに求められる配信特性を保証するロジックを実装する必要があることに注意してください（セクション5.2を参照）。
Figure 1 shows the relationship of these concepts, with three clients and one group, and clients 2 and 3 being part of the group and client 1 not being part of any group.
図1は、これらの概念の関係を示しており、3つのクライアントと1つのグループがあり、クライアント2と3はグループの一部であり、クライアント1はどのグループの一部でもありません。
+----------------+ +--------------+
| Authentication | | Delivery |
| Service (AS) | | Service (DS) |
+----------------+ +-------+------+
/ | \ Group
/ ........|........\................
/ . | \ .
+--------+-+ . +----+-----+ +----------+ .
| Client 1 | . | Client 2 | | Client 3 | .
+----------+ . +----------+ +----------+ .
. Member 1 Member 2 .
. .
..................................
Figure 1: A Simplified Messaging System
図1：単純化されたメッセージングシステム
Figure 2 shows the formation of an example group consisting of Alice, Bob, and Charlie, with Alice driving the creation of the group.
図2は、アリス、ボブ、チャーリーで構成されるサンプルグループの形成を示しており、アリスはグループの作成を推進しています。
Alice Bob Charlie AS DS
Create account ---------------------------------> |
<------------------------------------- Credential |
Create account -----------------------> | Step 1
<--------------------------- Credential |
Create account -------------> |
<----------------- Credential |
Initial Keying Material -----------------------------------> |
Initial Keying Material -------------------------> | Step 2
Initial Keying Material ---------------> |
Get Bob Initial Keying Material ---------------------------> |
<------------------------------- Bob Initial Keying Material |
Add Bob to group ------------------------------------------> | Step 3
Welcome(Bob) ----------------------------------------------> |
<-------------------------------- Add Bob to group |
<------------------------------------ Welcome(Bob) |
Get Charlie Initial Keying Material -----------------------> |
<--------------------------- Charlie Initial Keying Material |
Add Charlie to group --------------------------------------> |
Welcome(Charlie) ------------------------------------------> | Step 4
<---------------------------- Add Charlie to group |
<----------------- Add Charlie to group |
<--------------------- Welcome(Charlie) |
Figure 2: Group Formation Example
図2：グループ形成の例
This process proceeds as follows.
このプロセスは次のように進行します。
Alice, Bob, and Charlie create accounts with a service provider and obtain credentials from the AS. This is a one-time setup phase.
アリス、ボブ、チャーリーは、サービスプロバイダーでアカウントを作成し、ASから資格情報を取得します。これは1回限りのセットアップフェーズです。
Alice, Bob, and Charlie authenticate to the DS and store some initial keying material which is used to send encrypted messages to them for the first time. This keying material is authenticated with their long-term credentials. Although in principle this keying material can be reused for multiple senders, in order to provide forward secrecy it is better for this material to be regularly refreshed so that each sender can use a new key and delete older keys.
アリス、ボブ、チャーリーはDSに対して認証を行い、初めて暗号化されたメッセージを彼らに送信するために使用される初期鍵マテリアルを保存します。この鍵マテリアルは、彼らの長期的な資格情報で認証されています。原則として、この鍵マテリアルは複数の送信者に対して再利用できますが、前方秘匿性を提供するためには、各送信者が新しいキーを使用して古いキーを削除できるように、このマテリアルを定期的に更新することが望ましいです。
When Alice wants to create a group including Bob, she first uses the DS to look up his initial keying material. She then generates two messages:
アリスがボブを含むグループを作成したいとき、彼女は最初にDSを使用して彼の最初のキーイング素材を調べます。その後、彼女は2つのメッセージを生成します。
* A message to the entire group (which at this point is just her and Bob) that adds Bob to the group.
* グループ全体（この時点で彼女とボブ）全体へのメッセージは、グループにボブを追加します。
* A Welcome message just to Bob encrypted with his initial keying material that includes the secret keying information necessary to join the group.
* グループに参加するために必要な秘密のキーイング情報を含む彼の最初のキーイング素材で暗号化されたボブへのウェルカムメッセージ。
She sends both of these messages to the DS, which is responsible for sending them to the appropriate people. Note that the security of MLS does not depend on the DS forwarding the Welcome message only to Bob, as it is encrypted for him; it is simply not necessary for other group members to receive it.
彼女はこれらのメッセージの両方をDSに送信し、DSはそれらを適切な人々に送信する責任を負います。MLSのセキュリティは、DSがWelcomeメッセージをボブにのみ転送することに依存しているわけではないことに注意してください（メッセージは彼のために暗号化されているため）。単に他のグループメンバーがそれを受け取る必要がないだけです。
If Alice then wants to add Charlie to the group, she follows a similar procedure as with Bob. She first uses the DS to look up his initial keying material and then generates two messages:
アリスがグループにチャーリーを追加したい場合、彼女はボブと同様の手順に従います。彼女は最初にDSを使用して彼の最初のキーイング素材を検索し、次に2つのメッセージを生成します。
* A message to the entire group (consisting of her, Bob, and Charlie) adding Charlie to the group.
* グループ全体（彼女、ボブ、チャーリーで構成される）へのメッセージは、グループにチャーリーを追加します。
* A Welcome message just to Charlie encrypted with his initial keying material that includes the secret keying information necessary to join the group.
* グループに参加するために必要な秘密のキーイング情報を含む彼の最初のキーイング素材で暗号化されたチャーリーへのウェルカムメッセージ。
At the completion of this process, we have a group with Alice, Bob, and Charlie, which means that they share a single encryption key which can be used to send messages or to key other protocols.
このプロセスが完了すると、アリス、ボブ、チャーリーとのグループがあります。つまり、メッセージの送信や他の主要なプロトコルに使用できる単一の暗号化キーを共有しています。
Once the group has been created, clients can perform other actions, such as:
グループが作成されると、クライアントは次のような他のアクションを実行できます。
* sending a message to everyone in the group
* グループの全員にメッセージを送信します
* receiving a message from someone in the group
* グループの誰かからメッセージを受け取る
* adding one or more clients to an existing group
* 既存のグループに1つ以上のクライアントを追加します
* removing one or more members from an existing group
* 既存のグループから1人以上のメンバーを削除します
* updating their own key material
* 独自の重要な資料を更新します
* leaving a group (by asking to be removed)
* グループを去る（削除するように求めることによって）
Importantly, MLS does not itself enforce any access control on group operations. For instance, any member of the group can send a message to add a new member or to evict an existing member. This is in contrast to some designs in which there is a single group controller who can modify the group. MLS-using applications are responsible for setting their own access control policies. For instance, if only the group administrator is allowed to change group members, then it is the responsibility of the application to inform members of this policy and who the administrator is.
重要なことに、MLS自体はグループ操作に対するアクセス制御を強制しません。たとえば、グループのどのメンバーも、新しいメンバーを追加したり、既存のメンバーを追放したりするメッセージを送信できます。これは、グループを変更できる単一のグループコントローラーが存在する一部の設計とは対照的です。MLSを使用するアプリケーションは、独自のアクセス制御ポリシーを設定する責任があります。たとえば、グループ管理者のみがグループメンバーを変更できる場合、このポリシーと管理者が誰であるかをメンバーに通知するのはアプリケーションの責任です。
The general pattern for any change in the group state (e.g., to add or remove a user) is that it consists of two messages:
グループ状態の変更の一般的なパターン（たとえば、ユーザーを追加または削除するため）は、2つのメッセージで構成されていることです。
Proposal:
提案：
This message describes the change to be made (e.g., add Bob to the group) but does not effect a change.
このメッセージは、行われる変更について説明しています（たとえば、グループにボブを追加）が、変更には影響しません。
Commit:
専念：
This message changes the group state to include the changes described in a set of proposals.
このメッセージは、グループの状態を変更して、一連の提案に記載されている変更を含めます。
The simplest pattern is for a client to just send a Commit which contains one or more Proposals. For instance, Alice could send a Commit with the Proposal Add(Bob) embedded to add Bob to the group. However, there are situations in which one client might send a Proposal and another might send the corresponding Commit. For instance, Bob might wish to remove himself from the group and send a Remove proposal to do so (see Section 12.1.3 of [RFC9420]). Because Bob cannot send the Commit, an existing member must do so. Commits can apply to multiple valid Proposals, in which case all the listed changes are applied.
最も単純なパターンは、クライアントが1つ以上の提案を含むコミットを送信することです。たとえば、アリスは、ボブをグループに追加するために埋め込まれたAdd(Bob)提案を含むコミットを送信できます。ただし、あるクライアントが提案を送信し、別のクライアントが対応するコミットを送信する状況もあります。たとえば、ボブがグループから脱退したいと考え、そのためにRemove提案を送信する場合などです（[RFC9420]のセクション12.1.3を参照）。ボブはコミットを送信できないため、既存のメンバーが送信する必要があります。コミットは複数の有効な提案に適用でき、その場合、リストされたすべての変更が適用されます。
It is also possible for a Commit to apply to an empty set of Proposals, in which case it just updates the cryptographic state of the group without changing its membership.
また、コミットを空の提案セットに適用することも可能です。その場合、メンバーシップを変更することなく、グループの暗号学的状態を更新するだけです。
While it's natural to think of a messaging system as consisting of groups of users, possibly using different devices, in MLS the basic unit of operation is not the user but rather the "client". Formally, a client is a set of cryptographic objects composed of public values such as a name (an identity), a public encryption key, and a public signature key. As usual, a user demonstrates ownership of the client by demonstrating knowledge of the associated secret values.
メッセージングシステムをユーザーのグループ（おそらく異なるデバイスを使用している）で構成されていると考えるのは自然ですが、MLSでは、操作の基本単位はユーザーではなく「クライアント」です。正式には、クライアントは、名前（アイデンティティ）、公開暗号化キー、公開署名キーなどの公開値で構成される暗号学的オブジェクトのセットです。通常、ユーザーは、関連する秘密値の知識を示すことによって、クライアントの所有権を証明します。
In some messaging systems, clients belonging to the same user must all share the same signature key pair, but MLS does not assume this; instead, a user may have multiple clients with the same identity and different keys. In this case, each client will have its own cryptographic state, and it is up to the application to determine how to present this situation to users. For instance, it may render messages to and from a given user identically regardless of which client they are associated with, or it may choose to distinguish them. It is also possible to have multiple clients associated with the same user share state, as described in Section 8.2.4.
一部のメッセージングシステムでは、同じユーザーに属するクライアントはすべて同じ署名キーペアを共有する必要がありますが、MLSはこれを想定していません。代わりに、ユーザーは同じアイデンティティと異なるキーを持つ複数のクライアントを持つことができます。この場合、各クライアントは独自の暗号学的状態を持ち、この状況をユーザーにどのように提示するかはアプリケーション次第です。たとえば、特定のユーザーとの間のメッセージを、どのクライアントに関連付けられているかに関係なく同一に表示する場合もあれば、それらを区別することを選択する場合もあります。セクション8.2.4で説明されているように、同じユーザーに関連付けられた複数のクライアントが状態を共有することも可能です。
When a client is part of a group, it is called a member. A group in MLS is defined as the set of clients that have knowledge of the shared group secret established in the group key establishment phase. Note that until a client has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the client is a member of the group; for instance, the newly added member might not have received the Welcome message or been unable to decrypt it for some reason.
クライアントがグループの一部である場合、メンバーと呼ばれます。MLSのグループは、グループキー確立フェーズで確立された共有グループシークレットの知識を持つクライアントのセットとして定義されます。クライアントがグループに追加され、グループの他のメンバーが検証可能な方法でグループシークレットに貢献するまで、他のメンバーはクライアントがグループのメンバーであると想定できないことに注意してください。たとえば、新しく追加されたメンバーは、Welcomeメッセージを受け取っていないか、何らかの理由でそれを復号化できなかった可能性があります。
The Authentication Service (AS) has to provide three services:
認証サービス（AS）は3つのサービスを提供する必要があります。
1. Issue credentials to clients that attest to bindings between identities and signature key pairs.
1. アイデンティティと署名キーペアの間のバインディング（紐付け）を証明する資格情報をクライアントに発行する。
2. Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier.
2. クライアントが、別のクライアントによって提示された資格情報が参照識別子に関して有効であることを検証できるようにする。
3. Enable a group member to verify that a credential represents the same client as another credential.
3. グループメンバーが、ある資格情報が別の資格情報と同じクライアントを表していることを検証できるようにする。
A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key bound by its credential.
有効な資格情報を持つメンバーは、その資格情報によってバインドされた公開鍵に対応する秘密鍵で署名することにより、MLSメッセージを認証します。
The AS is considered an abstract layer by the MLS specification; part of this service could be, for instance, running on the members' devices, while another part is a separate entity entirely. The following examples illustrate the breadth of this concept:
ASは、MLS仕様では抽象的なレイヤーと見なされます。このサービスの一部は、たとえばメンバーのデバイス上で実行されている可能性があり、別の部分は完全に別のエンティティである可能性があります。以下の例は、この概念の広がりを示しています。
* A PKI could be used as an AS [RFC5280]. The issuance function would be provided by the certificate authorities in the PKI, and the verification function would correspond to certificate verification by clients.
* PKIはASとして使用できます[RFC5280]。発行機能はPKIの認証局によって提供され、検証機能はクライアントによる証明書検証に対応します。
* Several current messaging applications rely on users verifying each other's key fingerprints for authentication. In this scenario, the issuance function is simply the generation of a key pair (i.e., a credential is just an identifier and public key, with no information to assist in verification). The verification function is the application function that enables users to verify keys.
* 現在のいくつかのメッセージングアプリケーションは、認証のためにユーザーが互いの鍵のフィンガープリントを検証することに依存しています。このシナリオでは、発行機能は単にキーペアの生成です（つまり、資格情報は単なる識別子と公開鍵であり、検証を支援する情報はありません）。検証機能は、ユーザーが鍵を検証できるようにするアプリケーション機能です。
* In a system based on end-user Key Transparency (KT) [KT], the issuance function would correspond to the insertion of a key in a KT log under a user's identity. The verification function would correspond to verifying a key's inclusion in the log for a claimed identity, together with the KT log's mechanisms for a user to monitor and control which keys are associated with their identity.
* エンドユーザーの鍵の透明性（KT）[KT]に基づくシステムでは、発行機能は、ユーザーのアイデンティティの下でKTログにキーを挿入することに対応します。検証機能は、ユーザーが自分のアイデンティティに関連付けられているキーを監視および制御するためのKTログのメカニズムとともに、主張されたアイデンティティに対するキーがログに含まれていることを検証することに対応します。
By the nature of its role in MLS authentication, the AS is invested with a large amount of trust and the compromise of the AS could allow an adversary to, among other things, impersonate group members. We discuss security considerations regarding the compromise of the different AS functions in detail in Section 8.4.3.
MLS認証におけるその役割の性質上、ASには多大な信頼が置かれており、ASが侵害されると、攻撃者はとりわけグループメンバーになりすますことが可能になる可能性があります。セクション8.4.3では、さまざまなAS機能の侵害に関するセキュリティ上の考慮事項について詳しく説明します。
The association between members' identities and their signature keys is fairly flexible in MLS. As noted above, there is no requirement that all clients belonging to a given user have the same signature key (in fact, having duplicate signature keys in a group is forbidden). A member can also rotate the signature key they use within a group. These mechanisms allow clients to use different signature keys in different contexts and at different points in time, providing unlinkability and post-compromise security benefits. Some security trade-offs related to this flexibility are discussed in Section 8.
メンバーのアイデンティティとその署名キーとの関連付けは、MLSではかなり柔軟です。前述のように、特定のユーザーに属するすべてのクライアントが同じ署名キーを持つ必要はありません（実際、グループ内で重複する署名キーを持つことは禁止されています）。メンバーは、グループ内で使用する署名キーをローテーションすることもできます。これらのメカニズムにより、クライアントはさまざまなコンテキストやさまざまな時点で異なる署名キーを使用でき、非連結性（unlinkability）と侵害後のセキュリティ（PCS）の利点を提供します。この柔軟性に関連するいくつかのセキュリティトレードオフについては、セクション8で説明します。
In many applications, there are multiple MLS clients that represent a single entity, such as a human user with a mobile and desktop version of an application. Often, the same set of clients is represented in exactly the same list of groups. In applications where this is the intended situation, other clients can check that a user is consistently represented by the same set of clients. This would make it more difficult for a malicious AS to issue fake credentials for a particular user because clients would expect the credential to appear in all groups of which the user is a member. If a client credential does not appear in all groups after some relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge. Due to the asynchronous nature of MLS, however, there may be transient inconsistencies in a user's client set, so correlating users' clients across groups is more of a detection mechanism than a prevention mechanism.
多くのアプリケーションでは、アプリケーションのモバイルバージョンとデスクトップバージョンを持つ人間のユーザーなど、単一のエンティティを表す複数のMLSクライアントが存在します。多くの場合、同じクライアントのセットがグループのまったく同じリストで表されます。これが意図された状況であるアプリケーションでは、他のクライアントは、ユーザーが同じクライアントのセットによって一貫して表現されていることを確認できます。これにより、悪意のあるASが特定のユーザーに対して偽の資格情報を発行することがより困難になります。なぜなら、クライアントはその資格情報がユーザーがメンバーであるすべてのグループに表示されることを期待するからです。ある程度の短期間が経過してもクライアントの資格情報がすべてのグループに表示されない場合、クライアントは、その資格情報がユーザーの知らないうちに作成された可能性があるという兆候を得ます。ただし、MLSの非同期的な性質のため、ユーザーのクライアントセットに一時的な不整合が生じる可能性があるため、グループ間でユーザーのクライアントを相関させることは、予防メカニズムというよりも検出メカニズムです。
The Delivery Service (DS) plays two major roles in MLS:
配送サービス（DS）は、MLSで2つの主要な役割を果たしています。
* As a directory service, providing the initial keying material for clients to use. This allows a client to establish a shared key and send encrypted messages to other clients even if they're offline.
* ディレクトリサービスとして、クライアントが使用するための初期鍵マテリアルを提供します。これにより、クライアントは共有キーを確立し、オフラインであっても、暗号化されたメッセージを他のクライアントに送信できます。
* Routing MLS messages among clients.
* クライアント間でのMLSメッセージのルーティング。
While MLS depends on correct behavior by the AS in order to provide endpoint authentication and hence confidentiality of the group key, these properties do not depend on correct behavior by the DS; even a malicious DS cannot add itself to groups or recover the group key. However, depending precisely on how MLS is used, the DS may be able to determine group membership or prevent changes to the group from taking place (e.g., by blocking group change messages).
MLSは、エンドポイント認証、ひいてはグループキーの機密性を提供するために、ASによる正しい動作に依存しますが、これらのプロパティはDSによる正しい動作には依存しません。悪意のあるDSでさえ、自身をグループに追加したり、グループキーを復元したりすることはできません。ただし、MLSの使用方法によっては、DSはグループメンバーシップを特定したり、グループへの変更が行われるのを防いだり（例：グループ変更メッセージをブロックすることによって）できる場合があります。
Upon joining the system, each client stores its initial cryptographic key material with the DS. This key material, called a KeyPackage, advertises the functional abilities of the client (e.g., supported protocol versions, supported extensions, etc.) and the following cryptographic information:
システムに参加すると、各クライアントは初期暗号鍵マテリアルをDSに保存します。KeyPackageと呼ばれるこの鍵マテリアルは、クライアントの機能的能力（サポートされているプロトコルバージョン、サポートされている拡張機能など）および次の暗号情報を提示します。
* A credential from the AS attesting to the binding between the identity and the client's signature key.
* アイデンティティとクライアントの署名キーとの間のバインディングを証明するASからの資格情報。
* The client's asymmetric encryption public key.
* クライアントの非対称暗号化公開鍵。
All the parameters in the KeyPackage are signed with the signature private key corresponding to the credential. As noted in Section 3.7, users may own multiple clients, each with their own keying material. Each KeyPackage is specific to an MLS version and cipher suite, but a client may want to offer support for multiple protocol versions and cipher suites. As such, there may be multiple KeyPackages stored by each user for a mix of protocol versions, cipher suites, and end-user devices.
KeyPackage内のすべてのパラメータは、資格情報に対応する署名秘密鍵で署名されます。セクション3.7で述べたように、ユーザーは複数のクライアントを所有する場合があり、それぞれが独自の鍵マテリアルを持っています。各KeyPackageはMLSバージョンと暗号スイートに固有ですが、クライアントは複数のプロトコルバージョンと暗号スイートのサポートを提供したい場合があります。そのため、プロトコルバージョン、暗号スイート、エンドユーザーデバイスの組み合わせのために、各ユーザーによって複数のKeyPackageが保存される場合があります。
When a client wishes to establish a group or add clients to a group, it first contacts the DS to request KeyPackages for each of the other clients, authenticates the KeyPackages using the signature keys, includes the KeyPackages in Add proposals, and encrypts the information needed to join the group (the _GroupInfo_ object) with an ephemeral key; it then separately encrypts the ephemeral key with the public encryption key (init_key) from each KeyPackage. When a client requests a KeyPackage in order to add a user to a group, the DS should provide the minimum number of KeyPackages necessary to satisfy the request. For example, if the request specifies the MLS version, the DS might provide one KeyPackage per supported cipher suite, even if it has multiple such KeyPackages to enable the corresponding client to be added to multiple groups before needing to upload more fresh KeyPackages.
クライアントがグループを確立したり、クライアントをグループに追加したりする場合、まずDSに連絡して他の各クライアントのKeyPackageを要求し、署名キーを使用してKeyPackageを認証し、Add提案にKeyPackageを含め、グループに参加するために必要な情報（_GroupInfo_オブジェクト）をエフェメラルキーで暗号化します。その後、各KeyPackageの公開暗号化キー（init_key）を使用して、エフェメラルキーを個別に暗号化します。クライアントがユーザーをグループに追加するためにKeyPackageを要求する場合、DSはリクエストを満たすために必要な最小数のKeyPackageを提供する必要があります。たとえば、リクエストがMLSバージョンを指定した場合、DSは、より多くの新鮮なKeyPackageをアップロードする必要がある前に、対応するクライアントを複数のグループに追加できるように複数のこのようなKeyPackageがある場合でも、サポートされている暗号スイートごとに1つのKeyPackageを提供できます。
In order to avoid replay attacks and provide forward secrecy for messages sent using the initial keying material, KeyPackages are intended to be used only once, and init_key is intended to be deleted by the client after decryption of the Welcome message. The DS is responsible for ensuring that each KeyPackage is only used to add its client to a single group, with the possible exception of a "last resort" KeyPackage that is specially designated by the client to be used multiple times. Clients are responsible for providing new KeyPackages as necessary in order to minimize the chance that the "last resort" KeyPackage will be used.
初期鍵マテリアルを使用して送信されたメッセージのリプレイ攻撃を回避し、前方秘匿性を提供するために、KeyPackageは一度だけ使用されることを意図しており、init_keyはWelcomeメッセージの復号化後にクライアントによって削除されることを意図しています。DSは、各KeyPackageがクライアントを単一のグループに追加するためにのみ使用されることを保証する責任があります。ただし、クライアントによって複数回使用されるように特別に指定された「ラストリゾート（last resort）」KeyPackageは例外となる可能性があります。クライアントは、「ラストリゾート」KeyPackageが使用される可能性を最小限に抑えるために、必要に応じて新しいKeyPackageを提供する責任があります。
*Recommendation:* Ensure that "last resort" KeyPackages don't get used by provisioning enough standard KeyPackages.
*推奨事項:* 十分な標準KeyPackageをプロビジョニングすることで、「ラストリゾート」KeyPackageが使用されないようにしてください。
*Recommendation:* Rotate "last resort" KeyPackages as soon as possible after being used or if they have been stored for a prolonged period of time. Overall, avoid reusing "last resort" KeyPackages as much as possible.
*推奨事項:* 使用された後、または長期間保管されている場合は、できるだけ早く「ラストリゾート」KeyPackageをローテーションさせてください。全体として、「ラストリゾート」KeyPackageの再利用は可能な限り避けてください。
*Recommendation:* Ensure that the client for which a "last resort" KeyPackage has been used is updating leaf keys as early as possible.
*推奨事項:* 「ラストリゾート」KeyPackageが使用されたクライアントが、できるだけ早くリーフキーを更新していることを確認してください。
*Recommendation:* Ensure that clients delete the private component of their init_key after processing a Welcome message, or after the rotation of the "last resort" KeyPackage.
*推奨事項:* Welcomeメッセージを処理した後、または「ラストリゾート」KeyPackageのローテーション後に、クライアントがinit_keyのプライベートコンポーネントを削除することを確認してください。
Overall, it needs to be noted that key packages need to be updated when signature keys are changed.
全体として、署名キーが変更されたときにはKeyPackageを更新する必要があることに注意してください。
The main responsibility of the DS is to ensure delivery of messages. Some MLS messages need only be delivered to specific clients (e.g., a Welcome message initializing a new member's state), while others need to be delivered to all the members of a group. The DS may enable the latter delivery pattern via unicast channels (sometimes known as "client fanout"), broadcast channels ("server fanout"), or a mix of both.
DSの主な責任は、メッセージの配信を保証することです。一部のMLSメッセージは特定のクライアントにのみ配信する必要がありますが（例：新しいメンバーの状態を初期化するWelcomeメッセージ）、他のメッセージはグループのすべてのメンバーに配信する必要があります。DSは、ユニキャストチャネル（「クライアントファンアウト」と呼ばれることもある）、ブロードキャストチャネル（「サーバーファンアウト」）、または両方の組み合わせを介して、後者の配信パターンを可能にする場合があります。
For the most part, MLS does not require the DS to deliver messages in any particular order. Applications can set policies that control their tolerance for out-of-order messages (see Section 7), and messages that arrive significantly out of order can be dropped without otherwise affecting the protocol. There are two exceptions to this. First, Proposal messages should all arrive before the Commit that references them. Second, because an MLS group has a linear history of epochs, the members of the group must agree on the order in which changes are applied. Concretely, the group must agree on a single MLS Commit message that ends each epoch and begins the next one.
ほとんどの場合、MLSはDSが特定の順序でメッセージを配信することを要求しません。アプリケーションは、順序が乱れたメッセージに対する許容範囲を制御するポリシーを設定でき（セクション7を参照）、大幅に順序が乱れて到着したメッセージは、プロトコルに影響を与えることなく破棄できます。これには2つの例外があります。第一に、Proposalメッセージはすべて、それらを参照するCommitの前に到着する必要があります。第二に、MLSグループにはエポックの線形履歴があるため、グループのメンバーは変更が適用される順序に同意する必要があります。具体的には、グループは各エポックを終了し、次のエポックを開始する単一のMLS Commitメッセージに同意する必要があります。
In practice, there's a realistic risk of two members generating Commit messages at the same time, based on the same epoch, and both attempting to send them to the group at the same time. The extent to which this is a problem, and the appropriate solution, depend on the design of the DS. Per the CAP theorem [CAPBR], there are two general classes of distributed systems that the DS might fall into:
実際には、同じエポックに基づいて、2人のメンバーが同時にCommitメッセージを生成し、両方が同時にグループに送信しようとするという現実的なリスクがあります。これがどの程度問題になるか、そして適切な解決策は、DSの設計に依存します。CAP定理[CAPBR]によると、DSが該当する可能性のある分散システムには2つの一般的なクラスがあります。
* Consistent and Partition-tolerant, or Strongly Consistent, systems, which can provide a globally consistent view of data but have the inconvenience of clients needing to handle rejected messages.
* 一貫性があり分断耐性がある（Consistent and Partition-tolerant）、または強整合性（Strongly Consistent）システム。データのグローバルに一貫したビューを提供できますが、クライアントが拒否されたメッセージを処理する必要があるという不便さがあります。
* Available and Partition-tolerant, or Eventually Consistent, systems, which continue working despite network issues but may return different views of data to different users.
* 可用性があり分断耐性がある（Available and Partition-tolerant）、または結果整合性（Eventually Consistent）システム。ネットワークの問題にもかかわらず動作し続けますが、異なるユーザーに異なるデータのビューを返す可能性があります。
Strategies for sequencing messages in strongly and eventually consistent systems are described in the next two subsections. Most DSs will use the strongly consistent paradigm, but this remains a choice that can be handled in coordination with the client and advertised in the KeyPackages.
強整合性および結果整合性システムでメッセージを順序付けするための戦略については、次の2つのサブセクションで説明します。ほとんどのDSは強整合性パラダイムを使用しますが、これはクライアントと連携して処理され、KeyPackageで通知される選択肢のままです。
However, note that a malicious DS could also reorder messages or provide an inconsistent view to different users. The "generation" counter in MLS messages provides per-sender loss detection and ordering that cannot be manipulated by the DS, but this does not provide complete protection against partitioning. A DS can cause a partition in the group by partitioning key exchange messages; this can be detected only by out-of-band comparison (e.g., confirming that all clients have the same epoch_authenticator value). A mechanism for more robust protections is discussed in [EXTENSIONS].
ただし、悪意のあるDSは、メッセージを並べ替えたり、異なるユーザーに一貫性のないビューを提供したりする可能性があることに注意してください。MLSメッセージの「generation（世代）」カウンターは、DSによって操作できない送信者ごとの損失検出と順序付けを提供しますが、これは分断に対する完全な保護を提供するものではありません。DSは、鍵交換メッセージを分断することでグループ内に分断を引き起こす可能性があります。これは、帯域外の比較（たとえば、すべてのクライアントが同じepoch_authenticator値を持っていることを確認するなど）によってのみ検出できます。より堅牢な保護のためのメカニズムについては、[EXTENSIONS]で説明されています。
Other forms of DS misbehavior are still possible that are not easy to detect. For instance, a DS can simply refuse to relay messages to and from a given client. Without some sort of side information, other clients cannot generally detect this form of Denial-of-Service (DoS) attack.
検出が容易ではない他の形態のDSの不正行為も依然として可能です。たとえば、DSは特定のクライアントとの間でのメッセージの中継を単に拒否することができます。ある種のサイド情報がなければ、他のクライアントは一般に、この形式のサービス拒否（DoS）攻撃を検出することはできません。
With this approach, the DS ensures that some types of incoming messages have a linear order and all members agree on that order. The Delivery Service is trusted to break ties when two members send a Commit message at the same time.
このアプローチでは、DSは、ある種の着信メッセージが線形順序を持ち、すべてのメンバーがその順序に同意することを保証します。配信サービスは、2人のメンバーが同時にCommitメッセージを送信したときに競合を解決する（break ties）と信頼されています。
As an example, there could be an "ordering server" DS that broadcasts all messages received to all users and ensures that all clients see messages in the same order. This would allow clients to only apply the first valid Commit for an epoch and ignore subsequent Commits. Clients that send a Commit would then wait to apply it until it is broadcast back to them by the Delivery Service, assuming that they do not receive another Commit first.
例として、受信したすべてのメッセージをすべてのユーザーにブロードキャストし、すべてのクライアントが同じ順序でメッセージを見ることを保証する「順序付けサーバー」DSが考えられます。これにより、クライアントはエポックに対する最初の有効なCommitのみを適用し、後続のCommitを無視することができます。Commitを送信するクライアントは、最初に別のCommitを受信しないと仮定して、配信サービスによってブロードキャストされるまでその適用を待ちます。
Alternatively, the DS can rely on the epoch and content_type fields of an MLSMessage to provide an order only to handshake messages, and possibly even filter or reject redundant Commit messages proactively to prevent them from being broadcast. There is some risk associated with filtering; this is discussed further in Section 5.3.
あるいは、DSはMLSMessageのエポックおよびcontent_typeフィールドに依存して、ハンドシェイクメッセージのみに順序を提供し、おそらく冗長なCommitメッセージを積極的にフィルタリングまたは拒否して、それらがブロードキャストされるのを防ぐこともできます。フィルタリングにはいくつかのリスクが伴います。これについては、セクション5.3でさらに説明します。
With this approach, the DS is built in a way that may be significantly more available or performant than a strongly consistent system, but where it offers weaker consistency guarantees. Messages may arrive to different clients in different orders and with varying amounts of latency, which means clients are responsible for reconciliation.
このアプローチでは、DSは強整合性システムよりも大幅に可用性が高いか、パフォーマンスが高い方法で構築されていますが、一貫性の保証は弱くなります。メッセージは、異なるクライアントに異なる順序で、さまざまな遅延量で到着する可能性があり、これはクライアントが調整（reconciliation）に責任を負うことを意味します。
This type of DS might arise, for example, when group members are sending each message to each other member individually or when a distributed peer-to-peer network is used to broadcast messages.
このタイプのDSは、たとえば、グループメンバーが各メッセージを他の各メンバーに個別に送信している場合や、分散ピアツーピアネットワークを使用してメッセージをブロードキャストする場合に発生する可能性があります。
Upon receiving a Commit from the DS, clients can either:
DSからCommitを受信すると、クライアントは次のいずれかを行うことができます。
1. Pause sending new messages for a short amount of time to account for a reasonable degree of network latency and see if any other Commits are received for the same epoch. If multiple Commits are received, the clients can use a deterministic tie-breaking policy to decide which to accept, and then resume sending messages as normal.
1. 合理的な程度のネットワーク遅延を考慮して、新しいメッセージの送信を短時間一時停止し、同じエポックに対して他のCommitが受信されるかどうかを確認します。複数のCommitを受信した場合、クライアントは決定論的なタイブレークポリシーを使用してどちらを受け入れるかを決定し、その後通常どおりメッセージの送信を再開できます。
2. Accept the Commit immediately but keep a copy of the previous group state for a short period of time. If another Commit for a past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one. Note that any copies of previous or forked group states must be deleted within a reasonable amount of time to ensure that the protocol provides forward secrecy.
2. Commitを即座に受け入れますが、以前のグループ状態のコピーを短期間保持します。過去のエポックに対する別のCommitを受信した場合、クライアントは決定論的なタイブレークポリシーを使用して、最初に受け入れたCommitの使用を継続するか、元に戻して後のCommitを使用するかを決定します。プロトコルが前方秘匿性を提供することを保証するために、以前のグループ状態またはフォークされたグループ状態のコピーは、合理的な時間内に削除する必要があることに注意してください。
If the Commit references an unknown proposal, group members may need to solicit the DS or other group members individually for the contents of the proposal.
Commitが未知の提案を参照している場合、グループメンバーは提案の内容についてDSまたは他のグループメンバーに個別に問い合わせる必要がある場合があります。
Whenever a commit adds new members to a group, MLS requires the committer to send a Welcome message to the new members. Applications should ensure that Welcome messages are coupled with the tie-breaking logic for commits (see Sections 5.2.1 and 5.2.2). That is, when multiple commits are sent for the same epoch, applications need to ensure that only Welcome messages corresponding to the commit that "succeeded" are processed by new members.
Commitが新しいメンバーをグループに追加するたびに、MLSはコミッターに新しいメンバーへWelcomeメッセージを送信することを要求します。アプリケーションは、WelcomeメッセージがCommitのタイブレイクロジックと結合されていることを確認する必要があります（セクション5.2.1および5.2.2を参照）。つまり、同じエポックに対して複数のCommitが送信された場合、アプリケーションは、「成功した」Commitに対応するWelcomeメッセージのみが新しいメンバーによって処理されるようにする必要があります。
This is particularly important when groups are being reinitialized. When a group is reinitialized, it is restarted with a different protocol version and/or cipher suite but identical membership. Whenever an authorized member sends and commits a ReInit proposal, this immediately freezes the existing group and triggers the creation of a new group with a new group_id.
これは、グループが再初期化されている場合に特に重要です。グループが再初期化されると、異なるプロトコルバージョンや暗号スイートを使用して、同一のメンバーシップで再起動されます。許可されたメンバーがReInit提案を送信してコミットすると、既存のグループは即座に凍結され、新しいgroup_idを持つ新しいグループの作成がトリガーされます。
Ideally, the new group would be created by the same member that committed the ReInit proposal (including sending Welcome messages for the new group to all of the previous group's members). However, this operation is not always atomic, so it's possible for a member to go offline after committing a ReInit proposal but before creating the new group. If this happens, it's necessary for another member to continue the reinitialization by creating the new group and sending out Welcome messages.
理想的には、新しいグループは、ReInit提案をコミットしたのと同じメンバーによって作成されます（以前のグループのすべてのメンバーに新しいグループのWelcomeメッセージを送信することを含む）。ただし、この操作は常にアトミックではないため、ReInit提案をコミットした後、新しいグループを作成する前にメンバーがオフラインになる可能性があります。これが発生した場合、別のメンバーが新しいグループを作成し、Welcomeメッセージを送信することで再初期化を継続する必要があります。
This has the potential to create a race condition, where multiple members try to continue the reinitialization at the same time, and members receive multiple Welcome messages for each attempt at reinitializing the same group. Ensuring that all members agree on which reinitialization attempt is "correct" is key to prevent this from causing forks.
これには、複数のメンバーが同時に再初期化を継続しようとする競合状態（レースコンディション）を引き起こす可能性があり、メンバーは同じグループを再初期化する試みごとに複数のWelcomeメッセージを受け取ることになります。どの再初期化の試みが「正しい」かについてすべてのメンバーが同意することを保証することが、これがフォークを引き起こすのを防ぐための鍵です。
Situations can arise where a malicious or buggy client sends a Commit that is not accepted by all members of the group, and the DS is not able to detect this and reject the Commit. For example, a buggy client might send an encrypted Commit with an invalid set of proposals, or a malicious client might send a malformed Commit of the form described in Section 16.12 of [RFC9420].
悪意のあるクライアントやバグのあるクライアントが、グループのすべてのメンバーに受け入れられないCommitを送信し、DSがこれを検出して拒否できない状況が発生する可能性があります。たとえば、バグのあるクライアントが無効な一連の提案を含む暗号化されたCommitを送信したり、悪意のあるクライアントが[RFC9420]のセクション16.12で説明されている形式の不正なCommitを送信したりする場合があります。
In situations where the DS is attempting to filter redundant Commits, the DS might update its internal state under the assumption that a Commit has succeeded and thus end up in a state inconsistent with the members of the group. For example, the DS might think that the current epoch is now n+1 and reject any commits from other epochs, while the members think the epoch is n, and as a result, the group is stuck -- no member can send a Commit that the DS will accept.
DSが冗長なCommitをフィルタリングしようとしている状況では、DSはCommitが成功したという仮定の下で内部状態を更新し、その結果、グループのメンバーと矛盾する状態になる可能性があります。たとえば、DSは現在のエポックがn+1になったと考え、他のエポックからのCommitを拒否するかもしれませんが、メンバーはエポックがnであると考えており、その結果、グループは膠着状態に陥ります（どのメンバーもDSが受け入れるCommitを送信できません）。
Such "desynchronization" problems can arise even when the DS takes no stance on which Commit is "correct" for an epoch. The DS can enable clients to choose between Commits, for example by providing Commits in the order received and allowing clients to reject any Commits that violate their view of the group's policies. As such, all honest and correctly implemented clients will arrive at the same "first valid Commit" and choose to process it. Malicious or buggy clients that process a different Commit will end up in a forked view of the group.
このような「非同期」の問題は、DSがエポックに対してどのCommitが「正しい」かという姿勢を取らない場合でも発生する可能性があります。DSは、たとえば、受信した順序でCommitを提供し、クライアントがグループのポリシーの見解に違反するCommitを拒否できるようにすることで、クライアントがCommitを選択できるようにすることができます。そのため、正直で正しく実装されたすべてのクライアントは、同じ「最初の有効なCommit」に到達し、それを処理することを選択します。異なるCommitを処理する悪意のあるクライアントやバグのあるクライアントは、グループのフォークされたビューを持つことになります。
When these desynchronizations happen, the application may choose to take action to restore the functionality of the group. These actions themselves can have security implications. For example, a client developer might have a client automatically rejoin a group, using an external join, when it processes an invalid Commit. In this operation, however, the client trusts that the GroupInfo provided by the DS faithfully represents the state of the group, and not, say, an earlier state containing a compromised leaf node. In addition, the DS may be able to trigger this condition by deliberately sending the victim an invalid Commit. In certain scenarios, this trust can enable the DS or a malicious insider to undermine the post-compromise security guarantees provided by MLS.
これらの非同期化が発生した場合、アプリケーションはグループの機能を復元するためのアクションを実行することを選択できます。これらのアクション自体は、セキュリティに影響を与える可能性があります。たとえば、クライアント開発者は、クライアントが無効なCommitを処理するときに外部結合（external join）を使用してグループに自動的に再参加するようにするかもしれません。ただし、この操作では、クライアントは、DSによって提供されたGroupInfoがグループの状態を忠実に表していることを信頼しており、たとえば、侵害されたリーフノードを含む以前の状態ではないと信じています。さらに、DSは、被害者に無効なCommitを故意に送ることにより、この状態をトリガーできる場合があります。特定のシナリオでは、この信頼により、DSまたは悪意のある内部者がMLSが提供する侵害後のセキュリティ（PCS）保証を損なうことができます。
Actions to recover from desynchronization can also have availability and DoS implications. For example, if a recovery mechanism relies on external joins, a malicious member that deliberately posts an invalid Commit could also post a corrupted GroupInfo object in order to prevent victims from rejoining the group. Thus, careful analysis of security implications should be made for any system for recovering from desynchronization.
非同期から回復するためのアクションは、可用性とDoSの影響も持つ可能性があります。たとえば、回復メカニズムが外部結合に依存している場合、無効なCommitを意図的に投稿する悪意のあるメンバーは、被害者がグループに再参加するのを防ぐために、破損したGroupInfoオブジェクトを投稿することもできます。したがって、非同期から回復するためのシステムについては、セキュリティへの影響を慎重に分析する必要があります。
MLS is designed as a large-scale group messaging protocol and hence aims to provide both performance and security (e.g., integrity and confidentiality) to its users. Messaging systems that implement MLS provide support for conversations involving two or more members, and aim to scale to groups with tens of thousands of members, typically including many users using multiple devices.
MLSは、大規模なグループメッセージングプロトコルとして設計されているため、ユーザーにパフォーマンスとセキュリティ（整合性と機密性など）の両方を提供することを目的としています。MLSを実装するメッセージングシステムは、2人以上のメンバーが関与する会話のサポートを提供し、通常、複数のデバイスを使用して多くのユーザーを含む数万人のメンバーとグループに拡大することを目指しています。
MLS aims to provide agreement on group membership, meaning that all group members have agreed on the list of current group members.
MLSは、グループメンバーシップに関する合意を提供することを目指しています。つまり、すべてのグループメンバーが現在のグループメンバーのリストに同意していることを意味します。
Some applications may wish to enforce Access Control Lists (ACLs) to limit addition or removal of group members to privileged clients or users. Others may wish to require authorization from the current group members or a subset thereof. Such policies can be implemented at the application layer, on top of MLS. Regardless, MLS does not allow for or support addition or removal of group members without informing all other members.
一部のアプリケーションでは、アクセス制御リスト（ACL）を強制して、グループメンバーの追加または削除を特権クライアントまたはユーザーに制限したいと考える場合があります。他のアプリケーションでは、現在のグループメンバーまたはそのサブセットからの承認を要求したいと考える場合があります。このようなポリシーは、MLSの上のアプリケーション層で実装できます。いずれにせよ、MLSは、他のすべてのメンバーに通知することなくグループメンバーを追加または削除することを許可またはサポートしていません。
Membership of an MLS group is managed at the level of individual clients. In most cases, a client corresponds to a specific device used by a user. If a user has multiple devices, the user will generally be represented in a group by multiple clients (although applications could choose to have devices share keying material). If an application wishes to implement operations at the level of users, it is up to the application to track which clients belong to a given user and ensure that they are added/removed consistently.
MLSグループのメンバーシップは、個々のクライアントのレベルで管理されます。ほとんどの場合、クライアントはユーザーが使用する特定のデバイスに対応します。ユーザーが複数のデバイスを持っている場合、ユーザーは通常、複数のクライアントによってグループで表現されます（ただし、アプリケーションはデバイスに鍵マテリアルを共有させることを選択できます）。アプリケーションがユーザーのレベルで操作を実装したい場合、特定のユーザーに属するクライアントを追跡し、それらが一貫して追加/削除されることを確認するのはアプリケーション次第です。
MLS provides two mechanisms for changing the membership of a group. The primary mechanism is for an authorized member of the group to send a Commit that adds or removes other members. A secondary mechanism is an "external join": A member of the group publishes certain information about the group, which a new member can use to construct an "external" Commit message that adds the new member to the group. (There is no similarly unilateral way for a member to leave the group; they must be removed by a remaining member.)
MLSは、グループのメンバーシップを変更するための2つのメカニズムを提供します。主なメカニズムは、グループの許可されたメンバーが他のメンバーを追加または削除するCommitを送信することです。二次的なメカニズムは「外部結合（external join）」です。グループのメンバーは、グループに関する特定の情報を公開します。新しいメンバーは、これを使用して、新しいメンバーをグループに追加する「外部」Commitメッセージを作成できます。（メンバーがグループを脱退するための同様に一方的な方法はありません。彼らは残りのメンバーによって削除されなければなりません。）
With both mechanisms, changes to the membership are initiated from inside the group. When members perform changes directly, this is clearly the case. External joins are authorized indirectly, in the sense that a member publishing a GroupInfo object authorizes anyone to join who has access to the GroupInfo object, subject to whatever access control policies the application applies for external joins.
両方のメカニズムにおいて、メンバーシップの変更はグループ内から開始されます。メンバーが直接変更を実行する場合、これは明らかに当てはまります。外部結合は、GroupInfoオブジェクトを公開するメンバーが、アプリケーションが外部結合に適用するアクセス制御ポリシーに従って、GroupInfoオブジェクトにアクセスできる人なら誰でも参加することを許可するという意味で、間接的に承認されます。
Both types of joins are done via a Commit message, which could be blocked by the DS or rejected by clients if the join is not authorized. The former approach requires that Commits be visible to the DS; the latter approach requires that clients all share a consistent policy. In the unfortunate event that an unauthorized member is able to join, MLS enables any member to remove them.
両方のタイプの結合は、Commitメッセージを介して行われます。このメッセージは、結合が許可されていない場合、DSによってブロックされるか、クライアントによって拒否される可能性があります。前者のアプローチでは、CommitがDSに見えることが必要です。後者のアプローチでは、すべてのクライアントが一貫したポリシーを共有する必要があります。不正なメンバーが参加できてしまった場合でも、MLSはいずれかのメンバーがそのメンバーを削除できるようにします。
Application setup may also determine other criteria for membership validity. For example, per-device signature keys can be signed by an identity key recognized by other participants. If a certificate chain is used to authenticate device signature keys, then revocation by the owner adds an alternative mechanism to prompt membership removal.
アプリケーションのセットアップによって、メンバーシップの有効性に関する他の基準が決定される場合もあります。たとえば、デバイスごとの署名キーは、他の参加者によって認識されたIDキーによって署名できます。証明書チェーンを使用してデバイスの署名キーを認証する場合、所有者による失効は、メンバーシップの削除を促すための代替メカニズムを追加します。
An MLS group's secrets change on every change of membership, so each client only has access to the secrets used by the group while they are a member. Messages sent before a client joins or after they are removed are protected with keys that are not accessible to the client. Compromise of a member removed from a group does not affect the security of messages sent after their removal. Messages sent during the client's membership are also secure as long as the client has properly implemented the MLS deletion schedule, which calls for the secrets used to encrypt or decrypt a message to be deleted after use, along with any secrets that could be used to derive them.
MLSグループの秘密は、メンバーシップの変更ごとに変更されるため、各クライアントはメンバーである間にグループが使用する秘密にのみアクセスできます。クライアントが参加する前または削除後に送信されるメッセージは、クライアントがアクセスできないキーで保護されています。グループから削除されたメンバーの侵害は、削除後に送信されたメッセージのセキュリティに影響しません。クライアントのメンバーシップ中に送信されたメッセージも、クライアントがMLS削除スケジュールを適切に実装している限り安全です。このスケジュールでは、メッセージの暗号化または復号化に使用された秘密と、それらを導出するために使用できる秘密を、使用後に削除することが求められます。
Any user or client may have membership in several groups simultaneously. The set of members of any group may or may not overlap with the members of another group. MLS guarantees that the FS and PCS goals within a given group are maintained and not weakened by user membership in multiple groups. However, actions in other groups likewise do not strengthen the FS and PCS guarantees within a given group, e.g., key updates within a given group following a device compromise do not provide PCS healing in other groups; each group must be updated separately to achieve these security objectives. This also applies to future groups that a member has yet to join, which are likewise unaffected by updates performed in current groups.
ユーザーまたはクライアントは、複数のグループに同時にメンバーシップを持つことができます。あるグループのメンバーのセットは、別のグループのメンバーと重複する場合と重複しない場合があります。MLSは、特定のグループ内のFSおよびPCSの目標が維持され、複数のグループへのユーザーメンバーシップによって弱体化されないことを保証します。ただし、同様に、他のグループでのアクションは、特定のグループ内のFSおよびPCS保証を強化しません。たとえば、デバイスの侵害に続く特定のグループ内でのキー更新は、他のグループでのPCS治癒（healing）を提供しません。これらのセキュリティ目標を達成するには、各グループを個別に更新する必要があります。これは、メンバーがまだ参加していない将来のグループにも適用され、同様に現在のグループで実行される更新の影響を受けません。
Applications can strengthen connectivity among parallel groups by requiring periodic key updates from a user across all groups in which they have membership.
アプリケーションは、メンバーシップを持つすべてのグループにわたってユーザーからの定期的なキー更新を要求することにより、並列グループ間の接続を強化できます。
MLS provides a pre-shared key (PSK) mechanism that can be used to link healing properties among parallel groups. For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B. The key update provides PCS with regard to M in group A. If a PSK is exported from group A and injected into group B, then some of these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.
MLSは、並列グループ間で治癒（healing）特性をリンクするために使用できる、事前共有鍵（PSK）メカニズムを提供します。たとえば、2つのグループAとBの共通メンバーMが、グループAではキー更新を実行したが、グループBでは実行していないとします。キー更新は、グループAにおけるMに関してPCSを提供します。PSKがグループAからエクスポートされ、グループBに注入された場合、これらのPCSプロパティの一部はグループBに引き継がれます。なぜなら、PSKとそれから派生した秘密は、Mの新しい更新されたバージョンのみが知っており、侵害された可能性のある古いバージョンのMは知らないからです。
No operation in MLS requires two distinct clients or members to be online simultaneously. In particular, members participating in conversations protected using MLS can update the group's keys, add or remove new members, and send messages without waiting for another user's reply.
MLSでの操作では、2つの異なるクライアントまたはメンバーが同時にオンラインである必要はありません。特に、MLSを使用して保護されている会話に参加するメンバーは、グループのキーを更新したり、新しいメンバーを追加または削除したり、別のユーザーの返信を待たずにメッセージを送信したりできます。
Messaging systems that implement MLS have to provide a transport layer for delivering messages asynchronously and reliably.
MLSを実装するメッセージングシステムは、メッセージを非同期的かつ確実に配信するための輸送層を提供する必要があります。
Because all clients within a group (members) have access to the shared cryptographic material, the MLS protocol allows each member of the messaging group to perform operations. However, every service/ infrastructure has control over policies applied to its own clients. Applications managing MLS clients can be configured to allow for specific group operations. On the one hand, an application could decide that a group administrator will be the only member to perform Add and Remove operations. On the other hand, in many settings such as open discussion forums, joining can be allowed for anyone.
グループ内のすべてのクライアント（メンバー）は共有暗号化マテリアルにアクセスできるため、MLSプロトコルにより、メッセージンググループの各メンバーが操作を実行できます。ただし、すべてのサービス/インフラストラクチャは、自社のクライアントに適用されるポリシーを管理しています。MLSクライアントを管理するアプリケーションは、特定のグループ操作を許可するように構成できます。一方で、アプリケーションは、グループ管理者がAddおよびRemove操作を実行する唯一のメンバーになることを決定できます。他方で、オープンディスカッションフォーラムなどの多くの設定では、誰でも参加できるようにすることができます。
While MLS application messages are always encrypted, MLS handshake messages can be sent either encrypted (in an MLS PrivateMessage) or unencrypted (in an MLS PublicMessage). Applications may be designed such that intermediaries need to see handshake messages, for example to enforce policy on which commits are allowed, or to provide MLS ratchet tree data in a central location. If handshake messages are unencrypted, it is especially important that they be sent over a channel with strong transport encryption (see Section 8) in order to prevent external attackers from monitoring the status of the group. Applications that use unencrypted handshake messages may take additional steps to reduce the amount of metadata that is exposed to the intermediary. Everything else being equal, using encrypted handshake messages provides stronger privacy properties than using unencrypted handshake messages, as it prevents intermediaries from learning about the structure of the group.
MLSアプリケーションメッセージは常に暗号化されますが、MLSハンドシェイクメッセージは暗号化して（MLS PrivateMessageで）、または暗号化せずに（MLS PublicMessageで）送信できます。アプリケーションは、たとえばどのコミットが許可されるかというポリシーを強制するため、あるいは中央の場所でMLSラチェットツリーデータを提供するために、仲介者がハンドシェイクメッセージを見る必要があるように設計される場合があります。ハンドシェイクメッセージが暗号化されていない場合、外部の攻撃者がグループの状態を監視するのを防ぐために、強力なトランスポート暗号化を備えたチャネル上で送信されることが特に重要です（セクション8を参照）。暗号化されていないハンドシェイクメッセージを使用するアプリケーションは、仲介者にさらされるメタデータの量を減らすために追加の措置を講じることができます。他の条件が同じであれば、暗号化されたハンドシェイクメッセージを使用すると、仲介者がグループの構造について知ることを防ぐため、暗号化されていないハンドシェイクメッセージを使用するよりも強力なプライバシー特性が得られます。
If handshake messages are encrypted, any access control policies must be applied at the client, so the application must ensure that the access control policies are consistent across all clients to make sure that they remain in sync. If two different policies were applied, the clients might not accept or reject a group operation and end up in different cryptographic states, breaking their ability to communicate.
ハンドシェイクメッセージが暗号化されている場合、アクセス制御ポリシーをクライアントで適用する必要があるため、アプリケーションはすべてのクライアントにわたってアクセス制御ポリシーが一貫していることを確認し、同期が保たれるようにする必要があります。2つの異なるポリシーが適用された場合、クライアントはグループ操作を受け入れたり拒否したりせず、異なる暗号学的状態に陥り、通信できなくなる可能性があります。
*Recommendation:* Avoid using inconsistent access control policies, especially when using encrypted group operations.
*推奨：*特に暗号化されたグループ操作を使用する場合は、一貫性のないアクセス制御ポリシーを使用しないでください。
MLS allows actors outside the group to influence the group in two ways: External signers can submit proposals for changes to the group, and new joiners can use an external join to add themselves to the group. The external_senders extension ensures that all members agree on which signers are allowed to send proposals, but any other policies must be assured to be consistent, as noted above.
MLSを使用すると、グループ外のアクターは2つの方法でグループに影響を与えることができます。外部署名者はグループの変更の提案を提出することができ、新しい参加者は外部結合を使用してグループに追加できます。external_senders拡張は、すべてのメンバーがどの署名者が提案を送信することを許可されているかに同意することを保証しますが、上記のように、他のポリシーは一貫していることを保証する必要があります。
*Recommendation:* Have an explicit group policy setting the conditions under which external joins are allowed.
*推奨事項:* 外部結合が許可される条件を設定する明示的なグループポリシーを持ってください。
Within an MLS group, every member is authenticated to every other member by means of credentials issued and verified by the AS. MLS does not prescribe what actions, if any, an application should take in the event that a group member presents an invalid credential. For example, an application may require such a member to be immediately evicted or may allow some grace period for the problem to be remediated. To avoid operational problems, it is important for all clients in a group to have a consistent view of which credentials in a group are valid, and how to respond to invalid credentials.
MLSグループ内では、すべてのメンバーは、ASによって発行および検証された資格情報によって他のすべてのメンバーに対して認証されます。MLSは、グループメンバーが無効な資格情報を提示した場合にアプリケーションがどのようなアクションを取るべきか（もしあれば）を規定していません。たとえば、アプリケーションは、そのようなメンバーを即座に追放することを要求する場合もあれば、問題が修正されるまでの猶予期間を認める場合もあります。運用上の問題を回避するために、グループ内のすべてのクライアントが、グループ内のどの資格情報が有効であるか、および無効な資格情報にどのように対応するかについて一貫した見解を持つことが重要です。
*Recommendation:* Have a uniform credential validation process to ensure that all group members evaluate other members' credentials in the same way.
*推奨事項:* すべてのグループメンバーが同じ方法で他のメンバーの資格情報を評価できるように、統一された資格情報検証プロセスを持ってください。
*Recommendation:* Have a uniform policy for how invalid credentials are handled.
*推奨事項:* 無効な資格情報がどのように処理されるかについての統一されたポリシーを持ってください。
In some authentication systems, it is possible for a previously valid credential to become invalid over time. For example, in a system based on X.509 certificates, credentials can expire or be revoked. The MLS update mechanisms allow a client to replace an old credential with a new one. This is best done before the old credential becomes invalid.
一部の認証システムでは、以前に有効な資格情報が時間とともに無効になる可能性があります。たとえば、X.509証明書に基づくシステムでは、資格情報が期限切れになったり、取り消されたりする可能性があります。MLS更新メカニズムにより、クライアントは古い資格情報を新しい資格情報に置き換えることができます。これは、古い資格情報が無効になる前に行うのが最適です。
*Recommendation:* Proactively rotate credentials, especially if a credential is about to become invalid.
*推奨事項:* 特に資格情報が無効になりそうな場合は、資格情報を積極的にローテーションさせてください。
Group members whose local MLS state is lost or corrupted can reinitialize their state by rejoining the group as a new member and removing the member representing their earlier state. An application can require that a client performing such a reinitialization prove its prior membership with a PSK that was exported from the previous state.
ローカルのMLS状態が失われたり破損したりしたグループメンバーは、新しいメンバーとしてグループに再参加し、以前の状態を表すメンバーを削除することで、状態を再初期化できます。アプリケーションは、このような再初期化を実行するクライアントに対し、以前の状態からエクスポートされたPSKを使用して以前のメンバーシップを証明するよう要求できます。
There are a few practical challenges to this approach. For example, the application will need to ensure that all members have the required PSK, including any new members that have joined the group since the epoch in which the PSK was issued. And of course, if the PSK is lost or corrupted along with the member's other state, then it cannot be used to recover.
このアプローチにはいくつかの実際的な課題があります。たとえば、アプリケーションは、PSKが発行されたエポック以降にグループに参加した新しいメンバーを含む、すべてのメンバーが必要なPSKを持っていることを確認する必要があります。そしてもちろん、PSKがメンバーの他の状態とともに紛失または破損している場合、回復に使用することはできません。
Reinitializing in this way does not provide the member with access to group messages exchanged during the state loss window, but enables proof of prior membership in the group. Applications may choose various configurations for providing lost messages to valid group members that are able to prove prior membership.
この方法での再初期化は、状態喪失期間中に交換されたグループメッセージへのアクセスをメンバーに提供しませんが、グループの以前のメンバーシップの証明を可能にします。アプリケーションは、以前のメンバーシップを証明できる有効なグループメンバーに失われたメッセージを提供するためのさまざまな構成を選択する場合があります。
It is common for users within a group to own multiple devices. A new device can be added to a group and be considered as a new client by the protocol. This client will not gain access to the history even if it is owned by someone who owns another member of the group. MLS does not provide direct support for restoring history in this case, but applications can elect to provide such a mechanism outside of MLS. Such mechanisms, if used, may reduce the FS and PCS guarantees provided by MLS.
グループ内のユーザーが複数のデバイスを所有することは一般的です。新しいデバイスをグループに追加し、プロトコルによって新しいクライアントと見なすことができます。このクライアントは、グループの別のメンバーを所有している人が所有している場合でも、履歴にアクセスできません。MLSは、この場合に履歴を回復するための直接的なサポートを提供していませんが、アプリケーションはMLS以外のこのようなメカニズムを提供することを選択できます。このようなメカニズムは、使用すると、MLSが提供するFSおよびPCSの保証を減らす場合があります。
The MLS protocol provides several extension points where additional information can be provided. Extensions to KeyPackages allow clients to disclose additional information about their capabilities. Groups can also have extension data associated with them, and the group agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.
MLSプロトコルは、追加情報を提供できるいくつかの拡張ポイントを提供します。KeyPackageへの拡張により、クライアントはその機能に関する追加情報を開示できます。グループには拡張データに関連付けられた拡張データも持つことができ、MLSのグループ合意プロパティは、グループのすべてのメンバーがこれらの拡張機能の内容に同意することを確認します。
Application messages carried by MLS are opaque to the protocol and can contain arbitrary data. Each application that uses MLS needs to define the format of its application_data and any mechanism necessary to determine the format of that content over the lifetime of an MLS group. In many applications, this means managing format migrations for groups with multiple members who may each be offline at unpredictable times.
MLSによって運ばれるアプリケーションメッセージは、プロトコルに対して不透明であり、任意のデータを含めることができます。MLSを使用する各アプリケーションは、MLSグループの存続期間にわたって、そのapplication_dataのフォーマットと、そのコンテンツのフォーマットを決定するために必要なメカニズムを定義する必要があります。多くのアプリケーションでは、これは、予測不可能なタイミングでそれぞれオフラインになる可能性のある複数のメンバーを持つグループのフォーマット移行を管理することを意味します。
*Recommendation:* Use the content mechanism defined in [EXTENSIONS], unless the specific application defines another mechanism that more appropriately addresses the same requirements for that application of MLS.
*推奨事項:* 特定のアプリケーションがMLSの適用に対してより適切に対処する別のメカニズムを定義しない限り、[EXTENSIONS]で定義されたコンテンツメカニズムを使用してください。
The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with.
アプリケーションメッセージのMLSフレーミングは、クライアントが認証されているが暗号化されていない情報を送信できるフィールドも提供します。このような情報は、メッセージを処理するサーバーで使用できますが、グループメンバーはそれが改ざんされていないことが保証されます。
The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can interoperate to form federated systems if they use compatible authentication mechanisms, cipher suites, application content, and infrastructure functionalities. Federation is described in more detail in [FEDERATION].
このプロトコルは、フェデレーション環境と互換性があることを目的としています。このドキュメントでは、フェデレーションに必要なすべてのメカニズムを指定していませんが、複数のMLS実装が相互運用して、互換性のある認証メカニズム、暗号スイート、アプリケーションコンテンツ、およびインフラストラクチャ機能を使用する場合、フェデレーションシステムを形成できます。フェデレーションについては、[FEDERATION]で詳しく説明しています。
It is important that multiple versions of MLS be able to coexist in the future. Thus, MLS offers a version negotiation mechanism; this mechanism prevents version downgrade attacks where an attacker would actively rewrite messages with a lower protocol version than the messages originally offered by the endpoints. When multiple versions of MLS are available, the negotiation protocol guarantees that the creator is able to select the best version out of those supported in common by the group.
MLSの複数のバージョンが将来共存できることが重要です。したがって、MLSはバージョンネゴシエーションメカニズムを提供します。このメカニズムは、攻撃者がエンドポイントが元々提供したメッセージよりも低いプロトコルバージョンでメッセージを積極的に書き換えるバージョンダウングレード攻撃を防ぎます。MLSの複数のバージョンが利用可能な場合、ネゴシエーションプロトコルは、作成者がグループによって共通にサポートされているものから最適なバージョンを選択できることを保証します。
In MLS 1.0, the creator of the group is responsible for selecting the best cipher suite supported across clients. Each client is able to verify availability of protocol version, cipher suites, and extensions at all times once it has at least received the first group operation message.
MLS 1.0では、グループの作成者は、クライアント全体でサポートされている最適な暗号スイートを選択する責任があります。各クライアントは、少なくとも最初のグループ操作メッセージを受信すれば、プロトコルバージョン、暗号スイート、および拡張機能の可用性を常に確認できます。
Each member of an MLS group advertises the protocol functionality they support. These capability advertisements can be updated over time, e.g., if client software is updated while the client is a member of a group. Thus, in addition to preventing downgrade attacks, the members of a group can also observe when it is safe to upgrade to a new cipher suite or protocol version.
MLSグループの各メンバーは、サポートするプロトコル機能を通知します。これらの機能通知は、クライアントがグループのメンバーである間にクライアントソフトウェアが更新された場合など、時間の経過とともに更新できます。したがって、ダウングレード攻撃を防ぐことに加えて、グループのメンバーは、新しい暗号スイートまたはプロトコルバージョンに安全にアップグレードできる時期を観察することもできます。
MLS is a security layer that needs to be integrated with an application. A fully functional deployment of MLS will have to make a number of decisions about how MLS is configured and operated. Deployments that wish to interoperate will need to make compatible decisions. This section lists all of the dependencies of an MLS deployment that are external to the protocol specification, but would still need to be aligned within a given MLS deployment, or for two deployments to potentially interoperate.
MLSは、アプリケーションと統合する必要があるセキュリティレイヤーです。MLSの完全に機能する展開は、MLSの構成と操作方法について多くの決定を下す必要があります。相互運用を希望する展開は、互換性のある決定を下す必要があります。このセクションには、プロトコル仕様の外部のMLS展開のすべての依存関係をリストしますが、特定のMLS展開内に整列する必要があります。
The protocol has a built-in ability to negotiate protocol versions, cipher suites, extensions, credential types, and additional proposal types. For two deployments to interoperate, they must have overlapping support in each of these categories. The required_capabilities extension (Section 7.2 of [RFC9420]) can promote interoperability with a wider set of clients by ensuring that certain functionality continues to be supported by a group, even if the clients in the group aren't currently relying on it.
プロトコルには、プロトコルバージョン、暗号スイート、拡張機能、資格情報タイプ、および追加の提案タイプをネゴシエートする組み込み機能があります。2つの展開が相互運用するためには、これらの各カテゴリでサポートが重複している必要があります。required_capabilities拡張機能（[RFC9420]のセクション7.2）は、グループ内のクライアントが現在依存していない場合でも、特定の機能がグループによって引き続きサポートされることを保証することにより、より幅広いクライアントとの相互運用性を促進できます。
MLS relies on the following network services, which need to be compatible in order for two different deployments based on them to interoperate.
MLSは、次のネットワークサービスに依存しています。これは、それらに基づいた2つの異なる展開を相互運用するために互換性がある必要があります。
* An *Authentication Service*, described fully in Section 4, defines the types of credentials which may be used in a deployment and provides methods for:
* セクション4で詳しく説明されている *認証サービス（Authentication Service）*は、展開で使用できる資格情報の種類を定義し、次の方法を提供します。
1. Issuing new credentials with a relevant credential lifetime,
1. 関連する資格情報の生涯で新しい資格情報を発行する、
2. Validating a credential against a reference identifier,
2. 参照識別子に対する資格情報の検証、
3. Validating whether or not two credentials represent the same client, and
3. 2つの資格情報が同じクライアントを表すかどうかを検証し、
4. Optionally revoking credentials which are no longer authorized.
4. オプションで、もはや許可されていない資格情報を取り消します。
* A *Delivery Service*, described fully in Section 5, provides methods for:
* セクション5で詳しく説明されている *配信サービス（Delivery Service）*は、次の方法を提供します。
1. Delivering messages for a group to all members in the group.
1. グループ内のすべてのメンバーにグループのメッセージを配信します。
2. Delivering Welcome messages to new members of a group.
2. グループの新しいメンバーにウェルカムメッセージを配信します。
3. Uploading new KeyPackages for a user's own clients.
3. ユーザー自身のクライアント向けの新しいキーパッケージをアップロードします。
4. Downloading KeyPackages for specific clients. Typically, KeyPackages are used once and consumed.
4. 特定のクライアント向けのキーパッケージのダウンロード。通常、キーパッケージは一度使用され、消費されます。
* Additional services may or may not be required, depending on the application design:
* アプリケーションの設計に応じて、追加のサービスが必要になる場合とそうでない場合があります。
- In cases where group operations are not encrypted, the DS has the ability to observe and maintain a copy of the public group state. In particular, this is useful for either (1) clients that do not have the ability to send the full public state in a Welcome message when inviting a user or (2) clients that need to recover from losing their state. Such public state can contain privacy-sensitive information such as group members' credentials and related public keys; hence, services need to carefully evaluate the privacy impact of storing this data on the DS.
- グループ操作が暗号化されていない場合、DSは公開グループ状態のコピーを観察および維持する能力を持っています。特に、これは（1）ユーザーを招待するときにWelcomeメッセージで完全な公開状態を送信する能力がないクライアント、または（2）状態の喪失から回復する必要があるクライアントにとって有用です。このような公開状態には、グループメンバーの資格情報や関連する公開鍵などのプライバシーに敏感な情報が含まれている可能性があります。したがって、サービスはこのデータをDSに保存することによるプライバシーへの影響を慎重に評価する必要があります。
- If external joiners are allowed, there must be a method for publishing a serialized GroupInfo object (with an external_pub extension) that corresponds to a specific group and epoch, and for keeping that object in sync with the state of the group.
- 外部ジョイナーが許可されている場合、特定のグループとエポックに対応するシリアル化GroupInfoオブジェクト（external_pub拡張機能を使用）を公開し、そのオブジェクトをグループの状態と同期させる方法が必要です。
- If an application chooses not to allow external joining, it may instead provide a method for external users to solicit group members (or a designated service) to add them to a group.
- アプリケーションが外部参加を許可しないことを選択した場合、代わりに外部ユーザーがグループメンバー（または指定されたサービス）にグループへの追加を依頼する方法を提供する場合があります。
- If the application uses PSKs that members of a group may not have access to (e.g., to control entry into the group or to prove membership in the group in the past, as discussed in Section 6.6), there must be a method for distributing these PSKs to group members who might not have them -- for instance, if they joined the group after the PSK was generated.
- アプリケーションが、グループのメンバーがアクセスできない可能性のあるPSKを使用する場合（たとえば、セクション6.6で説明したように、グループへの参加を制御したり、過去のグループメンバーシップを証明したりするため）、これらのPSKを持っていない可能性のあるグループメンバー（たとえば、PSKが生成された後にグループに参加した場合など）に配布する方法が必要です。
- If an application wishes to detect and possibly discipline members that send malformed commits with the intention of corrupting a group's state, there must be a method for reporting and validating malformed commits.
- アプリケーションが、グループの状態を破壊する意図で不正なコミットメントを送信するメンバーを検出し、おそらく懲戒したい場合、奇形のコミットを報告および検証する方法がなければなりません。
MLS requires the following parameters to be defined, which must be the same for two implementations to interoperate:
MLSでは、次のパラメーターを定義する必要があります。これは、2つの実装が相互運用するために同じでなければなりません。
* The maximum total lifetime that is acceptable for a KeyPackage.
* キーパッケージに受け入れられる最大総寿命。
* How long to store the resumption PSK for past epochs of a group.
* グループの過去のエポックの再開PSKを保存する期間。
* The degree of tolerance that's allowed for out-of-order message delivery:
* 順序が乱れたメッセージ配信に対して許容される耐性の程度：
- How long to keep unused nonce and key pairs for a sender.
- 送信者の未使用のノンセとキーペアを保持する期間。
- A maximum number of unused key pairs to keep.
- 保持する未使用キーペアの最大数。
- A maximum number of steps that clients will move a secret tree ratchet forward in response to a single message before rejecting it.
- クライアントが単一のメッセージに応じてシークレットツリーラチェットを前方に移動させる最大ステップ数（これを超えると拒否する）。
- Whether to buffer messages that aren't yet able to be understood due to other messages not arriving first, and, if so, how many and for how long -- for example, Commit messages that arrive before a proposal they reference or application messages that arrive before the Commit starting an epoch.
- 他のメッセージが最初に到着していないためにまだ理解できないメッセージをバッファリングするかどうか、そしてもしそうなら、どのくらいの期間、たとえば、エポックを開始する前に到着する提案またはアプリケーションメッセージの前に到着するメッセージをコミットするかどうか。
If implementations differ in these parameters, they will interoperate to some extent but may experience unexpected failures in certain situations, such as extensive message reordering.
実装がこれらのパラメータで異なる場合、ある程度は相互運用しますが、広範なメッセージの順序変更など、特定の状況で予期しない障害が発生する可能性があります。
MLS provides the following locations where an application may store arbitrary data. The format and intention of any data in these locations must align for two deployments to interoperate:
MLSは、アプリケーションが任意のデータを保存できる次の場所を提供します。これらの場所のデータの形式と意図は、2つの展開が相互運用するために整列する必要があります。
* Application data, sent as the payload of an encrypted message.
* 暗号化されたメッセージのペイロードとして送信されるアプリケーションデータ。
* Additional authenticated data, sent unencrypted in an otherwise encrypted message.
* 追加の認証されたデータは、暗号化されていないメッセージで暗号化されていないメッセージを送信しました。
* Group IDs, as decided by group creators and used to uniquely identify a group.
* グループ作成者によって決定され、グループを一意に識別するために使用されるグループID。
* Application-level identifiers of public key material (specifically, the application_id extension as defined in Section 5.3.3 of [RFC9420]).
* 公開キー資料のアプリケーションレベルの識別子（具体的には、[RFC9420]のセクション5.3.3で定義されているApplication_ID拡張機能）。
MLS requires the following policies to be defined, which restrict the set of acceptable behaviors in a group. These policies must be consistent between deployments for them to interoperate:
MLSでは、次のポリシーを定義する必要があります。これにより、グループ内の許容可能な動作のセットが制限されます。これらのポリシーは、彼らが相互運用するための展開間で一貫している必要があります。
* A policy on which cipher suites are acceptable.
* 暗号スイートが受け入れられるポリシー。
* A policy on any mandatory or forbidden MLS extensions.
* 必須または禁止されたMLS拡張機能に関するポリシー。
* A policy on when to send proposals and commits in plaintext instead of encrypted.
* 暗号化する代わりに、いつ提案とコミットを平文で送信するかについてのポリシー。
* A policy for which proposals are valid to have in a commit, including but not limited to:
* 提案がコミットで有効であるポリシーは、以下を含むがこれらに限定されません。
- When a member is allowed to add or remove other members of the group.
- メンバーがグループの他のメンバーを追加または削除することを許可される場合。
- When, and under what circumstances, a reinitialization proposal is allowed.
- いつ、どのような状況下で、再初期化の提案が許可されます。
- When proposals from external senders are allowed and how to authorize those proposals.
- 外部送信者からの提案が許可されている場合、およびそれらの提案を承認する方法。
- When external joiners are allowed and how to authorize those external commits.
- 外部ジョイナーが許可されている場合、およびそれらの外部コミットを承認する方法。
- Which other proposal types are allowed.
- 他の提案タイプは許可されています。
* A policy of when members should commit pending proposals in a group.
* メンバーがいつグループ内の保留中の提案をコミットすべきかというポリシー。
* A policy of how to protect and share the GroupInfo objects needed for external joins.
* 外部結合に必要なGroupInfoオブジェクトを保護および共有する方法のポリシー。
* A policy for when two credentials represent the same client, distinguishing the following two cases:
* 2つの資格情報が同じクライアントを表している場合のポリシー。次の2つのケースを区別します。
- When there are multiple devices for a given user.
- 特定のユーザーに複数のデバイスがある場合。
- When a single device has multiple signature keys -- for instance, if the device has keys corresponding to multiple overlapping time periods.
- 単一のデバイスに複数の署名キーがある場合 - たとえば、デバイスに複数の重複する期間に対応するキーがある場合。
* A policy on how long to allow a member to stay in a group without updating its leaf keys before removing them.
* メンバーがリーフキーを更新せずにグループに留まることを許可する期間（その後削除する）に関するポリシー。
Finally, there are some additional application-defined behaviors that are partially an individual application's decision but may overlap with interoperability:
最後に、個々のアプリケーションの決定であるが、相互運用性と重複する可能性のある追加のアプリケーション定義の動作があります。
* When and how to pad messages.
* いつ、どのようにメッセージにパディングを行うか。
* When to send a reinitialization proposal.
* 再生提案をいつ送信するか。
* How often clients should update their leaf keys.
* クライアントがリーフキーを更新すべき頻度。
* Whether to prefer sending full commits or partial/empty commits.
* 完全なコミットを送ることを好むか、部分的/空のコミットを送ることを好むか。
* Whether there should be a required_capabilities extension in groups.
* グループにrequired_capabilities拡張機能が必要かどうか。
MLS adopts the Internet threat model [RFC3552] and therefore assumes that the attacker has complete control of the network. It is intended to provide the security services described in Section 8.2 in the face of attackers who can:
MLSはインターネットの脅威モデル[RFC3552]を採用するため、攻撃者がネットワークを完全に制御していると想定しています。これは、セクション8.2で説明されているセキュリティサービスを攻撃者に直面して提供することを目的としています。
* Monitor the entire network.
* ネットワーク全体を監視します。
* Read unprotected messages.
* 保護されていないメッセージを読んでください。
* Generate, inject, and delete any message in the unprotected transport layer.
* 保護されていない輸送層でメッセージを生成、注入、削除します。
While MLS should be run over a secure transport such as QUIC [RFC9000] or TLS [RFC8446], the security guarantees of MLS do not depend on the transport. This departs from the usual design practice of trusting the transport because MLS is designed to provide security even in the face of compromised network elements, especially the DS.
MLSは、QUIC [RFC9000]やTLS [RFC8446]などのセキュアなトランスポート上で実行されるべきですが、MLSのセキュリティ保証はトランスポートに依存しません。これは、MLSが侵害されたネットワーク要素、特にDSに直面してもセキュリティを提供するように設計されているため、トランスポートを信頼するという通常の設計慣行から逸脱しています。
Generally, MLS is designed under the assumption that the transport layer is present to keep metadata private from network observers, while the MLS protocol provides confidentiality, integrity, and authentication guarantees for the application data (which could pass through multiple systems). Additional properties such as partial anonymity or deniability could also be achieved in specific architecture designs.
一般に、MLSは、メタデータをネットワークオブザーバーからプライベートに保つために輸送層が存在するという仮定の下で設計されていますが、MLSプロトコルはアプリケーションデータの機密性、整合性、および認証保証を提供します（複数のシステムを通過する可能性があります）。特定のアーキテクチャ設計では、部分的な匿名性や否定性などの追加のプロパティも実現できます。
In addition, these guarantees are intended to degrade gracefully in the presence of compromise of the transport security links as well as of both clients and elements of the messaging system, as described in the remainder of this section.
さらに、これらの保証は、このセクションの残りの部分で説明されているように、トランスポートセキュリティリンクの侵害、およびクライアントとメッセージングシステムの要素の両方の侵害が存在する場合でも、緩やかに低下（degrade gracefully）することを意図しています。
As discussed above, MLS provides the highest level of security when its messages are delivered over an encrypted transport, thus preventing attackers from selectively interfering with MLS communications as well as protecting the already limited amount of metadata. Very little information is contained in the unencrypted header of the MLS protocol message format for group operation messages, and application messages are always encrypted in MLS.
上記で説明したように、MLSは、暗号化されたトランスポートを介してメッセージが配信されると、最高レベルのセキュリティを提供するため、攻撃者がMLS通信を選択的に妨害することを防ぎ、すでに限られた量のメタデータを保護します。グループ操作メッセージのMLSプロトコルメッセージ形式の暗号化されていないヘッダーにはほとんど含まれておらず、アプリケーションメッセージは常にMLSで暗号化されます。
*Recommendation:* Use transports that provide reliability and metadata confidentiality whenever possible, e.g., by transmitting MLS messages over a protocol such as TLS [RFC8446] or QUIC [RFC9000].
*推奨事項:* 可能な限り信頼性とメタデータの機密性を提供するトランスポートを使用してください。たとえば、TLS [RFC8446]やQUIC [RFC9000]などのプロトコルを介してMLSメッセージを送信します。
MLS avoids the need to send the full list of recipients to the server for dispatching messages because that list could potentially contain tens of thousands of recipients. Header metadata in MLS messages typically consists of an opaque group_id, a numerical value to determine the epoch of the group (the number of changes that have been made to the group), and whether the message is an application message, a proposal, or a commit.
MLSは、そのリストに何万人もの受信者が含まれる可能性があるため、メッセージをディスパッチするために受信者の完全なリストをサーバーに送信する必要性を回避します。MLSメッセージのヘッダーメタデータは、通常、不透明なGroup_id、グループのエポック（グループに加えられた変更の数）を決定するための数値的値であり、メッセージがアプリケーションメッセージ、提案、またはコミットであるかどうかで構成されています。
Even though some of this metadata information does not consist of sensitive information, when correlated with other data a network observer might be able to reconstruct sensitive information. Using a secure channel to transfer this information will prevent a network attacker from accessing this MLS protocol metadata if it cannot compromise the secure channel.
このメタデータ情報の一部は機密情報で構成されていませんが、ネットワークオブザーバーが機密情報を再構築できる他のデータと相関している場合。安全なチャネルを使用してこの情報を転送すると、ネットワーク攻撃者がセキュアチャネルを妥協できない場合は、ネットワーク攻撃者がこのMLSプロトコルメタデータにアクセスできません。
MLS provides an authenticated "Additional Authenticated Data" (AAD) field for applications to make data available outside a PrivateMessage, while cryptographically binding it to the message.
MLSは、アプリケーションがPrivateMessageの外でデータを利用できるようにするための、認証された「追加認証データ（Additional Authenticated Data: AAD）」フィールドを提供し、同時にそれをメッセージに暗号的にバインドします。
*Recommendation:* Use the "Additional Authenticated Data" field of the PrivateMessage instead of using other unauthenticated means of sending metadata throughout the infrastructure. If the data should be kept private, the infrastructure should use encrypted application messages instead.
*推奨事項:* インフラストラクチャ全体にメタデータを送信する他の認証されていない手段を使用する代わりに、PrivateMessageの「追加認証データ」フィールドを使用してください。データをプライベートに保つ必要がある場合、インフラストラクチャは代わりに暗号化されたアプリケーションメッセージを使用する必要があります。
Having no secure channel to exchange MLS messages can have a serious impact on privacy when transmitting unencrypted group operation messages. Observing the contents and signatures of the group operation messages may lead an adversary to extract information about the group membership.
MLSメッセージを交換するための安全なチャネルがないことは、暗号化されていないグループ操作メッセージを送信する際にプライバシーに深刻な影響を与える可能性があります。グループ操作メッセージの内容と署名を観察すると、敵がグループメンバーシップに関する情報を抽出することにつながる可能性があります。
*Recommendation:* Never use the unencrypted mode for group operations without using a secure channel for the transport layer.
*推奨事項:* トランスポート層にセキュアなチャネルを使用せずに、グループ操作に暗号化されていないモードを使用しないでください。
In general, we do not consider DoS resistance to be the responsibility of the protocol. However, it should not be possible for anyone aside from the DS to perform a trivial DoS attack from which it is hard to recover. This can be achieved through the secure transport layer, which prevents selective attack on MLS communications by network attackers.
一般に、DoS耐性がプロトコルの責任であるとは考えていません。ただし、DS以外の誰かが、回復が困難な些細なDoS攻撃を実行できるべきではありません。これは、ネットワーク攻撃者によるMLS通信への選択的な攻撃を防ぐセキュアなトランスポート層を通じて達成できます。
In the centralized setting, DoS protection can typically be performed by using tickets or cookies which identify users to a service for a certain number of connections. Such a system helps in preventing anonymous clients from sending arbitrary numbers of group operation messages to the DS or the MLS clients.
集中型の設定では、DoS保護は通常、一定数の接続に対してユーザーをサービスに識別させるチケットまたはCookieを使用することで実行できます。このようなシステムは、匿名のクライアントがDSまたはMLSクライアントに任意の数のグループ操作メッセージを送信するのを防ぐのに役立ちます。
*Recommendation:* Use credentials uncorrelated with specific users to help prevent DoS attacks, in a privacy-preserving manner. Note that the privacy of these mechanisms has to be adjusted in accordance with the privacy expected from secure transport links. (See more discussion in the next section.)
*推奨事項:* 特定のユーザーと相関のない資格情報を使用して、プライバシーを保護する方法でDoS攻撃を防ぐのに役立ててください。これらのメカニズムのプライバシーは、セキュアなトランスポートリンクから期待されるプライバシーに従って調整する必要があることに注意してください。（次のセクションの詳細を参照してください。）
As noted above, MLS is designed to provide some robustness in the face of tampering within the secure transport, e.g., tampering by the DS. The confidentiality and authenticity properties of MLS prevent the DS from reading or writing messages. MLS also provides a few tools for detecting message suppression, with the caveat that message suppression cannot always be distinguished from transport failure.
上記のように、MLSは、セキュアなトランスポート内での改ざん、たとえばDSによる改ざんに直面しても、ある程度の堅牢性を提供するように設計されています。MLSの機密性と真正性のプロパティは、DSがメッセージを読み書きすることを防ぎます。MLSは、メッセージの抑制を検出するためのいくつかのツールも提供しますが、メッセージの抑制が常にトランスポートの障害と区別できるとは限らないという注意点があります。
Each encrypted MLS message carries a per-sender incrementing "generation" number. If a group member observes a gap in the generation sequence for a sender, then they know that they have missed a message from that sender. MLS also provides a facility for group members to send authenticated acknowledgments of application messages received within a group.
暗号化された各MLSメッセージには、センダーごとの増分「生成」数が含まれます。グループメンバーが送信者の生成シーケンスのギャップを観察した場合、彼らはその送信者からのメッセージを見逃したことを知っています。MLSは、グループメンバーがグループ内で受信したアプリケーションメッセージの認証された謝辞を送信できる施設も提供します。
As discussed in Section 5, the DS is trusted to select the single Commit message that is applied in each epoch from among the Commits sent by group members. Since only one Commit per epoch is meaningful, it's not useful for the DS to transmit multiple Commits to clients. The risk remains that the DS will use the ability maliciously.
セクション5で説明したように、DSは、グループメンバーから送られたコミットの中から各エポックに適用される単一のコミットメッセージを選択することが信頼されています。エポックごとに1つのコミットのみが意味があるため、DSが複数のコミットをクライアントに送信することは役に立たないことです。DSが能力を悪意を持って使用するというリスクは残ります。
MLS aims to provide a number of security guarantees, covering authentication, as well as confidentiality guarantees to different degrees in different scenarios.
MLSは、認証をカバーする多くのセキュリティ保証を提供すること、およびさまざまなシナリオでさまざまな程度の機密保証を提供することを目指しています。
MLS enforces the encryption of application messages and thus generally guarantees authentication and confidentiality of application messages sent in a group.
MLSはアプリケーションメッセージの暗号化を強制するため、一般的にグループで送信されたアプリケーションメッセージの認証と機密性を保証します。
In particular, this means that only other members of a given group can decrypt the payload of a given application message, which includes information about the sender of the message.
特に、これは、特定のグループの他のメンバーのみが、メッセージの送信者に関する情報を含む特定のアプリケーションメッセージのペイロードを復号化できることを意味します。
Similarly, group members receiving a message from another group member can authenticate that group member as the sender of the message and verify the message's integrity.
同様に、別のグループメンバーからメッセージを受信するグループメンバーは、そのグループメンバーをメッセージの送信者として認証し、メッセージの整合性を確認できます。
Message content can be deniable if the signature keys are exchanged over a deniable channel prior to signing messages.
メッセージに署名する前に、署名キーが否認可能なチャネルで交換される場合、メッセージコンテンツは否認可能です。
Depending on the group settings, handshake messages can be encrypted as well. If that is the case, the same security guarantees apply.
グループ設定に応じて、握手メッセージも暗号化できます。その場合、同じセキュリティ保証が適用されます。
MLS optionally allows the addition of padding to messages, mitigating the amount of information leaked about the length of the plaintext to an observer on the network.
MLSは、オプションでメッセージにパディングを追加することができ、ネットワーク上のオブザーバーにプレーンテキストの長さについてリークされた情報の量を軽減します。
MLS provides additional protection regarding secrecy of past messages and future messages. These cryptographic security properties are forward secrecy (FS) and post-compromise security (PCS).
MLSは、過去のメッセージと将来のメッセージの秘匿性に関する追加の保護を提供します。これらの暗号学的セキュリティ特性は、前方秘匿性（FS）および侵害後のセキュリティ（PCS）です。
FS means that access to all encrypted traffic history combined with access to all current keying material on clients will not defeat the secrecy properties of messages older than the oldest key of the compromised client. Note that this means that clients have to delete the appropriate keys as soon as they have been used with the expected message; otherwise, the secrecy of the messages and the security of MLS are considerably weakened.
FSとは、すべての暗号化されたトラフィック履歴へのアクセスと、クライアント上の現在のすべての鍵マテリアルへのアクセスを組み合わせても、侵害されたクライアントの最も古いキーよりも古いメッセージの秘匿性が損なわれないことを意味します。これは、クライアントが期待されるメッセージでキーを使用したらすぐに適切なキーを削除しなければならないことを意味することに注意してください。そうしないと、メッセージの秘匿性とMLSのセキュリティが著しく弱体化します。
PCS means that if a group member's state is compromised at some time t1 but the group member subsequently performs an update at some time t2, then all MLS guarantees apply to messages sent by the member after time t2 and to messages sent by other members after they have processed the update. For example, if an attacker learns all secrets known to Alice at time t1, including both Alice's long-term secret keys and all shared group keys, but Alice performs a key update at time t2, then the attacker is unable to violate any of the MLS security properties after the updates have been processed.
PCSは、グループメンバーの状態がある時点t1で侵害されたとしても、そのグループメンバーがその後ある時点t2で更新を実行すれば、t2以降にそのメンバーが送信したメッセージ、および他のメンバーが更新を処理した後に送信したメッセージに対して、すべてのMLS保証が適用されることを意味します。たとえば、攻撃者が時点t1でアリスが知っているすべての秘密（アリスの長期秘密鍵とすべての共有グループキーの両方を含む）を知ったとしても、アリスが時点t2でキー更新を実行すれば、攻撃者は更新が処理された後にMLSセキュリティ特性のいずれも侵害できなくなります。
Both of these properties are satisfied even against compromised DSs and ASes in the case where some other mechanism for verifying keys is in use, such as Key Transparency [KT].
これらの特性は両方とも、鍵の透明性（Key Transparency）[KT]など、鍵を検証する他のメカニズムが使用されている場合において、侵害されたDSおよびASに対しても満たされます。
Confidentiality is mainly ensured on the client side. Because FS and PCS rely on the active deletion and replacement of keying material, any client which is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised.
機密性は、主にクライアント側で保証されています。FSとPCSは、鍵マテリアルの能動的な削除と交換に依存しているため、長期間オフラインのクライアントは依然として古い鍵マテリアルを保持している可能性があり、後で侵害された場合、FSとPCSの両方にとって脅威になる可能性があります。
MLS partially defends against this problem by active members including new keying material. However, not much can be done on the inactive side especially in the case where the client has not processed messages.
MLSは、アクティブなメンバーが新しい鍵マテリアルを含めることによって、この問題に対して部分的に防御します。ただし、特にクライアントがメッセージを処理していない場合、非アクティブな側ではそれほど多くのことはできません。
*Recommendation:* Mandate key updates from clients that are not otherwise sending messages and evict clients that are idle for too long.
*推奨事項:* メッセージを送信していないクライアントからのキー更新を義務付け、あまりにも長い間アイドル状態のクライアントを追放してください。
These recommendations will reduce the ability of idle compromised clients to decrypt a potentially long set of messages that might have been sent after the point of compromise.
これらの推奨事項により、アイドル状態で侵害されたクライアントが、侵害時点以降に送信された可能性のある大量のメッセージを復号化する能力が低下します。
The precise details of such mechanisms are a matter of local policy and beyond the scope of this document.
このようなメカニズムの正確な詳細は、ローカルポリシーの問題であり、このドキュメントの範囲を超えています。
MLS provides strong authentication within a group, such that a group member cannot send a message that appears to be from another group member. Additionally, some services require that a recipient be able to prove to the service provider that a message was sent by a given client, in order to report abuse. MLS supports both of these use cases. In some deployments, these services are provided by mechanisms which allow the receiver to prove a message's origin to a third party. This is often called "non-repudiation".
MLSはグループ内で強力な認証を提供するため、グループメンバーは別のグループメンバーから来たように見えるメッセージを送信できません。さらに、一部のサービスでは、悪用を報告するために、受信者が特定のクライアントによってメッセージが送信されたことをサービスプロバイダーに証明できる必要があります。MLSはこれら両方のユースケースをサポートしています。一部の展開では、これらのサービスは、受信者がメッセージの起源を第三者に証明できるメカニズムによって提供されます。これはしばしば「否認防止（non-repudiation）」と呼ばれます。
Roughly speaking, "deniability" is the opposite of "non-repudiation", i.e., the property that it is impossible to prove to a third party that a message was sent by a given sender. MLS does not make any claims with regard to deniability. It may be possible to operate MLS in ways that provide certain deniability properties, but defining the specific requirements and resulting notions of deniability requires further analysis.
大まかに言えば、「否認可能性（deniability）」は「否認防止」の反対です。つまり、特定の送信者によってメッセージが送信されたことを第三者に証明することが不可能であるという特性です。MLSは、否認可能性に関して何の主張もしません。特定の否認可能性特性を提供するような方法でMLSを運用することは可能かもしれませんが、特定の要件と結果として生じる否認可能性の概念を定義するには、さらなる分析が必要です。
When a user has multiple devices, the base MLS protocol only describes how to operate each device as a distinct client in the MLS groups that the user is a member of. As a result, the other members of the group will be able to identify which of a user's devices sent each message and, therefore, which device the user was using at the time. Group members would also be able to detect when the user adds or removes authorized devices from their account. For some applications, this may be an unacceptable breach of the user's privacy.
ユーザーが複数のデバイスを持っている場合、基本のMLSプロトコルは、ユーザーがメンバーであるMLSグループ内で各デバイスを個別のクライアントとして操作する方法のみを記述しています。その結果、グループの他のメンバーは、ユーザーのどのデバイスが各メッセージを送信したか、したがってユーザーがその時点でどのデバイスを使用していたかを特定できます。グループメンバーは、ユーザーがアカウントから許可されたデバイスを追加または削除したときにも検出できます。一部のアプリケーションにとって、これはユーザーのプライバシーに対する許容できない侵害となる可能性があります。
This risk only arises when the leaf nodes for the clients in question provide data that can be used to correlate the clients. One way to mitigate this risk is by only doing client-level authentication within MLS. If user-level authentication is still desirable, the application would have to provide it through some other mechanism.
このリスクは、問題のクライアントのリーフノードがクライアントを関連付けるために使用できるデータを提供する場合にのみ発生します。このリスクを軽減する1つの方法は、MLS内でクライアントレベルの認証のみを行うことです。ユーザーレベルの認証が依然として望ましい場合、アプリケーションは他のメカニズムを通じてそれを提供する必要があります。
It is also possible to maintain user-level authentication while hiding information about the clients that a user owns. This can be done by having the clients share cryptographic state, so that they appear as a single client within the MLS group. Appearing as a single client has the privacy benefits of no longer leaking which device was used to send a particular message and no longer leaking the user's authorized devices. However, the application would need to provide a synchronization mechanism so that the state of each client remains consistent across changes to the MLS group. Flaws in this synchronization mechanism may impair the ability of the user to recover from a compromise of one of their devices. In particular, state synchronization may make it easier for an attacker to use one compromised device to establish exclusive control of a user's account, locking them out entirely and preventing them from recovering.
また、ユーザーが所有するクライアントに関する情報を隠しながら、ユーザーレベルの認証を維持することも可能です。これは、クライアントに暗号学的状態を共有させることで実現でき、MLSグループ内では単一のクライアントとして見えるようになります。単一のクライアントとして見えることには、特定のメッセージを送信するためにどのデバイスが使用されたかが漏洩しなくなり、ユーザーの許可されたデバイスも漏洩しなくなるというプライバシー上の利点があります。ただし、アプリケーションは、各クライアントの状態がMLSグループへの変更全体で一貫性を保つように同期メカニズムを提供する必要があります。この同期メカニズムに欠陥があると、ユーザーがデバイスの1つの侵害から回復する能力が損なわれる可能性があります。特に、状態の同期により、攻撃者が1つの侵害されたデバイスを使用してユーザーのアカウントの排他的制御を確立し、ユーザーを完全に締め出して回復を防ぐことが容易になる可能性があります。
The MLS protocol adopts a threat model which includes multiple forms of endpoint/client compromise. While adversaries are in a strong position if they have compromised an MLS client, there are still situations where security guarantees can be recovered thanks to the PCS properties achieved by the MLS protocol.
MLSプロトコルは、エンドポイント/クライアントの侵害の複数の形式を含む脅威モデルを採用しています。攻撃者はMLSクライアントを侵害した場合、強力な立場にありますが、MLSプロトコルによって達成されたPCS特性のおかげで、セキュリティ保証を回復できる状況がまだあります。
In this section we will explore the consequences and recommendations regarding the following compromise scenarios:
このセクションでは、次の侵害シナリオに関する結果と推奨事項を探ります。
* The attacker has access to a symmetric encryption key.
* 攻撃者は、対称暗号化キーにアクセスできます。
* The attacker has access to an application ratchet secret.
* 攻撃者は、アプリケーションラチェットシークレットにアクセスできます。
* The attacker has access to the group secrets for one group.
* 攻撃者は、1つのグループのグループ秘密にアクセスできます。
* The attacker has access to a signature oracle for any group.
* 攻撃者は、任意のグループの署名オラクルにアクセスできます。
* The attacker has access to the signature key for one group.
* 攻撃者は、1つのグループの署名鍵にアクセスできます。
* The attacker has access to all secrets of a user for all groups (full state compromise).
* 攻撃者は、すべてのグループ（完全な状態妥協）に対してユーザーのすべての秘密にアクセスできます。
As described above, each MLS epoch creates a new group secret.
前述のように、各MLSエポックは新しいグループ秘密を作成します。
These group secrets are then used to create a per-sender ratchet secret, which in turn is used to create a per-sender Authenticated Encryption with Associated Data (AEAD) [RFC5116] key that is then used to encrypt MLS plaintext messages. Each time a message is sent, the ratchet secret is used to create a new ratchet secret and a new corresponding AEAD key. Because of the properties of the key derivation function, it is not possible to compute a ratchet secret from its corresponding AEAD key or compute ratchet secret n-1 from ratchet secret n.
これらのグループ秘密は、送信者ごとのラチェットシークレットを作成するために使用され、それがさらに送信者ごとの認証付き暗号（AEAD）[RFC5116]キーを作成するために使用され、このキーがMLS平文メッセージを暗号化するために使用されます。メッセージが送信されるたびに、ラチェットシークレットは新しいラチェットシークレットと新しい対応するAEADキーを作成するために使用されます。鍵導出関数の特性により、対応するAEADキーからラチェットシークレットを計算したり、ラチェットシークレットnからラチェットシークレットn-1を計算したりすることはできません。
Below, we consider the compromise of each of these pieces of keying material in turn, in ascending order of severity. While this is a limited kind of compromise, it can be realistic in cases of implementation vulnerabilities where only part of the memory leaks to the adversary.
以下では、これらの鍵マテリアルのそれぞれの侵害を、深刻度の低い順に検討します。これは限定的な種類の侵害ですが、メモリの一部のみが攻撃者に漏洩する実装の脆弱性の場合には現実的である可能性があります。
In some circumstances, adversaries may have access to specific AEAD keys and nonces which protect an application message or a group operation message. Compromise of these keys allows the attacker to decrypt the specific message encrypted with that key but no other; because the AEAD keys are derived from the ratchet secret, it cannot generate the next ratchet secret and hence not the next AEAD key.
状況によっては、攻撃者がアプリケーションメッセージまたはグループ操作メッセージを保護する特定のAEADキーとナンスにアクセスできる場合があります。これらのキーが侵害されると、攻撃者はそのキーで暗号化された特定のメッセージを復号化できますが、他のメッセージは復号化できません。AEADキーはラチェットシークレットから派生しているため、次のラチェットシークレットを生成することはできず、したがって次のAEADキーも生成できません。
In the case of an application message, an AEAD key compromise means that the encrypted application message will be leaked as well as the signature over that message. This means that the compromise has both confidentiality and privacy implications on the future AEAD encryptions of that chain. In the case of a group operation message, only the privacy is affected, as the signature is revealed, because the secrets themselves are protected by Hybrid Public Key Encryption (HPKE). Note that under that compromise scenario, authentication is not affected in either of these cases. As every member of the group can compute the AEAD keys for all the chains (they have access to the group secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common framing mechanism is weak. Successful decryption of an AEAD encrypted message only guarantees that some member of the group -- or in this case an attacker who has compromised the AEAD keys -- sent the message.
アプリケーションメッセージの場合、AEADキーの侵害は、暗号化されたアプリケーションメッセージとそのメッセージに対する署名が漏洩することを意味します。これは、侵害がそのチェーンの将来のAEAD暗号化に対して機密性とプライバシーの両方に影響を与えることを意味します。グループ操作メッセージの場合、秘密自体はハイブリッド公開鍵暗号化（HPKE）によって保護されているため、署名が明らかにされることによるプライバシーへの影響のみが生じます。この侵害シナリオでは、いずれの場合も認証は影響を受けないことに注意してください。グループのすべてのメンバーは、メッセージを送受信するためにすべてのチェーンのAEADキーを計算できる（グループ秘密にアクセスできる）ため、共通フレーミングメカニズムのAEAD暗号化層によって提供される認証は弱いです。AEAD暗号化されたメッセージの復号化に成功しても、グループのいずれかのメンバー（またはこの場合、AEADキーを侵害した攻撃者）がメッセージを送信したことしか保証されません。
Compromise of the AEAD keys allows the attacker to send an encrypted message using that key, but the attacker cannot send a message to a group that appears to be from any valid client because the attacker cannot forge the signature. This applies to all the forms of symmetric key compromise described in Section 8.3.1.
AEADキーの侵害により、攻撃者はそのキーを使用して暗号化されたメッセージを送信できますが、攻撃者は署名を偽造できないため、有効なクライアントから送信されたように見えるメッセージをグループに送信することはできません。これは、セクション8.3.1で説明されているすべての形式の対称鍵侵害に適用されます。
When a ratchet secret is compromised, the adversary can compute both the current AEAD keys for a given sender and any future keys for that sender in this epoch. Thus, it can decrypt current and future messages by the corresponding sender. However, because it does not have previous ratchet secrets, it cannot decrypt past messages as long as those secrets and keys have been deleted.
ラチェットシークレットが侵害されると、攻撃者は特定の送信者の現在のAEADキーと、このエポックにおけるその送信者の将来のキーの両方を計算できます。したがって、対応する送信者による現在および将来のメッセージを復号化できます。ただし、以前のラチェットシークレットは持っていないため、それらの秘密とキーが削除されている限り、過去のメッセージを復号化することはできません。
Because of its forward secrecy guarantees, MLS will also retain secrecy of all other AEAD keys generated for _other_ MLS clients, outside this dedicated chain of AEAD keys and nonces, even within the epoch of the compromise. MLS provides post-compromise security against an active adaptive attacker across epochs for AEAD encryption, which means that as soon as the epoch is changed, if the attacker does not have access to more secret material they won't be able to access any protected messages from future epochs.
前方秘匿性の保証により、MLSは、侵害されたエポック内であっても、この専用のAEADキーとナンスのチェーンの外で、_他の_MLSクライアント用に生成された他のすべてのAEADキーの秘匿性を保持します。MLSは、AEAD暗号化に関してエポックをまたぐアクティブな適応的攻撃者に対して侵害後のセキュリティ（PCS）を提供します。つまり、エポックが変更されるとすぐに、攻撃者がそれ以上の秘密マテリアルにアクセスできない限り、将来のエポックからの保護されたメッセージにはアクセスできなくなります。
An adversary who gains access to a set of group secrets -- as when a member of the group is compromised -- is significantly more powerful. In this section, we consider the case where the signature keys are not compromised. This can occur if the attacker has access to part of the memory containing the group secrets but not to the signature keys which might be stored in a secure enclave.
グループ秘密のセットへのアクセスを獲得した攻撃者は（グループのメンバーが侵害された場合のように）、はるかに強力です。このセクションでは、署名キーが侵害されていない場合を検討します。これは、攻撃者がグループ秘密を含むメモリの一部にはアクセスできるが、セキュアエンクレーブに保存されている可能性のある署名キーにはアクセスできない場合に発生する可能性があります。
In this scenario, the adversary gains the ability to compute any number of ratchet secrets for the epoch and their corresponding AEAD encryption keys and thus can encrypt and decrypt all messages for the compromised epochs.
このシナリオでは、攻撃者はエポックの任意の数のラチェットシークレットとそれに対応するAEAD暗号化キーを計算する能力を獲得し、したがって、侵害されたエポックのすべてのメッセージを暗号化および復号化できます。
If the adversary is passive, it is expected from the PCS properties of the MLS protocol that as soon as the compromised party remediates the compromise and sends an honest Commit message, the next epochs will provide message secrecy.
攻撃者が受動的である場合、MLSプロトコルのPCS特性から、侵害された当事者が侵害を修復し、正当なCommitメッセージを送信するとすぐに、次のエポックではメッセージの秘匿性が提供されることが期待されます。
If the adversary is active, the adversary can engage in the protocol itself and perform updates on behalf of the compromised party with no ability for an honest group to recover message secrecy. However, MLS provides PCS against active adaptive attackers through its Remove group operation. This means that as long as other members of the group are honest, the protocol will guarantee message secrecy for all messages exchanged in the epochs after the compromised party has been removed.
攻撃者が能動的である場合、攻撃者はプロトコル自体に関与し、侵害された当事者に代わって更新を実行できるため、正当なグループがメッセージの秘匿性を回復することはできません。ただし、MLSはRemoveグループ操作を通じて、アクティブな適応的攻撃者に対するPCSを提供します。これは、グループの他のメンバーが正当である限り、侵害された当事者が削除された後のエポックで交換されるすべてのメッセージに対して、プロトコルがメッセージの秘匿性を保証することを意味します。
If an active adversary has compromised an MLS client and can sign messages, two different scenarios emerge. In the strongest compromise scenario, the attacker has access to the signing key and can forge authenticated messages. In a weaker, yet realistic scenario, the attacker has compromised a client but the client signature keys are protected with dedicated hardware features which do not allow direct access to the value of the private key and instead provide a signature API.
アクティブな攻撃者がMLSクライアントを侵害し、メッセージに署名できる場合、2つの異なるシナリオが考えられます。最も強力な侵害シナリオでは、攻撃者は署名キーにアクセスでき、認証されたメッセージを偽造できます。より弱いが現実的なシナリオでは、攻撃者はクライアントを侵害していますが、クライアントの署名キーは、秘密鍵の値への直接アクセスを許可せず、代わりに署名APIを提供する専用ハードウェア機能で保護されています。
When considering an active adaptive attacker with access to a signature oracle, the compromise scenario implies a significant impact on both the secrecy and authentication guarantees of the protocol, especially if the attacker also has access to the group secrets. In that case, both secrecy and authentication are broken. The attacker can generate any message, for the current and future epochs, until the compromise is remediated and the formerly compromised client sends an honest update.
署名オラクルへのアクセスを持つアクティブな適応的攻撃者を考慮する場合、この侵害シナリオは、特に攻撃者がグループ秘密にもアクセスできる場合、プロトコルの秘匿性と認証の保証の両方に重大な影響を及ぼします。その場合、秘匿性と認証の両方が破られます。攻撃者は、侵害が修復され、以前に侵害されたクライアントが正当な更新を送信するまで、現在および将来のエポックに対して任意のメッセージを生成できます。
Note that under this compromise scenario, the attacker can perform all operations which are available to a legitimate client even without access to the actual value of the signature key.
この侵害シナリオでは、攻撃者は署名キーの実際の値にアクセスできなくても、正当なクライアントが利用できるすべての操作を実行できることに注意してください。
The difference between having access to the value of the signature key and only having access to a signing oracle is not about the ability of an active adaptive network attacker to perform different operations during the time of the compromise; the attacker can perform every operation available to a legitimate client in both cases.
署名キーの値にアクセスできることと、署名オラクルにのみアクセスできることの違いは、侵害中にアクティブな適応的ネットワーク攻撃者が異なる操作を実行できる能力にあるわけではありません。攻撃者はどちらの場合でも、正当なクライアントが利用できるすべての操作を実行できます。
There is a significant difference, however, in terms of recovery after a compromise.
ただし、侵害後の回復という点では大きな違いがあります。
Because of the PCS guarantees provided by the MLS protocol, when a previously compromised client recovers from compromise and performs an honest Commit, both secrecy and authentication of future messages can be recovered as long as the attacker doesn't otherwise get access to the key. Because the adversary doesn't have the signing key, they cannot authenticate messages on behalf of the compromised party, even if they still have control over some group keys by colluding with other members of the group.
MLSプロトコルによって提供されるPCS保証により、以前に侵害されたクライアントが侵害から回復し、正当なCommitを実行すると、攻撃者が他の方法でキーにアクセスしない限り、将来のメッセージの秘匿性と認証の両方を回復できます。攻撃者は署名キーを持っていないため、グループの他のメンバーと共謀して一部のグループキーをまだ制御していたとしても、侵害された当事者に代わってメッセージを認証することはできません。
This is in contrast with the case where the signature key is leaked. In that case, the compromised endpoint needs to refresh its credentials and invalidate the old credentials before the attacker will be unable to authenticate messages.
これは、署名キーが漏洩した場合とは対照的です。その場合、侵害されたエンドポイントは、攻撃者がメッセージを認証できなくなるようにするために、資格情報を更新し、古い資格情報を無効にする必要があります。
Beware that in both oracle and private key access, an active adaptive attacker can follow the protocol and request to update its own credential. This in turn induces a signature key rotation, which could provide the attacker with part or the full value of the private key, depending on the architecture of the service provider.
オラクルアクセスと秘密鍵アクセスの両方において、アクティブな適応的攻撃者はプロトコルに従い、自身の資格情報の更新を要求できることに注意してください。これにより署名キーのローテーションが誘発され、サービスプロバイダーのアーキテクチャによっては、攻撃者に秘密鍵の一部または完全な値が提供される可能性があります。
*Recommendation:* Signature private keys should be compartmentalized from other secrets and preferably protected by a Hardware Security Module (HSM) or dedicated hardware features to allow recovery of the authentication for future messages after a compromise.
*推奨事項:* 署名秘密鍵は他の秘密から分離し、できればハードウェアセキュリティモジュール（HSM）または専用のハードウェア機能によって保護して、侵害後に将来のメッセージの認証を回復できるようにする必要があります。
*Recommendation:* When the credential type supports revocation, the users of a group should check for revoked keys.
*推奨事項:* 資格情報タイプが失効をサポートしている場合、グループのユーザーは失効したキーを確認する必要があります。
In real-world compromise scenarios, it is often the case that adversaries target specific devices to obtain parts of the memory or even the ability to execute arbitrary code in the targeted device.
現実世界の侵害シナリオでは、攻撃者が特定のデバイスを標的にしてメモリの一部を取得したり、標的デバイスで任意のコードを実行する能力を取得したりすることがよくあります。
Also, recall that in this setting, the application will often retain the unencrypted messages. If so, the adversary does not have to break encryption at all to access sent and received messages. Messages may also be sent by using the application to instruct the protocol implementation.
また、この設定では、アプリケーションが暗号化されていないメッセージを保持することが多いことを思い出してください。その場合、攻撃者は送受信されたメッセージにアクセスするために暗号化を破る必要はまったくありません。アプリケーションを使用してプロトコル実装に指示することで、メッセージを送信することもできます。
*Recommendation:* If messages are stored on the device, they should be protected using encryption at rest, and the keys used should be stored securely using dedicated mechanisms on the device.
*推奨事項:* メッセージがデバイスに保存されている場合、それらは保存データの暗号化（encryption at rest）を使用して保護されるべきであり、使用されるキーはデバイス上の専用メカニズムを使用して安全に保存されるべきです。
*Recommendation:* If the threat model of the system includes an adversary that can access the messages on the device without even needing to attack MLS, the application should delete plaintext and ciphertext messages as soon as practical after encryption or decryption.
*推奨事項:* システムの脅威モデルに、MLSを攻撃する必要なくデバイス上のメッセージにアクセスできる攻撃者が含まれている場合、アプリケーションは、暗号化または復号化後、実用的な範囲でできるだけ早く平文および暗号文のメッセージを削除する必要があります。
Note that this document makes a clear distinction between the way signature keys and other group shared secrets must be handled. In particular, a large set of group secrets cannot necessarily be assumed to be protected by an HSM or secure enclave features. This is especially true because these keys are frequently used and changed with each message received by a client.
このドキュメントでは、署名キーと他のグループ共有秘密の取り扱い方法を明確に区別していることに注意してください。特に、大規模なグループ秘密のセットは、必ずしもHSMまたはセキュアエンクレーブ機能によって保護されていると想定することはできません。これらのキーは頻繁に使用され、クライアントがメッセージを受信するたびに変更されるため、これは特に当てはまります。
However, the signature private keys are mostly used by clients to send a message. They also provide strong authentication guarantees to other clients; hence, we consider that their protection by additional security mechanisms should be a priority.
ただし、署名秘密鍵は主にクライアントがメッセージを送信するために使用されます。また、他のクライアントに強力な認証保証を提供します。したがって、追加のセキュリティメカニズムによるそれらの保護を優先すべきであると考えています。
Overall, there is no way to detect or prevent these compromises, as discussed in the previous sections: Performing separation of the application secret states can help recovery after compromise; this is the case for signature keys, but similar concerns exist for a client's encryption private keys.
全体として、前のセクションで説明したように、これらの侵害を検出または防止する方法はありません。アプリケーションの秘密状態の分離を行うことは、侵害後の回復に役立ちます。これは署名キーの場合に当てはまりますが、クライアントの暗号化秘密鍵についても同様の懸念が存在します。
*Recommendation:* The secret keys used for public key encryption should be stored similarly to the way the signature keys are stored, as keys can be used to decrypt the group operation messages and contain the secret material used to compute all the group secrets.
*推奨事項:* 公開鍵暗号化に使用される秘密鍵は、署名キーと同様の方法で保存する必要があります。これらのキーはグループ操作メッセージを復号化するために使用でき、すべてのグループ秘密を計算するために使用される秘密マテリアルを含んでいる可能性があるためです。
Even if secure enclaves are not perfectly secure or are even completely broken, adopting additional protections for these keys can ease recovery of the secrecy and authentication guarantees after a compromise where, for instance, an attacker can sign messages without having access to the key. In certain contexts, the rotation of credentials might only be triggered by the AS through ACLs and hence be beyond the capabilities of the attacker.
セキュアエンクレーブが完全に安全でなかったり、完全に破られたりした場合でも、これらのキーに追加の保護を採用することで、たとえば攻撃者がキーにアクセスせずにメッセージに署名できるような侵害後の秘匿性と認証の保証の回復を容易にすることができます。特定のコンテキストでは、資格情報のローテーションはACLを介してASによってのみトリガーされる可能性があり、したがって攻撃者の能力を超えている可能性があります。
There are many scenarios leading to communication between the application on a device and the DS or the AS. In particular, when:
デバイス上のアプリケーションとDSまたはASの間の通信につながる多くのシナリオがあります。特に、以下の場合です：
* The application connects to the AS to generate or validate a new credential before distributing it.
* アプリケーションが、配布する前に新しい資格情報を生成または検証するためにASに接続する場合。
* The application fetches credentials at the DS prior to creating a messaging group (one-to-one or more than two clients).
* アプリケーションが、メッセージンググループ（1対1または3つ以上のクライアント）を作成する前に、DSで資格情報を取得する場合。
* The application fetches service provider information or messages on the DS.
* アプリケーションは、DSのサービスプロバイダー情報またはメッセージを取得します。
* The application sends service provider information or messages to the Delivery Service.
* アプリケーションが、サービスプロバイダーの情報またはメッセージを配信サービスに送信する場合。
In all these cases, the application will often connect to the device via a secure transport which leaks information about the origin of the request, such as the IP address and -- depending on the protocol -- the MAC address of the device.
これらすべての場合において、アプリケーションは、IPアドレスや（プロトコルによっては）デバイスのMACアドレスなど、リクエストの送信元に関する情報を漏洩するセキュアなトランスポートを介して接続することがよくあります。
Similar concerns exist in the peer-to-peer use cases for MLS.
MLSのピアツーピアのユースケースにも同様の懸念が存在します。
*Recommendation:* In the case where privacy or anonymity is important, using adequate protection such as Multiplexed Application Substrate over QUIC Encryption (MASQUE) [MASQUE-PROXY], Tor [Tor], or a VPN can improve metadata protection.
*推奨事項:* プライバシーや匿名性が重要な場合、Multiplexed Application Substrate over QUIC Encryption (MASQUE) [MASQUE-PROXY]、Tor [Tor]、またはVPNなどの適切な保護を使用することで、メタデータ保護を改善できます。
More generally, using anonymous credentials in an MLS-based architecture might not be enough to provide strong privacy or anonymity properties.
より一般的には、MLSベースのアーキテクチャで匿名の資格情報を使用するだけでは、強力なプライバシーまたは匿名性特性を提供するのに十分ではないかもしれません。
In the case where private data or metadata has to be persisted on the servers for functionality (mappings between identities and push tokens, group metadata, etc.), it should be stored encrypted at rest and only decrypted upon need during the execution. Honest service providers can rely on such "encryption at rest" mechanisms to be able to prevent access to the data when not using it.
機能性のために、プライベートデータまたはメタデータをサーバーに永続化する必要がある場合（アイデンティティとプッシュトークン、グループメタデータなどのマッピング）、保存時に暗号化（encrypted at rest）し、実行中に必要な場合にのみ復号化する必要があります。誠実なサービスプロバイダーは、そのような「保存データの暗号化」メカニズムに依存して、使用していないときにデータへのアクセスを防ぐことができます。
*Recommendation:* Store cryptographic material used for server-side decryption of sensitive metadata on the clients and only send it when needed. The server can use the secret to open and update encrypted data containers after which they can delete these keys until the next time they need it, in which case those can be provided by the client.
*推奨事項:* 機密性の高いメタデータのサーバー側での復号化に使用される暗号マテリアルをクライアントに保存し、必要な場合にのみ送信してください。サーバーはシークレットを使用して暗号化されたデータコンテナを開き、更新した後、次に必要になるまでこれらのキーを削除できます。その場合、キーはクライアントから提供されます。
*Recommendation:* Rely on group secrets exported from the MLS session for server-side encryption at rest and update the key after each removal from the group. Otherwise, rotate those keys on a regular basis.
*推奨事項:* サーバー側の保存データの暗号化のためにMLSセッションからエクスポートされるグループ秘密に依存し、グループからの各削除の後にキーを更新してください。それ以外の場合は、定期的にこれらのキーをローテーションさせてください。
MLS is intended to provide strong guarantees in the face of compromise of the DS. Even a totally compromised DS should not be able to read messages or inject messages that will be acceptable to legitimate clients. It should also not be able to undetectably remove, reorder, or replay messages.
MLSは、DSの侵害に直面しても強力な保証を提供することを目的としています。完全に侵害されたDSでさえ、メッセージを読んだり、正当なクライアントに受け入れられるメッセージを注入したりすることはできないはずです。また、検出されずにメッセージを削除、順序変更、またはリプレイすることもできないはずです。
However, a malicious DS can mount a variety of DoS attacks on the system, including total DoS attacks (where it simply refuses to forward any messages) and partial DoS attacks (where it refuses to forward messages to and from specific clients). As noted in Section 5.2, these attacks are only partially detectable by clients without an out-of-band channel. Ultimately, failure of the DS to provide reasonable service must be dealt with as a customer service matter, not via technology.
ただし、悪意のあるDSは、完全なDoS攻撃（メッセージの転送を単に拒否する）や部分的なDoS攻撃（特定のクライアントとのメッセージの転送を拒否する）など、システムに対してさまざまなDoS攻撃を仕掛けることができます。セクション5.2で述べたように、これらの攻撃は、帯域外チャネルのないクライアントには部分的にしか検出できません。最終的に、DSが適切なサービスを提供できない場合は、技術ではなくカスタマーサービスの問題として対処する必要があります。
Because the DS is responsible for providing the initial keying material to clients, it can provide stale keys. This does not inherently lead to compromise of the message stream, but does allow the DS to attack post-compromise security to a limited extent. This threat can be mitigated by having initial keys expire.
DSはクライアントに初期鍵マテリアルを提供する責任があるため、古いキーを提供する可能性があります。これは本質的にメッセージストリームの侵害につながるわけではありませんが、DSが侵害後のセキュリティ（PCS）を限定的な範囲で攻撃することを可能にします。この脅威は、初期キーに有効期限を設けることで軽減できます。
Initial keying material (KeyPackages) using the basic credential type is more vulnerable to replacement by a malicious or compromised DS, as there is no built-in cryptographic binding between the identity and the public key of the client.
基本的な資格情報タイプを使用した初期鍵マテリアル（KeyPackage）は、クライアントのアイデンティティと公開鍵の間に組み込みの暗号学的バインディングがないため、悪意のあるまたは侵害されたDSによる置き換えに対してより脆弱です。
*Recommendation:* Prefer a credential type in KeyPackages which includes a strong cryptographic binding between the identity and its key (for example, the x509 credential type). When using the basic credential type, take extra care to verify the identity (typically out of band).
*推奨事項:* アイデンティティとそのキーの間に強力な暗号学的バインディングを含むKeyPackageの資格情報タイプ（たとえば、x509資格情報タイプ）を好む（たとえば、X509資格情報タイプ）。基本的な資格情報タイプを使用する場合は、ID（通常はバンドから外れている）を確認するために特に注意してください。
Push tokens provide an important mechanism that is often ignored from the standpoint of privacy considerations. In many modern messaging architectures, applications are using push notification mechanisms typically provided by OS vendors. This is to make sure that when messages are available at the DS (or via other mechanisms if the DS is not a central server), the recipient application on a device knows about it. Sometimes the push notification can contain the application message itself, which saves a round trip with the DS.
プッシュトークンは、プライバシーに関する考慮事項の観点からしばしば無視される重要なメカニズムを提供します。多くの最新のメッセージングアーキテクチャでは、アプリケーションは通常、OSベンダーが提供するプッシュ通知メカニズムを使用しています。これは、DSでメッセージが利用可能である場合（またはDSが中央サーバーではない場合、他のメカニズムを介して）、デバイス上の受信アプリケーションがそれについて知っていることを確認するためです。プッシュ通知にアプリケーションメッセージ自体が含まれている場合があり、DSで往復を節約できます。
To "push" this information to the device, the service provider and the OS infrastructures use unique per-device, per-application identifiers called push tokens. This means that the push notification provider and the service provider have information on which devices receive information and at which point in time. Alternatively, non-mobile applications could use a WebSocket or persistent connection for notifications directly from the DS.
この情報をデバイスに「プッシュ」するために、サービスプロバイダーとOSインフラストラクチャは、プッシュトークンと呼ばれる一意のデバイスごとのアプリケーション識別子を使用します。これは、プッシュ通知プロバイダーとサービスプロバイダーが、どのデバイスが情報を受け取るか、どの時点で情報を受け取るかについての情報を持っていることを意味します。または、非モバイルアプリケーションは、DSから直接通知にWebSocketまたは永続的な接続を使用できます。
Even though the service provider and the push notification provider can't necessarily access the content (typically encrypted MLS messages), no technical mechanism in MLS prevents them from determining which devices are recipients of the same message.
サービスプロバイダーとプッシュ通知プロバイダーは、必ずしもコンテンツ（通常は暗号化されたMLSメッセージ）にアクセスすることはできませんが、MLSの技術的メカニズムは、どのデバイスが同じメッセージの受信者であるかを決定することを妨げません。
For secure messaging systems, push notifications are often sent in real time, as it is not acceptable to create artificial delays for message retrieval.
セキュアなメッセージングシステムの場合、メッセージ取得のために人為的な遅延を作成することは受け入れられないため、プッシュ通知はリアルタイムで送信されることがよくあります。
*Recommendation:* If real-time notifications are not necessary, one can delay notifications randomly across recipient devices using a mixnet or other techniques.
*推奨事項：*リアルタイム通知が必要ない場合、ミックスネットまたはその他の手法を使用して、レシピエントデバイス全体で通知をランダムに遅らせることができます。
Note that with a legal request to ask the service provider for the push token associated with an identifier, it is easy to correlate the token with a second request to the company operating the push notification system to get information about the device, which is often linked with a real identity via a cloud account, a credit card, or other information.
識別子に関連付けられたプッシュトークンをサービスプロバイダーに依頼する法的リクエストにより、トークンをプッシュ通知システムを操作してデバイスに関する情報を取得する会社に2番目のリクエストを簡単に相関させることができます。
*Recommendation:* If stronger privacy guarantees are needed with regard to the push notification provider, the client can choose to periodically connect to the DS without the need of a dedicated push notification infrastructure.
*推奨：*プッシュ通知プロバイダーに関してより強力なプライバシー保証が必要な場合、クライアントは専用のプッシュ通知インフラストラクチャを必要とせずに定期的にDSに接続することを選択できます。
Applications can also consider anonymous systems for server fanout (for example, [Loopix]).
アプリケーションは、サーバーファンアウト（[Loopix]など）の匿名システムを考慮することもできます。
The Authentication Service design is left to the infrastructure designers. In most designs, a compromised AS is a serious matter, as the AS can serve incorrect or attacker-provided identities to clients.
認証サービスの設計は、インフラストラクチャ設計者に任されています。ほとんどのデザインでは、クライアントに誤ったまたは攻撃者が提供するアイデンティティを提供できるように、深刻な問題であるように妥協されたものです。
* The attacker can link an identity to a credential.
* 攻撃者は、アイデンティティを資格情報にリンクできます。
* The attacker can generate new credentials.
* 攻撃者は新しい資格情報を生成できます。
* The attacker can sign new credentials.
* 攻撃者は新しい資格情報に署名できます。
* The attacker can publish or distribute credentials.
* 攻撃者は資格情報を公開または配布できます。
An attacker that can generate or sign new credentials may or may not have access to the underlying cryptographic material necessary to perform such operations. In that last case, it results in windows of time for which all emitted credentials might be compromised.
新しい資格情報を生成または署名できる攻撃者は、そのような操作を実行するために必要な基礎となる暗号化資料にアクセスできる場合とできない場合があります。その最後のケースでは、すべての放出された資格情報が損なわれる可能性のある時間の窓になります。
*Recommendation:* Use HSMs to store the root signature keys to limit the ability of an adversary with no physical access to extract the top-level signature private key.
*推奨事項：* HSMSを使用してルート署名キーを保存して、トップレベルの署名秘密鍵を抽出する物理的なアクセスなしで敵の能力を制限します。
Note that historically some systems generate signature keys on the AS and distribute the private keys to clients along with their credential. This is a dangerous practice because it allows the AS or an attacker who has compromised the AS to silently impersonate the client.
歴史的には、一部のシステムはASに署名キーを生成し、クライアントの資格とともにプライベートキーをクライアントに配布することに注意してください。これは、クライアントに静かになりすましているように妥協したASまたは攻撃者を許可するため、危険な慣行です。
One important property of MLS is that all members know which other members are in the group at all times. If all members of the group and the AS are honest, no parties other than the members of the current group can read and write messages protected by the protocol for that group.
MLSの重要な特性の1つは、すべてのメンバーが常にグループにいる他のメンバーを常に知っていることです。グループのすべてのメンバーと正直なところであれば、現在のグループのメンバー以外の当事者は、そのグループのプロトコルによって保護されているメッセージを読み書きすることはできません。
This guarantee applies to the cryptographic identities of the members. Details about how to verify the identity of a client depend on the MLS credential type used. For example, cryptographic verification of credentials can be largely performed autonomously (e.g., without user interaction) by the clients themselves for the x509 credential type.
この保証は、メンバーの暗号化のアイデンティティに適用されます。クライアントのIDを確認する方法に関する詳細は、使用されるMLS資格情報タイプに依存します。たとえば、資格情報の暗号化の検証は、X509資格型タイプのクライアント自体が自律的に（例えば、ユーザーインタラクションなし）に実行できます。
In contrast, when MLS clients use the basic credential type, some other mechanism must be used to verify identities. For instance, the Authentication Service could operate some sort of directory server to provide keys, or users could verify keys via an out-of-band mechanism.
対照的に、MLSクライアントが基本的な資格情報タイプを使用する場合、その他のメカニズムを使用してアイデンティティを検証する必要があります。たとえば、認証サービスは、ある種のディレクトリサーバーを操作してキーを提供するか、ユーザーがバンド外のメカニズムを介してキーを検証することができます。
*Recommendation:* Select the MLS credential type with the strongest security which is supported by all target members of an MLS group.
*推奨：* MLSグループのすべてのターゲットメンバーによってサポートされている最も強力なセキュリティで、MLS資格情報タイプを選択します。
*Recommendation:* Do not use the same signature key pair across groups. Update all keys for all groups on a regular basis. Do not preserve keys in different groups when suspecting a compromise.
*推奨事項：*グループ間で同じ署名キーペアを使用しないでください。定期的にすべてのグループのすべてのキーを更新します。妥協を疑うときは、さまざまなグループのキーを保存しないでください。
If the AS is compromised, it could validate a signature key pair (or generate a new one) for an attacker. The attacker could then use this key pair to join a group as if it were another of the user's clients. Because a user can have many MLS clients running the MLS protocol, it possibly has many signature key pairs for multiple devices. These attacks could be very difficult to detect, especially in large groups where the UI might not reflect all the changes back to the users. If the application participates in a key transparency mechanism in which it is possible to determine every key for a given user, then this would allow for detection of surreptitiously created false credentials.
ASが侵害されている場合、攻撃者の署名キーペアを検証する（または新しいものを生成する）ことができます。攻撃者は、このキーペアを使用して、まるでユーザーのクライアントの別の人であるかのようにグループに参加できます。ユーザーはMLSプロトコルを実行している多くのMLSクライアントを持つことができるため、複数のデバイスの多くの署名キーペアがある可能性があります。これらの攻撃は、特にUIがユーザーへのすべての変更を反映していない大規模なグループでは、検出が非常に困難になる可能性があります。アプリケーションが特定のユーザーのすべてのキーを決定できるキー透明性メカニズムに参加した場合、これにより、ひどく作成された誤った資格情報の検出が可能になります。
*Recommendation:* Make sure that MLS clients reflect all the membership changes to the users as they happen. If a choice has to be made because the number of notifications is too high, the client should provide a log of state of the device so that the user can examine it.
*推奨：* MLSクライアントが発生したときにすべてのメンバーシップの変更を反映していることを確認してください。通知の数が多すぎるために選択を行う必要がある場合、クライアントはユーザーがそれを調べることができるようにデバイスの状態のログを提供する必要があります。
*Recommendation:* Provide a key transparency mechanism for the AS to allow public verification of the credentials authenticated by this service.
*推奨事項：*このサービスによって認証された資格情報の公的検証を可能にするために、主要な透明性メカニズムを提供します。
While the ways to handle MLS credentials are not defined by the protocol or the architecture documents, the MLS protocol has been designed with a mechanism that can be used to provide out-of-band authentication to users. The authentication_secret generated for each user at each epoch of the group is a one-time, per-client authentication secret which can be exchanged between users to prove their identities to each other. This can be done, for instance, using a QR code that can be scanned by the other parties.
MLS資格情報を処理する方法は、プロトコルまたはアーキテクチャドキュメントによって定義されていませんが、MLSプロトコルは、ユーザーに帯域外認証を提供するために使用できるメカニズムを使用して設計されています。グループの各エポックで各ユーザーに対して生成されたAuthentication_Secretは、ユーザー間で交換して互いにアイデンティティを証明できる1回限りのクライアント認証秘密です。これは、たとえば、他の関係者がスキャンできるQRコードを使用して実行できます。
*Recommendation:* Provide one or more out-of-band authentication mechanisms to limit the impact of an AS compromise.
*推奨：* AS ASの妥協の影響を制限するために、1つまたは複数の帯域外認証メカニズムを提供します。
We note, again, that the AS may not be a centralized system and could be realized by many mechanisms such as establishing prior one-to-one deniable channels, gossiping, or using trust on first use (TOFU) for credentials used by the MLS protocol.
繰り返しますが、ASは集中システムではない可能性があり、MLSプロトコルで使用される資格情報の最初の使用チャネルの確立、うわさ、最初の使用（豆腐）の使用など、多くのメカニズムによって実現できることに注意してください。
Another important consideration is the ease of redistributing new keys on client compromise, which helps recovering security faster in various cases.
もう1つの重要な考慮事項は、クライアントの妥協に新しいキーを再配布するのが容易であることです。これは、さまざまな場合にセキュリティをより速く回復するのに役立ちます。
Group membership is itself sensitive information, and MLS is designed to limit the amount of persistent metadata. However, large groups often require an infrastructure that provides server fanout. In the case of client fanout, the destination of a message is known by all clients; hence, the server usually does not need this information. However, servers may learn this information through traffic analysis. Unfortunately, in a server-side fanout model, the Delivery Service can learn that a given client is sending the same message to a set of other clients. In addition, there may be applications of MLS in which the group membership list is stored on some server associated with the DS.
グループメンバーシップ自体は機密情報であり、MLSは永続的なメタデータの量を制限するように設計されています。ただし、大規模なグループには、サーバーファンアウトを提供するインフラストラクチャが必要です。クライアントファンアウトの場合、メッセージの宛先はすべてのクライアントに知られています。したがって、サーバーは通常、この情報を必要としません。ただし、サーバーはトラフィック分析を通じてこの情報を学習する場合があります。残念ながら、サーバー側のファンアウトモデルでは、配信サービスは、特定のクライアントが他のクライアントのセットに同じメッセージを送信していることを知ることができます。さらに、グループメンバーシップリストがDSに関連付けられた一部のサーバーに保存されるMLSのアプリケーションがある場合があります。
While this knowledge is not a breach of the protocol's authentication or confidentiality guarantees, it is a serious issue for privacy.
この知識は、プロトコルの認証または機密保証の違反ではありませんが、プライバシーの深刻な問題です。
Some infrastructures keep a mapping between keys used in the MLS protocol and user identities. An attacker with access to this information due to compromise or regulation can associate unencrypted group messages (e.g., Commits and Proposals) with the corresponding user identity.
一部のインフラストラクチャは、MLSプロトコルとユーザーIDで使用されるキー間のマッピングを保持しています。妥協または規制のためにこの情報にアクセスできる攻撃者は、暗号化されていないグループメッセージ（たとえば、コミットや提案など）を対応するユーザーIDと関連付けることができます。
*Recommendation:* Use encrypted group operation messages to limit privacy risks whenever possible.
*推奨：*暗号化されたグループ操作メッセージを使用して、可能な限りプライバシーリスクを制限します。
In certain cases, the adversary can access specific bindings between public keys and identities. If the signature keys are reused across groups, the adversary can get more information about the targeted user.
特定の場合、敵は公開鍵とアイデンティティの間の特定のバインディングにアクセスできます。署名キーがグループ間で再利用されている場合、敵はターゲットユーザーに関する詳細情報を取得できます。
*Recommendation:* Ensure that linking between public keys and identities only happens in expected scenarios.
*推奨：*公開キーとアイデンティティ間のリンクが予想されるシナリオでのみ行われることを確認してください。
Physical attacks on devices storing and executing MLS principals are not considered in depth in the threat model of the MLS protocol. While non-permanent, non-invasive attacks can sometimes be equivalent to software attacks, physical attacks are considered outside of the MLS threat model.
MLSプリンシパルの保存と実行のデバイスに対する物理的攻撃は、MLSプロトコルの脅威モデルでは深く考慮されていません。非永続的で非侵襲的な攻撃は、ソフトウェア攻撃と同等になる場合がありますが、MLS脅威モデルの外で物理的な攻撃が考慮されます。
Compromise scenarios typically consist of a software adversary, which can maintain active adaptive compromise and arbitrarily change the behavior of the client or service.
妥協シナリオは通常、ソフトウェアの敵で構成され、アクティブな適応妥協を維持し、クライアントまたはサービスの動作を任意に変えることができます。
On the other hand, security goals consider that honest clients will always run the protocol according to its specification. This relies on implementations of the protocol to securely implement the specification, which remains non-trivial.
一方、セキュリティの目標は、正直なクライアントがその仕様に応じて常にプロトコルを実行することを考慮しています。これは、プロトコルの実装に依存して、特定の仕様を安全に実装します。
*Recommendation:* Additional steps should be taken to protect the device and the MLS clients from physical compromise. In such settings, HSMs and secure enclaves can be used to protect signature keys.
*推奨：*デバイスとMLSクライアントを物理的な妥協から保護するために、追加の手順を実行する必要があります。このような設定では、HSMとセキュアエンクレーブを使用して署名キーを保護できます。
MLS does not protect against one group member replaying a PrivateMessage sent by another group member within the same epoch that the message was originally sent. Similarly, MLS does not protect against the replay (by a group member or otherwise) of a PublicMessage within the same epoch that the message was originally sent. Applications for whom replay is an important risk should apply mitigations at the application layer, as discussed below.
MLSは、メッセージが元々送信されたのと同じ時代内で別のグループメンバーから送信された民営化を再生する1つのグループメンバーから保護しません。同様に、MLSは、メッセージが元々送信されたのと同じエポック内のパブリックメスのリプレイ（グループメンバーまたはその他）から保護しません。以下で説明するように、リプレイが重要なリスクであるアプリケーションは、アプリケーションレイヤーに緩和を適用する必要があります。
In addition to the risks discussed in Section 8.3.1, an attacker with access to the ratchet secrets for an endpoint can replay PrivateMessage objects sent by other members of the group by taking the signed content of the message and re-encrypting it with a new generation of the original sender's ratchet. If the other members of the group interpret a message with a new generation as a fresh message, then this message will appear fresh. (This is possible because the message signature does not cover the generation field of the message.) Messages sent as PublicMessage objects similarly lack replay protections. There is no message counter comparable to the generation field in PrivateMessage.
セクション8.3.1で説明されているリスクに加えて、エンドポイントのラチェットシークレットにアクセスできる攻撃者は、メッセージの署名入りコンテンツを取得し、元の送信者のラチェットの新世代と再結晶することにより、グループの他のメンバーから送信されるprivatemessageオブジェクトを再生できます。グループの他のメンバーが新世代のメッセージを新鮮なメッセージとして解釈する場合、このメッセージは新鮮に見えます。（これは、メッセージの署名がメッセージの生成フィールドをカバーしていないために可能です。）PublicMessageオブジェクトとして送信されたメッセージも同様にリプレイ保護を欠いています。privatemessageの生成フィールドに匹敵するメッセージカウンターはありません。
Applications can detect replay by including a unique identifier for the message (e.g., a counter) in either the message payload or the authenticated_data field, both of which are included in the signatures for PublicMessage and PrivateMessage.
アプリケーションは、メッセージのペイロードまたはAuthentsed_Dataフィールドのいずれかにメッセージの一意の識別子（例：カウンター）を含めることにより、再生を検出できます。
Various academic works have analyzed MLS and the different security guarantees it aims to provide. The security of large parts of the protocol has been analyzed by [BBN19] (for MLS Draft 7), [ACDT21] (for MLS Draft 11), and [AJM20] (for MLS Draft 12).
さまざまな学術作品がMLSを分析しており、それが提供することを目的としたさまざまなセキュリティ保証があります。プロトコルの大部分のセキュリティは、[BBN19]（MLSドラフト7の場合）、[ACDT21]（MLSドラフト11の場合）、および[AJM20]（MLSドラフト12の場合）によって分析されています。
Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models. For example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20], [ACJM20], [AHKM21], [CGWZ25], and [WPB25] analyze the ratcheting tree sub-protocol of MLS that facilitates key agreement; [WPBB22] analyzes the sub-protocol of MLS for group state agreement and authentication; and [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule. Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS.
MLSプロトコルのさまざまなドラフトの個々のコンポーネントは、分離して異なる敵対モデルを使用して分析されています。たとえば、[bbr18]、[acdt19]、[acckmppwy19]、[ajm20]、[acjm20]、[ahkm21]、[cgwz25]、[wpb25]、[wpb25]は、主要な一致を促進するmlsのラチェットツリーサブプロトコルを分析します。[WPBB22]は、グループ状態の合意と認証のためのMLSのサブプロトコルを分析します。[BCK21]は、ラチェットツリーとキースケジュールのキー派生パスを分析します。最後に、[CHK21]は、MLSが提供する認証とクロスグループのヒーリング保証を分析します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.
[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/info/rfc9420>.
[ACCKKMPPWY19]
Alwen, J., Capretto, M., Cueto, M., Kamath, C., Klein, K.,
Markov, I., Pascual-Perez, G., Pietrzak, K., Walter, M.,
and M. Yeo, "Keep the Dirt: Tainted TreeKEM, Adaptively
and Actively Secure Continuous Group Key Agreement",
Cryptology ePrint Archive, 2019,
<https://eprint.iacr.org/2019/1489>.
[ACDT19] Alwen, J., Coretti, S., Dodis, Y., and Y. Tselekounis,
"Security Analysis and Improvements for the IETF MLS
Standard for Group Messaging", Cryptology ePrint Archive,
2019, <https://eprint.iacr.org/2019/1189.pdf>.
[ACDT21] Alwen, J., Coretti, S., Dodis, Y., and Y. Tselekounis,
"Modular Design of Secure Group Messaging Protocols and
the Security of MLS", Cryptology ePrint Archive, 2021,
<https://eprint.iacr.org/2021/1083.pdf>.
[ACJM20] Alwen, J., Coretti, S., Jost, D., and M. Mularczyk,
"Continuous Group Key Agreement with Active Security",
Cryptology ePrint Archive, 2020,
<https://eprint.iacr.org/2020/752.pdf>.
[AHKM21] Alwen, J., Hartmann, D., Kiltz, E., and M. Mularczyk,
"Server-Aided Continuous Group Key Agreement", Cryptology
ePrint Archive, 2021,
<https://eprint.iacr.org/2021/1456.pdf>.
[AJM20] Alwen, J., Jost, D., and M. Mularczyk, "On The Insider
Security of MLS", Cryptology ePrint Archive, 2020,
<https://eprint.iacr.org/2020/1327.pdf>.
[BBN19] Bhargavan, K., Beurdouche, B., and P. Naldurg, "Formal
Models and Verified Protocols for Group Messaging: Attacks
and Proofs for IETF MLS", HAL ID hal-02425229, 2019,
<https://inria.hal.science/hal-02425229/document>.
[BBR18] Bhargavan, K., Barnes, R., and E. Rescorla, "TreeKEM:
Asynchronous Decentralized Key Management for Large
Dynamic Groups - A protocol proposal for Messaging Layer
Security (MLS)", HAL ID hal-02425247, 2018,
<https://hal.inria.fr/hal-02425247/file/
treekem+%281%29.pdf>.
[BCK21] Brzuska, C., Cornelissen, E., and K. Kohbrok, "Security
Analysis of the MLS Key Distribution", Cryptology ePrint
Archive, 2021, <https://eprint.iacr.org/2021/137.pdf>.
[CAPBR] Brewer, E. A., "Towards robust distributed systems
(abstract)", Proceedings of the nineteenth annual ACM
symposium on Principles of distributed computing, p. 7,
DOI 10.1145/343477.343502, July 2000,
<https://dl.acm.org/doi/10.1145/343477.343502>.
[CGWZ25] Cremers, C., Günsay, E., Wesselkamp, V., and M. Zhao,
"ETK: External-Operations TreeKEM and the Security of MLS
in RFC 9420", 2025,
<https://eprint.iacr.org/2025/229.pdf>.
[CHK21] Cremers, C., Hale, B., and K. Kohbrok, "The Complexities
of Healing in Secure Group Messaging: Why Cross-Group
Effects Matter", Proceedings of the 30th USENIX Security
Symposium, August 2021,
<https://www.usenix.org/system/files/sec21-cremers.pdf>.
[EXTENSIONS]
Robert, R., "The Messaging Layer Security (MLS)
Extensions", Work in Progress, Internet-Draft, draft-ietf-
mls-extensions-06, 19 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
extensions-06>.
[FEDERATION]
Omara, E. and R. Robert, "The Messaging Layer Security
(MLS) Federation", Work in Progress, Internet-Draft,
draft-ietf-mls-federation-03, 9 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-mls-
federation-03>.
[KT] McMillion, B., "Key Transparency Architecture", Work in
Progress, Internet-Draft, draft-ietf-keytrans-
architecture-03, 25 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-
keytrans-architecture-03>.
[Loopix] Piotrowska, A. M., Hayes, J., Elahi, T., Meiser, S., and
G. Danezis, "The Loopix Anonymity System", Proceedings of
the 26th USENIX Security Symposium, August 2017.
[MASQUE-PROXY]
Schinazi, D., "The MASQUE Proxy", Work in Progress,
Internet-Draft, draft-schinazi-masque-proxy-05, 18
February 2025, <https://datatracker.ietf.org/doc/html/
draft-schinazi-masque-proxy-05>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[Tor] "The Tor Project", <https://torproject.org/>.
[WPB25] Wallez, T., Protzenko, J., and K. Bhargavan, "TreeKEM: A
Modular Machine-Checked Symbolic Security Analysis of
Group Key Agreement in Messaging Layer Security", 2025,
<https://eprint.iacr.org/2025/410.pdf>.
[WPBB22] Wallez, T., Protzenko, J., Beurdouche, B., and K.
Bhargavan, "TreeSync: Authenticated Group Management for
Messaging Layer Security", Cryptology ePrint Archive,
2022, <https://eprint.iacr.org/2022/1732.pdf>.
Richard Barnes
Cisco
Email: rlb@ipv.sx
Katriel Cohn-Gordon
Meta Platforms
Email: me@katriel.co.uk
Cas Cremers
CISPA Helmholtz Center for Information Security
Email: cremers@cispa.de
Britta Hale
Naval Postgraduate School
Email: britta.hale@nps.edu
Albert Kwon
Badge Inc.
Email: kwonalbert@badgeinc.com
Konrad Kohbrok
Phoenix R&D
Email: konrad.kohbrok@datashrine.de
Rohan Mahy
Wire
Email: rohan.mahy@wire.com
Brendan McMillion
Email: brendanmcmillion@gmail.com
Thyla van der Merwe
Email: tjvdmerwe@gmail.com
Jon Millican
Meta Platforms
Email: jmillican@meta.com
Raphael Robert
Phoenix R&D
Email: ietf@raphaelrobert.com
Benjamin Beurdouche
Inria & Mozilla
Email: ietf@beurdouche.com
Eric Rescorla
Email: ekr@rtfm.com
Emad Omara
Email: emad.omara@gmail.com
Srinivas Inguva
Email: singuva@yahoo.com
Alan Duric
Email: alan@duric.net