要約

  • 9月5日のMOQT Discovery第01版は、URIの正規化とX.509証明書照合を新設した。続く第02版の変更は、ソースリポジトリへのリンク訂正だけだった。
  • SVCBやSRVで別ホストへ接続しても、証明書は元のmoqt URIのauthorityで検証する。この規則は明快だが、mDNSで閲覧した_moqt._udp広告が、どのように信頼済みの元URIと広告資格を得るのかは未記述で、Security ConsiderationsもTODOのままだ。

イベント会場の無線LANに入ると、配信アプリにリレーが一台表示されたとする。PTRがインスタンスを列挙し、SRVがホストとポートを示し、TXTにはalpn=moqtがある。これは接続候補を作るには十分だ。しかし、会場が運用するリレーなのか、同じリンクにいる別の端末なのかは分からない。

Datatrackerの記録では、現行版は2026年9月5日付の第02版である。文書名は個人Internet-Draftのままで、IETF streamもintended standard levelも設定されていない。本文冒頭はStandards Trackを意図し、議論先をMedia over QUICメーリングリストとするが、ワーキンググループ採択や合意、承認を意味しない。

差分をたどるとニュースの範囲が見える。第00版は8月に三つの発見経路を示した。第01版は9月5日、URI正規化と証明書照合を追加した。その後の第02版はGitHub URLだけを直した。I-D告知は、完成した標準や実装の発表ではなく、身元規則が具体化した作業文書の更新である。

DNSが選んだ機械は、サービスの名前を奪えない

草案は、ネイティブQUICにSVCB、WebTransportにHTTPS、フォールバックにSRVを割り当てる。SVCB/HTTPSはALPNなどの接続情報を持てるが、SRVはターゲットとポートだけを伝える。利用可能な候補を受け取ったクライアントは、返された機械へ接続する。

第01版が守るのは、その次の判断だ。TLS SNIと証明書照合には、解決されたターゲットではなく元のmoqt URIホストを使う。DNSの中間値はパケットの行き先を変えられるが、相手の身元を再定義できない。

これはRFC 9460のSVCB/HTTPS原則と一致する。代替エンドポイントはorigin authorityを変えない。RFC 9525も、reference identifierを安全な入力または設定から組み立て、DNS解決中の名前を無条件に昇格させないよう求める。

新設部は比較方法まで限定した。RFC 3986に沿って大文字小文字とパーセント符号化を整え、ポート省略時は443を加え、末尾のドットを取り、国際化ドメインをRFC 5890のIDNAへ変換する。ワイルドカードとCN-IDは使わず、DNS、IP、URI、およびRFC 4985のSRVNameをsubjectAltName候補とする。

ただし、この強い規則は元URIが先にある場合に働く。ローカルのサービス一覧から始める利用者には、検証基準となるURIを誰が与えたのかという前段が必要だ。

同じリンクにいることは、同じ組織に属することではない

mDNS経路では、リレーが.localにPTR、SRV、TXTを出し、認識可能なALPNを広告する。RFC 6762の送信元とIP TTLの確認は、応答がローカルリンク外から偽装された可能性を減らす。リンク内にいる敵対的な端末は排除しない。

同RFCは、中央権限のない環境で協力的な参加者を前提に名前衝突を解く、と明記する。.local名にはグローバルな権威がなく、信頼できないネットワークではエンドツーエンド暗号が重要だ。RFC 6763はDNS-SDのレコード構成を定め、真正性が重要ならDNSSECを勧めるが、サービスを広告する組織上の権限までは発行しない。

現行MOQT DiscoveryのSecurity ConsiderationsはTODO一語である。閲覧したサービスインスタンスから証明書検証用の元moqt URIをどう得るか、広告者をどのポリシーで認めるかも定義されていない。事前設定、証明書ピンニング、署名付き発見ドメイン、利用者確認などを製品が採用することはできる。それは現草案がすでに決めた事実ではない。

未完成は脆弱性の証明ではない。Internet-Draftが未解決点を見せるのは正常だ。実装側がしてはいけないのは、候補発見を権限付与として扱うことだ。

TLSの成功とメディアの権利は別々に残る

MOQT Transport第20版はQUICまたはWebTransportで通信を保護するが、購読、発行、namespaceの権限はアプリケーションや認可方式に委ねる。証明書が名前に一致しても、会場の代理権、コンテンツ閲覧権、トラック発行権、配信結果までは証明しない。

記録すべき現実は、受信した広告、リンク由来、選択した接続先、構成した元URI、証明書結果、ローカル信頼判断、namespace認可、セッション、受信メディアである。「発見済み」の一項目にまとめれば、最初のレコードが後続すべての権威を借りてしまう。

Lu Hengの最小初期仕様に従えば、共有層は「indirectionはauthorityを変えない」という小さな不変条件を守ればよい。現実の層は広告、身元、認可、結果を分離する。動くコードの優先は、実クライアントがどの名前とポリシーを使ったかを観測させる。

出典

  1. IETF Datatracker記録
  2. MOQT Discovery第02版
  3. 第01版
  4. 第00版
  5. 第02版I-D告知
  6. MOQT Transport第20版
  7. RFC 9460：SVCBとHTTPS
  8. RFC 6762：Multicast DNS
  9. RFC 6763：DNS-Based Service Discovery
  10. RFC 9525：TLSのサービス識別
  11. RFC 4985：SRVName
  12. RFC 3986：URI構文
  13. RFC 5890：IDNA
  14. Lu Heng：最小初期仕様
  15. Lu Heng：現実の層
  16. Lu Heng：動くコードの優先