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.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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.
著作権（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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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は、完全なインスタントメッセージングプロトコルとしては意図されていませんが、拡張可能なメッセージングおよびプレゼンスプロトコル（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つのクライアントと同じくらい小さい（単純な人から人へのメッセージングなど）、または数十万人のクライアントが多い場合があります。グループの一部であるクライアントは、そのグループの_member_です。グループがメンバーシップとグループまたはメンバーのプロパティを変更すると、1つの_EPOCH_から別の_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_は、パブリック暗号化キーと署名キー（両方ともキーパッケージのリーフノードオブジェクトに保存されている）など、クライアントをグループに追加するために使用できるキーを提供します。_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.
* Authentication Service（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によってグループ内の各受信者に転送されます。DSは、MLSプロトコルの一部であるGroup Secret Keyの設立を進めるために、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は証明書の発行および検証プロセスを構成します。
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に送信します。これは、適切な人に送信する責任があります。MLSのセキュリティは、彼のために暗号化されているため、歓迎メッセージをボブに転送するDSに依存しないことに注意してください。他のグループメンバーがそれを受け取る必要はありません。
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つ以上の提案を含むコミットを送信することです。たとえば、アリスは、グループに追加するためにボブを追加するために埋め込まれた提案（ボブ）でコミットを送ることができます。ただし、1人のクライアントが提案を送信する状況があり、別のクライアントが対応するコミットを送信する可能性があります。たとえば、ボブはグループから自分自身を削除し、そうするための削除提案を送信したいかもしれません（[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のグループは、グループキー設立段階で確立された共有グループの秘密の知識を持つクライアントのセットとして定義されます。クライアントがグループに追加され、グループの他のメンバーが検証可能な方法でグループシークレットに貢献するまで、他のメンバーはクライアントがグループのメンバーであると想定できないことに注意してください。たとえば、新しく追加されたメンバーは、歓迎メッセージを受け取っていないか、何らかの理由でそれを解読できなかった可能性があります。
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は[RFC5280]としてASとして使用できます。発行機能は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]に基づくシステムでは、発行機能は、ユーザーのIDの下で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でかなり柔軟です。上記のように、特定のユーザーに属するすべてのクライアントが同じ署名キーを持っているという要件はありません（実際、グループに署名キーを重複させることは禁止されています）。メンバーは、グループ内で使用する署名キーを回転させることもできます。これらのメカニズムにより、クライアントはさまざまなコンテキストとさまざまな時点で異なる署名キーを使用し、非難と競争後のセキュリティ給付を提供することができます。この柔軟性に関連するいくつかのセキュリティトレードオフについては、セクション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クライアントがあります。多くの場合、同じクライアントのセットがグループのまったく同じリストで表されます。これが意図した状況であるアプリケーションでは、他のクライアントがユーザーが同じクライアントのセットによって一貫して表現されていることを確認できます。これにより、ユーザーがメンバーであるすべてのグループに資格情報が表示されることをクライアントが期待するため、特定のユーザーに偽の資格情報を発行することは悪意のある人にとってより困難になります。クライアントの資格が比較的短期間の後にすべてのグループに表示されない場合、クライアントは、ユーザーの知識なしに資格情報が作成された可能性があるという兆候を持っています。ただし、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に保存します。キーパッケージと呼ばれるこの重要な資料は、クライアントの機能的能力（サポートされているプロトコルバージョン、サポートされている拡張など）および次の暗号化情報を宣伝します。
* A credential from the AS attesting to the binding between the identity and the client's signature key.
* アイデンティティとクライアントの署名キーとの間のバインディングを証明することからの資格。
* 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.
キーパッケージ内のすべてのパラメーターは、資格情報に対応する署名の秘密鍵で署名されます。セクション3.7で述べたように、ユーザーは複数のクライアントを所有する場合があります。各キーパッケージはMLSバージョンと暗号スイートに固有ですが、クライアントは複数のプロトコルバージョンと暗号スイートのサポートを提供したい場合があります。そのため、プロトコルバージョン、暗号スイート、エンドユーザーデバイスの組み合わせのために、各ユーザーが保存する複数のキーパッケージが存在する場合があります。
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に連絡して他の各クライアントのキーパッケージを要求し、署名キーを使用してキーパッケージを認証し、追加提案にキーパッケージを含み、グループに参加するために必要な情報を暗号化します（_GroupINFO_オブジェクト）。次に、各キーパッケージのパブリック暗号化キー（init_key）を使用して、はかないキーを個別に暗号化します。クライアントがユーザーをグループに追加するためにキーパッケージを要求する場合、DSはリクエストを満たすために必要な最小数のキーパッケージを提供する必要があります。たとえば、リクエストがMLSバージョンを指定した場合、DSは、より多くの新鮮なキーパッケージをアップロードする必要がある前に、対応するクライアントを複数のグループに追加できるように複数のこのようなキーパッケージがある場合でも、サポートされているCipherスイートごとに1つのキーパッケージを提供できます。
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.
リプレイ攻撃を回避し、最初のキーイング素材を使用して送信されたメッセージの前向きな秘密を提供するために、キーパッケージは一度だけ使用することを目的としており、init_keyは歓迎メッセージの復号化後にクライアントによって削除されることを目的としています。DSは、各キーパッケージがクライアントを単一のグループに追加するためにのみ使用されることを保証する責任があります。クライアントは、「最後のリゾート」キーパッケージが使用される可能性を最小限に抑えるために、必要に応じて新しいキーパッケージを提供する責任があります。
*Recommendation:* Ensure that "last resort" KeyPackages don't get used by provisioning enough standard KeyPackages.
*推奨：*十分な標準キーパッケージをプロビジョニングしても、「最後のリゾート」キーパッケージが使用されないようにしてください。
*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.
*推奨事項：*使用された後、または長期間保管されている場合は、できるだけ早く「最後のリゾート」を回転させます。全体として、「Last Resort」のキーパッケージを可能な限り再利用しないでください。
*Recommendation:* Ensure that the client for which a "last resort" KeyPackage has been used is updating leaf keys as early as possible.
*推奨：*「最後のリゾート」キーパッケージが使用されているクライアントが、できるだけ早く葉のキーを更新していることを確認してください。
*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.
*推奨：*ウェルカムメッセージを処理した後、または「最後のリゾート」キーパッケージの回転後に、クライアントがinit_keyのプライベートコンポーネントを削除することを確認してください。
Overall, it needs to be noted that key packages need to be updated when signature keys are changed.
全体として、署名キーが変更されたときにキーパッケージを更新する必要があることに注意する必要があります。
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メッセージは、特定のクライアントにのみ配信する必要があります（たとえば、新しいメンバーの状態を初期化するウェルカムメッセージ）、他のメッセージはグループのすべてのメンバーに配信する必要があります。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つの例外があります。まず、提案メッセージはすべて、それらを参照するコミットの前に到着する必要があります。第二に、MLSグループにはエポックの線形履歴があるため、グループのメンバーは、変更が適用される順序に同意する必要があります。具体的には、グループは各エポックを終了し、次のエポックを開始する単一のMLSコミットメッセージに同意する必要があります。
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人のメンバーが同時にコミットメッセージを生成するという現実的なリスクがあり、どちらも同時にグループに送信しようとしています。これが問題であり、適切な解決策は、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.
* 一貫性があり、パーティションに耐える、または強く一貫したシステムは、データのグローバルに一貫した見解を提供できますが、拒否されたメッセージを処理する必要があるクライアントに不便を持っています。
* Available and Partition-tolerant, or Eventually Consistent, systems, which continue working despite network issues but may return different views of data to different users.
* ネットワークの問題にもかかわらず動作し続けるが、異なるユーザーに異なるデータを返す可能性がある、利用可能でパーティショントレラント、または最終的に一貫したシステム。
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つのサブセクションで、強くかつ最終的に一貫したシステムでメッセージをシーケンスするための戦略が説明されています。ほとんどのDSSは強く一貫したパラダイムを使用しますが、これはクライアントと連携して処理され、キーパッケージで宣伝される選択肢のままです。
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メッセージの「生成」カウンターは、DSで操作できないセンダーごとの損失検出と順序付けを提供しますが、これはパーティション化に対する完全な保護を提供しません。DSは、キー交換メッセージをパーティション化することにより、グループ内のパーティションを引き起こす可能性があります。これは、帯域外の比較によってのみ検出できます（たとえば、すべてのクライアントが同じepoch_authenticator値を持っていることを確認してください）。より堅牢な保護のメカニズムについては、[拡張]で説明します。
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人のメンバーが同時にコミットメッセージを送信するときにネクタイを破ると信頼されています。
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がある可能性があります。これにより、クライアントはエポックに最初の有効なコミットを適用し、その後のコミットを無視することができます。コミットを送信するクライアントは、最初に別のコミットを受け取らないと仮定して、配達サービスによって放送されるまでそれを適用するのを待ちます。
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フィールドに依存して、メッセージのみを握手するために注文を提供することができ、おそらく冗長なコミットメッセージを積極的にフィルタリングまたは拒否して、それらが放送されないようにすることもできます。フィルタリングに関連するリスクがあります。これについては、セクション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は、強く一貫したシステムよりもはるかに利用可能またはパフォーマンスが高い方法で構築されていますが、一貫性の保証が弱い場合です。メッセージは、さまざまな注文でさまざまなクライアントに届き、さまざまなレイテンシで届く場合があります。これは、クライアントが和解に責任を負うことを意味します。
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からコミットを受けると、クライアントは次のとおりです。
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. 合理的な程度のネットワーク遅延を考慮して、同じエポックのために他のコミットが受け取られているかどうかを確認するために、新しいメッセージを短時間送信する一時停止します。複数のコミットを受け取った場合、クライアントは決定論的なタイブレークポリシーを使用して、どちらを受け入れるかを決定し、通常どおりメッセージを送信することができます。
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. すぐにコミットを受け入れますが、以前のグループ状態のコピーを短時間保管してください。過去のエポックに対する別のコミットを受け取った場合、クライアントは決定論的なタイブレイクポリシーを使用して、最初に受け入れたか、戻って後のコミットを使用して使用する必要があるかどうかを決定します。プロトコルが前向きな秘密を提供することを確認するために、以前またはフォークされたグループ状態のコピーは、合理的な時間内に削除する必要があることに注意してください。
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.
コミットが未知の提案を参照する場合、グループメンバーは提案の内容について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.
コミットが新しいメンバーをグループに追加するたびに、MLSはコミッターに新しいメンバーにウェルカムメッセージを送信する必要があります。アプリケーションは、歓迎メッセージがコミットのためのタイブレイクロジックと結びついていることを確認する必要があります（セクション5.2.1および5.2.2を参照）。つまり、複数のコミットが同じエポックに送信される場合、アプリケーションは、「成功した」というコミットに対応する歓迎メッセージのみが新しいメンバーによって処理されることを確認する必要があります。
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.
これは、グループが再初期化されている場合に特に重要です。グループが再活性化されると、異なるプロトコルバージョンおよび/または暗号スイートが同一のメンバーシップで再起動されます。許可されたメンバーがリネットの提案を送信してコミットするたびに、これは既存のグループをすぐにフリーズし、新しい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の提案をコミットしたのと同じメンバーによって作成されます（以前のグループのすべてのメンバーに新しいグループの歓迎メッセージを送信することを含む）。ただし、この操作は常にアトミックではないため、Reinit Proposalをコミットしてから新しいグループを作成する前に、メンバーがオフラインになる可能性があります。これが発生した場合、新しいグループを作成して歓迎メッセージを送信することにより、別のメンバーが再初期化を継続する必要があります。
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.
これには、複数のメンバーが同時に再初期化を継続しようとする人種条件を作成する可能性があり、メンバーは同じグループを再初期化する試みごとに複数の歓迎メッセージを受け取ります。すべてのメンバーが、どの再初期化の試みが「正しい」かについて同意することを保証することが、これがフォークを引き起こすのを防ぐための鍵です。
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].
悪意のあるクライアントやバギーのクライアントがグループのすべてのメンバーに受け入れられないコミットを送信する場合、DSはこれを検出してコミットを拒否することができない状況が発生する可能性があります。たとえば、バギークライアントは、無効な一連の提案で暗号化されたコミットを送信したり、悪意のあるクライアントが[RFC9420]のセクション16.12で説明したフォームの不正なコミットを送信する場合があります。
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が冗長コミットをフィルタリングしようとしている状況では、DSは、コミットが成功したという仮定の下で内部状態を更新し、グループのメンバーと矛盾する状態になる可能性があります。たとえば、DSは、現在のエポックは現在N+1であり、他のエポックからコミットを拒否していると考えるかもしれませんが、メンバーはエポックがNであると考え、その結果、グループは立ち往生しています。メンバーはDSが受け入れるコミットを送信できません。
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がエポックに対して「正しい」コミットが「正しい」という姿勢を取らない場合でも発生する可能性があります。DSは、たとえば、受け取った注文でコミットを提供し、クライアントがグループのポリシーの見解に違反するコミットを拒否できるようにすることにより、クライアントがコミットを選択できるようにすることができます。そのため、正直で正確に実装されたすべてのクライアントは、同じ「最初の有効なコミット」に到着し、それを処理することを選択します。異なるコミットを処理する悪意のあるまたはバギーのクライアントは、グループのフォークされたビューになります。
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.
これらの非同期化が発生した場合、アプリケーションはグループの機能を復元するためのアクションを実行することを選択できます。これらのアクション自体は、セキュリティに影響を与える可能性があります。たとえば、クライアント開発者は、クライアントが無効なコミットを処理するときに外部結合を使用してグループに自動的に再参加する可能性があります。ただし、この操作では、クライアントは、DSによって提供されたGroupInfoがグループの状態を忠実に表していることを信頼しており、たとえば、葉のノードを含む以前の状態ではありません。さらに、DSは、被害者に無効なコミットを故意に送ることにより、この状態をトリガーできる場合があります。特定のシナリオでは、この信頼により、DSまたは悪意のあるインサイダーがMLSが提供する競合後のセキュリティ保証を損なうことができます。
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の意味合いも持つことができます。たとえば、回復メカニズムが外部結合に依存している場合、無効なコミットを意図的に投稿する悪意のあるメンバーは、被害者がグループに再び参加するのを防ぐために、破損した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つのメカニズムを提供します。主なメカニズムは、グループの認定メンバーが他のメンバーを追加または削除するコミットを送信することです。二次メカニズムは「外部結合」です。グループのメンバーは、グループに関する特定の情報を公開します。新しいメンバーは、新しいメンバーをグループに追加する「外部」コミットメッセージを作成するために使用できます。（メンバーがグループを去るための同様に一方的な方法はありません。彼らは残りのメンバーによって削除されなければなりません。）
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.
両方のタイプの結合は、DSによってブロックされるか、参加が許可されていない場合にクライアントによって拒否される可能性があるコミットメッセージを介して行われます。前者のアプローチでは、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保証を強化しません。たとえば、デバイスの妥協に続く特定のグループ内の重要な更新は、他のグループでPCの治癒を提供しません。これらのセキュリティ目標を達成するには、各グループを個別に更新する必要があります。これは、メンバーがまだ参加していない将来のグループにも適用されます。これは、現在のグループで実行される更新の影響を受けません。
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は、並列グループ間で治癒特性をリンクするために使用できる、事前に共有キー（PSK）メカニズムを提供します。たとえば、2つのグループAとBの一般的なメンバーMがグループAでキーアップデートを実行したが、グループBではキーアップデートを実行したと仮定します。キーアップデートはグループAのMに関してPCを提供します。PSKがグループAからエクスポートされ、グループBに注入された場合、これらのPCSプロパティの一部はグループBに引き継がれます。
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クライアントを管理するアプリケーションは、特定のグループ操作を可能にするように構成できます。一方で、アプリケーションは、グループ管理者が操作を追加および削除する唯一のメンバーになることを決定できます。一方、オープンディスカッションフォーラムなどの多くの設定では、誰にでも参加することができます。
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およびPCの保証を減らす場合があります。
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プロトコルは、追加情報を提供できるいくつかの拡張ポイントを提供します。キーパッケージへの拡張により、クライアントはその機能に関する追加情報を開示できます。グループには拡張データに関連付けられた拡張データも持つことができ、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を使用する各アプリケーションは、Application_Dataの形式と、MLSグループの寿命にわたってそのコンテンツの形式を決定するために必要なメカニズムを定義する必要があります。多くのアプリケーションでは、これは、予測不可能な時期にそれぞれオフラインになる可能性のある複数のメンバーを持つグループの形式移行を管理することを意味します。
*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の適用に対してより適切に対処する別のメカニズムを定義しない限り、[拡張]で定義されたコンテンツメカニズムを使用します。
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実装が相互運用して、互換性のある認証メカニズム、暗号スイート、アプリケーションコンテンツ、およびインフラストラクチャ機能を使用する場合、フェデレートシステムを形成できます。フェデレーションについては、[フェデレーション]で詳しく説明しています。
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つの展開の場合、これらの各カテゴリでサポートが重複する必要があります。必要な_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で完全に説明されている *認証サービス *は、展開で使用できる資格情報の種類を定義し、次の方法を提供します。
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で完全に説明されている *配送サービス *は、次の方法を提供します。
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）ユーザーを招待するときに歓迎のメッセージで完全な公共の状態を送信することができない（1）（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.
- アプリケーションがグループのメンバーがアクセスできない場合（たとえば、セクション6.6で説明したように、グループへの参入を制御したり、過去にグループのメンバーシップを証明するために）PSKを使用している場合、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.
- クライアントが1つのメッセージを拒否する前に、クライアントが秘密のツリーラチェットを1つのメッセージに応じて前方に移動する最大数のステップ。
- 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.
* グループに必要な_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.
さらに、これらの保証は、このセクションの残りの部分で説明されているように、輸送セキュリティリンクとメッセージングシステムのクライアントと要素の両方の妥協の存在下で優雅に分解することを目的としています。
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は、アプリケーションに認証された「追加の認証データ」（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.
PCは、グループメンバーの状態がいつかT1で侵害されているが、グループメンバーがいつかT2で更新を実行する場合、すべてのMLS保証は、時間T2の後にメンバーが送信したメッセージと、更新を処理した後に他のメンバーから送信されたメッセージに適用されることを意味します。たとえば、攻撃者がアリスの長期シークレットキーとすべての共有グループキーの両方を含むアリスに知られているすべての秘密を学習した場合、アリスは時間T2でキーアップデートを実行します。
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].
これらの特性は両方とも、キーの透明度[KT]など、キーを検証する他のメカニズムが使用されている場合において、妥協したDSSおよびASEに対しても満たされています。
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とPCは、キーイングマテリアルの積極的な削除と交換に依存しているため、オフラインで持続的に持続的なクライアントはまだ古いキーイング素材を保持しているため、後で侵害された場合、FSとPCの両方にとって脅威になる可能性があります。
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は、これらの両方のユースケースをサポートしています。一部の展開では、これらのサービスは、受信者がメッセージの起源を第三者に証明できるメカニズムによって提供されます。これはしばしば「非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.
大まかに言えば、「否定性」は「非和解」の反対です。つまり、特定の送信者によってメッセージが送信されたことを第三者に証明することが不可能であるというプロパティです。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キーからラチェットの秘密を計算することはできません。
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キーとノンセスのチェーンの外で、_Other_ MLSクライアント向けに生成された他のすべてのAEADキーの秘密も保持します。MLSは、AEAD暗号化のためにエポックを横切るアクティブな適応攻撃者に対して、競合後のセキュリティを提供します。つまり、エポックが変更されるとすぐに、攻撃者がより多くの秘密の素材にアクセスできない場合、将来のエポックから保護されたメッセージにアクセスできません。
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プロパティから予想されます。妥協した当事者が妥協を改善し、正直なコミットメッセージを送信するとすぐに、次のエポックはメッセージの秘密を提供します。
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は、削除グループ操作を通じて、アクティブな適応攻撃者に対してPCを提供します。これは、グループの他のメンバーが正直である限り、プロトコルは、侵害された当事者が削除された後、エポックで交換されたすべてのメッセージに対してメッセージの秘密を保証することを意味します。
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.
署名キーの値にアクセスすることと、署名のOracleにのみアクセスすることのみの違いは、妥協時にアクティブな適応ネットワーク攻撃者が異なる操作を実行する能力ではありません。攻撃者は、どちらの場合も合法的なクライアントが利用できるすべての操作を実行できます。
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保証のため、以前に侵害されたクライアントが妥協から回復し、正直なコミットを実行すると、攻撃者がそうでなければキーにアクセスできない限り、将来のメッセージの秘密と認証の両方を回復できます。敵は署名キーを持っていないため、グループの他のメンバーと共謀してグループキーをまだコントロールしていても、妥協した当事者に代わってメッセージを認証することはできません。
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.
Oracleと秘密のキーアクセスの両方で、アクティブな適応攻撃者がプロトコルに従い、独自の資格情報を更新するよう要求できることに注意してください。これにより、署名キーの回転が誘導され、サービスプロバイダーのアーキテクチャに応じて、攻撃者に秘密鍵の一部または完全な値を提供できます。
*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.
*推奨事項：*メッセージがデバイスに保存されている場合、それらは安静時に暗号化を使用して保護する必要があり、使用するキーはデバイス上の専用メカニズムを使用して安全に保存する必要があります。
*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.
安全な飛び地が完全に安全でなく、完全に壊れている場合でも、これらのキーに追加の保護を採用すると、妥協後の秘密と認証の保証の回復を容易にすることができます。特定のコンテキストでは、資格情報の回転は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.
*推奨事項：*プライバシーまたは匿名性が重要な場合、QUIC暗号化（マスク）[マスクプロキシ]、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.
機能性のために、個人データまたはメタデータをサーバーに持続する必要がある場合（アイデンティティとプッシュトークン、グループメタデータなどのマッピング）、安静時に暗号化され、実行中に必要な場合にのみ保存する必要があります。正直なサービスプロバイダーは、そのような「安静時の暗号化」メカニズムに依存して、使用しないときにデータへのアクセスを防ぐことができます。
*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は、Total 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が妥協後のセキュリティを限られた範囲で攻撃することを可能にします。この脅威は、初期キーを期限切れにすることで軽減できます。
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.
基本的な資格情報タイプを使用した初期キーイング材料（キーパッケージ）は、クライアントのアイデンティティと公開鍵の間に組み込みの暗号化結合がないため、悪意のあるまたは侵害された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).
*推奨事項：*アイデンティティとそのキーの間に強い暗号化結合を含むキーパッケージの資格型を好む（たとえば、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