要約

  • draft-mahy-mls-semiprivatemessage-07 は、非公開のCommitまたはProposalを、群が合意した外部受信者へ限定して渡す形式を提案する。
  • 外部受信者はHPKEからメッセージ鍵、nonce、reuse guard、sender leaf indexを得るが、署名検証は対応するGroupContextを持つ場合に行う。
  • 復号、メンバーと同じ内容、現epochの群状態、送信者認証、受信権限、下流結果は別の証拠である。revision 07は作業中で、Security Considerationsにも未完了事項が残る。

外部の配信サービスがMLS Commitを受け取ったとする。自分のreceiver referenceを見つけ、HPKEの封筒を開き、得た鍵とnonceで共通ciphertextを復号する。paddingも正しく、framed_content_tbs_hashもメンバー側の内容と一致した。

ここまで成功しても、送信者の署名を検証できたとは限らない。

SemiPrivateMessage revision 07 は、その境界を手順の中に残している。外部受信者は encrypted_sender_data を開けないため、sender_leaf_index が受信者用のHPKE材料に含まれる。しかしleaf indexは群の状態にある参照先であり、単独の身分証明ではない。

Semi-privateが減らすのは公開範囲である

RFC 9420 のPublicMessageでhandshakeを送れば、必要のない観測者にも内容が見える。PrivateMessageでは、連合型環境の配信サービスがCommitやProposalを扱えない場合がある。草案は external_receivers をGroupContextに置き、mls_semiprivate_message をProposalとCommit専用にすることで中間を作る。

ただし、一つのleafが対応能力を広告しただけでは使えない。群がwire formatをrequiredにし、現epochの外部受信者リストに少なくとも一つの項目が必要である。capability、群の選択、実際の処理は三つの状態だ。

送信者は外部受信者ごとに HPKE を使い、鍵、nonce、reuse guard、leaf indexを包む。そのcontextにはgroup ID、epoch、leaf indexとnonceのhashが入る。外部受信者はこれを開いて、メンバーと共通のhandshake ciphertextを復号する。

同一内容の証明と送信元の証明

framed_content_tbs_hash は、送信者がメンバーと外部受信者へ違う FramedContentTBS を密かに渡すことを検出する。重要だが、範囲は限定される。

受領結果 証明すること 証明しないこと
receiver reference一致 対象descriptor用の項目がある 現epochでも認可されている
HPKE成功 対象private keyが材料を開いた MLS送信者の本人性
AEAD成功 ciphertextとAADが完全である GroupContextの新鮮さ
content hash一致 内外が同じ内容を見る その内容を適用したこと
署名成功 使用した群状態に対して送信者が正しい 外部サービスの実行権限
下流receipt 特定処理が起きた 全メンバーの収束

草案は外部受信者がGroupContextのcopyを持つ場合に署名を検証すると書く。したがって実装には「復号済み、内容一致、認証保留」という状態が必要だ。context不在は署名失敗ではない。署名成功も受信委任ではない。

GroupContextには来歴が必要だ

サービスがepoch Nのcontextを保持したままN+1のmessageを受け取ることがある。リストから外された後も古いprivate keyを持てる。同じleaf番号のcredentialが交換されることもある。group IDとepochの暗号的bindingは単純な移植を防ぐが、完全なGroupContextの配送、保存期限、認可の継続を証明しない。

外部受信receiptにはprotocol version、wire format、group ID、epoch、GroupContext digestと取得元・取得時刻、受信者descriptor・credential・public keyのdigest、追加を承認した主体、HPKE結果、leaf index、content hash、署名の 未実行/成功/失敗、検証credential、local policy、下流結果を残すべきだ。

見えるリストは統治面でもある

受信者リストはGroupContextの一部なのでメンバーに見える。PublicMessageより露出を減らしながら、誰がhandshakeを読めるかは群が確認できる。しかし、誰が追加を提案し、どの規則で承認し、削除後に古い鍵とcontextをどう扱うかは暗号処理だけでは決まらない。

The Policy Mirror の規律を使えば、技術リストが権限になる地点でactor、rule、scope、consequenceを記録する。extensionはリストの表現であり、権限の発生源ではない。

未完成という事実も公開情報である

revision 07は個人Internet-Draftで、IANA値はまだTBDである。IANA MLS registry はplaceholderをassignmentに変えず、RFC 8126 もsoftwareを承認しない。

さらにSecurity Considerationsは、PublicMessageよりprivateであることとリストが見えることを述べた後、TODO More Security を残している。この不確実性を消してはならない。試験はできるが、完成したsecurity analysisとして販売できない。

情報源