Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Secure Messaging at IETF 118
Search
sylph01
February 05, 2024
0
96
Secure Messaging at IETF 118
sylph01
February 05, 2024
Tweet
Share
More Decks by sylph01
See All by sylph01
End-to-End Encryption Saves Lives. You Can Start Saving Lives With Ruby, Too
sylph01
1
70
End-to-End Encryption Saves Lives. You Can Start Saving Lives With Ruby, Too (JP subtitles)
sylph01
2
190
Introduction to C Extensions
sylph01
3
170
"Actual" Security in Microcontroller Ruby!?
sylph01
0
120
Everyone Now Understands AuthZ/AuthN and Encryption Perfectly and I'm Gonna Lose My Job
sylph01
1
48
Updates on PicoRuby Networking, HPKE (and maybe more)
sylph01
1
270
Adding Security to Microcontroller Ruby
sylph01
3
3.4k
Adventures in the Dungeons of OpenSSL
sylph01
0
580
Community & RubyKaigi Showcase @ Ehime.rb Reboot Meetup
sylph01
0
340
Featured
See All Featured
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Designing for Performance
lara
608
69k
Practical Orchestrator
shlominoach
186
11k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
The World Runs on Bad Software
bkeepers
PRO
67
11k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Thoughts on Productivity
jonyablonski
69
4.6k
What's in a price? How to price your products and services
michaelherold
245
12k
Automating Front-end Workflow
addyosmani
1369
200k
Adopting Sorbet at Scale
ufuk
76
9.3k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
2.9k
Transcript
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