Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
64
Secure Messaging at IETF 118
sylph01
February 05, 2024
Tweet
Share
More Decks by sylph01
See All by sylph01
Everyone Now Understands AuthZ/AuthN and Encryption Perfectly and I'm Gonna Lose My Job
sylph01
1
6
Updates on PicoRuby Networking, HPKE (and maybe more)
sylph01
1
190
Adding Security to Microcontroller Ruby
sylph01
2
3.1k
Adventures in the Dungeons of OpenSSL
sylph01
0
470
Community & RubyKaigi Showcase @ Ehime.rb Reboot Meetup
sylph01
0
290
Build and Learn Rails Authentication
sylph01
8
2k
Email, Messaging, and Self-Sovereign Identity (2021/05/28 edition)
sylph01
0
270
DNS Encryption and Its Controversies
sylph01
0
710
Email, Messaging, and SSI/DID (再放送)
sylph01
0
1.4k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
GitHub's CSS Performance
jonrohan
1030
460k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
4 Signs Your Business is Dying
shpigford
181
21k
The Invisible Side of Design
smashingmag
298
50k
[RailsConf 2023] Rails as a piece of cake
palkan
52
5k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
1
200
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.1k
Statistics for Hackers
jakevdp
796
220k
It's Worth the Effort
3n
183
27k
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