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
74
Secure Messaging at IETF 118
sylph01
February 05, 2024
Tweet
Share
More Decks by sylph01
See All by sylph01
"Actual" Security in Microcontroller Ruby!?
sylph01
0
66
Everyone Now Understands AuthZ/AuthN and Encryption Perfectly and I'm Gonna Lose My Job
sylph01
1
13
Updates on PicoRuby Networking, HPKE (and maybe more)
sylph01
1
210
Adding Security to Microcontroller Ruby
sylph01
2
3.2k
Adventures in the Dungeons of OpenSSL
sylph01
0
480
Community & RubyKaigi Showcase @ Ehime.rb Reboot Meetup
sylph01
0
300
Build and Learn Rails Authentication
sylph01
8
2k
Email, Messaging, and Self-Sovereign Identity (2021/05/28 edition)
sylph01
0
280
DNS Encryption and Its Controversies
sylph01
0
720
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
44
13k
How STYLIGHT went responsive
nonsquared
96
5.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
810
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7k
Why Our Code Smells
bkeepers
PRO
335
57k
YesSQL, Process and Tooling at Scale
rocio
169
14k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
66k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
1
100
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