要約

  • 有効なタグは、送信者がクライアントの Initial を観測し、検査対象の Retry バイトが偶発的に壊れていないことを示す。
  • 指定されたサーバーの認証、トークン受理、サーバーによるクライアントアドレス検証の完了は示さない。
  • 調査ではタグ検証、トークン返送、サーバー側検証、認証済み TLS 結果を別イベントとして保存すべきである。

パケットキャプチャに、有効な完全性タグを持つ QUIC Retry が現れた。ダッシュボードはそれを「認証済みサーバーのチャレンジ」と表示し、クライアントアドレスも検証済みにした。しかしパケットが支える証拠はそこまで広くない。

RFC 9001 §5.8 の保証は限定的だ。128 ビットのタグは、空の平文と Retry 疑似パケットを関連データとして AEAD_AES_128_GCM で計算する。疑似パケットは、タグを除いた Retry の前に Original Destination Connection ID（ODCID）の長さと値を置いたものだ。QUIC v1 では計算に使う鍵と nonce も仕様に記載される。ODCID はクライアントの Initial に由来するため、有効なタグは送信者がその Initial を見たことを示し、偶発的な破損の排除にも使える。

これはピア認証ではない。QUIC v1 の計算に必要な固定値は公開仕様にあり、Retry に保護されたフィールドはない。タグは TLS の証明書と Finished の検証に代わらない。応答したサーバーインスタンス、そのサービス名に対する権限、あるいは経路上の装置が送信した可能性についても答えない。

RFC 9000 §17.2.5 はクライアント側の次の処理を定める。タグを検証できない Retry や、長さゼロのトークンを持つ Retry は破棄し、一つの接続試行で処理する Retry は最大一つである。受理した場合、クライアントは Retry の SCID を DCID とし、トークンをコピーした新しい Initial を送る。つまり観測した Retry は返送証明の要求であって、完了した証明ではない。

サーバー側の境界は RFC 9000 §8.1.2 にある。攻撃者が自分のアドレス用に有効なトークンを生成できず、クライアントがそのトークンを返せるなら、サーバーはクライアントが受け取ったことを確認できる。それでもサーバーは返送トークンを検証し、接続を拒否するか進めるか決める必要がある。送信 Retry で終わるキャプチャは、トークン受理もクライアントアドレス検証完了も証明しない。

運用記録には、QUIC バージョン、最初の Initial の 5 タプルと時刻、ODCID、Retry の DCID と SCID、正確なバイト列、タグ結果、トークン指紋、次の Initial の 5 タプルと時刻、返送指紋、サーバー検証結果、検証ドメインまたはインスタンス、TLS 証明書と Finished、最終結果を結び付ける。これにより anycast の秘密情報ずれ、期限切れ、経路変更、誤ルーティングを、身元認証と混同せずに分けられる。