Secure Messaging @ IETF118 Ryo Kajiwara, 2024/02/05 1

過去の内容について 特にMessaging Layer Securityについて過去に何度か発表・報告している 内容について、RFC9420では大幅に変更が入っています。 今でも通用する内容 問題空間: 2-partyでのgroup keyingは容易、3+-partyでは困難 Protocol Overview (Chapter 3) 実装について、Ratchet Treeを使う点は保たれている 変更されている内容 Merkle Trees、TreeKEMは使われていない 2

MLSとMIMI Messaging Layer Security グループ鍵共有のためのプロトコル。 End-to-End暗号化をど うやるか、の層 MIMIをやるための大前提 MLS Protocol (RFC 9420): どのようなメッセージをやりとりして グループの鍵の状態を揃えるか MLS Architecture (I-D): MLSで利用されるサービスの定義、セキ ュリティ上のゴールの定義 3

MLSとMIMI More Instant Messaging Interoperability (MIMI) MLSがあった上で、以下の問題を解決することを目指す アイデンティティ技術(X.509証明書、Verifiable Credential) を使ってメッセージングサービス間でのend-to-endでのア イデンティティの確立 あるアプリケーションでのアイデンティティを使って他の アプリケーションでの操作権限を得る(introduction problem) メッセージングの最低限の共通機能セット 4

どこから読む？ だいたいのI-Dにおいてどのような問題を解決しようとしているか を知るには RFC 9420 (MLS Protocol)のChapter 3まで をまず読むの がよい 暗号の詳細には踏み入らない。これはChapter 5以降 ツリーの操作の詳細にも踏み入らない。これはChapter 4 今回はChapter 4以降の詳細には可能な限り踏み入りません 5

6

MLS Working Group 7

Rechartering RFC 9420が出たのでそれをcharterに反映する必要があるよね (by AD) extensionsで何をやるかの定義 いつまでにextensions documentを終了させる？ TLS, SIP(, oauth) ...は永遠にやってるけどanti-pattern good extensionsは何かのcriteriaを明記したい extensionにはsecurity analysisが必要と明記 8

MLS Architecture 現状: -10時点ではNot Readyのreviewが出ている、7月からupdateさ れていない、IESG Evaluation: AD Followupのstate 話されたissue Encrypted Group Operationsについて、MIMIとの整合性 MLS handshakeはMLS PublicMessageで暗号化なしで送る ことができて、中間者がポリシー適用などの目的で使うこ とができるが、暗号化しないことによるプライバシー上の 注意を記述する必要がある 9

MLS Extensions Safe Extensions extensionとMLS Protocol間のAPIセットの定義 暗号操作について、main protocolのkeying materialの利用、シ ークレットのエクスポート、PSKの注入の3つのみを許可 extension IDでドメイン分離が行われる 10

MLS Extensions User Trees 1ユーザーが複数デバイスを持つときに、それぞれのデバイス がツリーに直接鍵を持つのではなく、ユーザーをツリーの末端 ノードとして、そこにsub-treeを生やしてデバイスを管理する デバイスの出入りによって全体のツリーにblankが発生するこ とを防ぎ、groupが小さくなることで効率がよくなる 11

SelfRemove proposal 自分自身をgroupから除外するproposal 自分自身のremoveのatomic性を担保できない 12

draft-mahy-kp-context KeyPackageが特定のコンテキストのみで利用されるべきことを示 す拡張 contextを無視して使ってしまうことができるのでは？ このextensionに対応していなかったり無視したらアクセスコ ントロールとしての性質が破綻しそう？ 13

14

MIMI Working Group 15

MIMI Architecture Client-Server-Server-Server-Client Model 全ての通信はハブサーバーを通る 用語 room: MIMIの機能の実行単位 participants: ユーザーの表現 clients: MLS groupのメンバーとしての表現 active/inactive: ユーザーのclientが1以上か否か 16

MIMI Architecture Roomのstate Authorization Policy, Participation List, MLS Groupを持つ Participant Listからユーザーを除外するためには、該当のユー ザーが持つclientがMLS Groupからすべて除外されている必要が ある。その間の状態管理はMIMIの仕事 まだMIMIのドキュメント間で用語の統一が取れていない 17

MIMI Content Format 現時点で唯一WG Documentになっている。 attachments テキストベースのものをバイナリベースにした big file problem vs privacy problem ファイルを外置きにしたらHTTPアクセスが発生し該当の サーバーがどのクライアントからのアクセスかわかってし まいprivacy problem、だが巨大なファイルを暗号化してグ ループに流すのもよくない、どうしよう メッセージの順序の安定化: lastSeen フィールドの利用 18

今後どうする (design team report) 4つの文書を核にする MIMI Architecture MIMI Message Content MIMI Delivery Service generic MLS DSとしてのMIMI DSの定義、MIMIの機能と MLS DSの対応付け MIMI Format MIMI Protocolはroom-level operationを扱い、MLS Groupの扱いはDSが行 う 19