要約

  • Version Negotiation パケットには、送信者が受け入れると表明するバージョン一覧が入るが、暗号学的には保護されていない。
  • Connection ID の反映は送信者が Initial を見たという限定的な確からしさを与えるだけで、指定サーバーや本番ポリシーを認証しない。
  • 運用証跡では、生のパケット、次の選択、ハンドシェイク内で認証された Version Information を別々に残す必要がある。

互換性ダッシュボードが一つのエッジアドレスに三つの QUIC バージョンを表示している。根拠は一度のキャプチャだ。クライアントが一つを試し、Version Negotiation を受け取り、三つの値を読んだ。そこから「サーバー対応一覧」を作るのは、観測を能力台帳へ飛躍させている。

RFC 9000 §6.1 では、クライアントが選んだバージョンをサーバーが受け入れられない場合、受け入れるバージョンを列挙して応答する。サーバーは接続状態を保持せずに応答でき、送信数を制限してもよい。応答がないことも、完全な非対応一覧にはならない。

形式が作る結び付きは狭い。RFC 9000 §17.2.1 により Version はゼロとなり、応答 DCID はクライアントの SCID を、応答 SCID は Initial の DCID を写す。仕様が述べるのは、送信者が Initial を観測したという「一定の確からしさ」だ。その後ろに32ビットのバージョン値が並ぶ。

Initial を見たことは、サービスとして認証されたことではない。RFC 9000 §12.1 は Version Negotiation に暗号学的保護がないと明記する。経路上の装置も反映に必要な ID を見られる。TLS 証明書、Finished の検証、認証済みトランスポートパラメーターはこのパケットに含まれない。

受信規則は明白な曖昧さを減らすが、証拠の格を上げない。RFC 9000 §6.2 によれば、QUIC v1 だけをサポートするクライアントは、条件を満たす Version Negotiation を受けると現在の接続試行を断念しなければならない。ただし、別のパケットをすでに正常処理した場合と、一覧に当初選んだバージョンが含まれる場合には、その Version Negotiation を破棄する。単純な注入や古い応答への耐性にはなるが、残った一覧を署名済みポリシーに変えるわけではない。

強い証拠はハンドシェイク中に現れる。RFC 9368 §3 は Chosen Version と Available Versions からなる Version Information を、認証された形で双方が交換する仕組みを定義する。QUIC v1 では version_information トランスポートパラメーターを使う。RFC 9368 §9 は、その真正性に安全性が依存し、v1 のトランスポートパラメーターが認証されることを根拠にしている。

必要なのは段階的な証拠だ。Initial はクライアントの試行を示す。保護されない応答は、その文脈で送信者が掲げた値を示す。次の Initial は新しい選択を示す。認証済みハンドシェイクは最終選択と、対応する場合には認証済み可用一覧を示す。アプリケーション交換まで完了して初めて「動作した」と言える。

この連鎖なら、特定の再試行や中断を診断できる。しかしすべてのエニーキャスト拠点が同じ一覧を出すこと、各バージョンが現在も有効なこと、その全てでアプリケーションが成功すること、最初の応答が指定サービス由来であることは証明できない。配備台帳には複数の許可済み経路での検証、TLS で確認した相手の身元、認証済み情報、ソフトウェア／設定識別子、完了したアプリケーション試験が要る。

記録すべき項目は、提示バージョン、時刻、5 タプル、Initial の DCID／SCID、応答の生バイト列、反映された ID、一覧の順序、破棄判定、次に試したバージョン、成立したバージョン、version_information、TLS で確認した相手の身元、エッジやリリースの識別子、最終結果である。低いバージョンへ移った事実だけでダウングレードを帰属してはならない。認証済みの通信記録と実際の候補集合、選択規則が必要だ。

このパケットは、一度の互換性分岐を示すから有用なのである。サーバー証明書、配備マニフェスト、全体の対応保証ではない。