要約

  • QUIC 0-RTT の受理は TLS とトランスポートの判断であり、アプリケーションの一回限りの実行を示さない。
  • パケット ACK はトランスポート処理の証拠であって、リプレイ耐性、永続確定、認証済みのクライアント識別、業務上の成功の証拠ではない。
  • 早期データを許す範囲とリプレイ対策はアプリケーションが定め、実行と結果を別々に記録する。

QUIC 0-RTT では、クライアントが以前の接続に結び付いた設定、つまり TLS セッションチケットなどを再利用し、新しいハンドシェイクが完了する前にアプリケーションデータを送れる。サーバーは EncryptedExtensions の TLS early_data 拡張によって受理を示し、その後に受信した 0-RTT パケットを処理して ACK を返す。拡張を送らなければ 0-RTT は拒否され、対象パケットを受理済みの早期データとして処理してはならない。

ここで確認できるのは、暗号とトランスポートの境界までである。アプリケーションの処理が正確に一度だけ実行されたこと、下流サービスに届いたこと、永続化の確定点を越えたことは分からない。ハンドシェイク完了前の受理は、クライアントの生存や認証済みの身元も証明しない。アドレス検証が行われていても、リプレイされたデータを一意の業務操作に変えるわけではない。

QUIC 0-RTT は TLS の早期データに伴うリプレイのリスクを持つ。TLS の対策は必要だが、アプリケーションの保証にはならない。QUIC の基本的なトランスポートフレーム処理は冪等なので、フレームをリプレイしただけで接続状態が壊れるわけではない。問題は、そのフレームが運ぶアプリケーションの意味にある。STREAM、RESET_STREAM、STOP_SENDING、CONNECTION_CLOSE はアプリケーション上の意味を持ち得るため、0-RTT では安全とは限らない。QUIC を使うアプリケーションプロトコルは、許容する用途を明確にしなければならない。

HTTP の Early-Data は中継された早期データの状態を伝える。情報が足りない場合、クライアントは安全なメソッドを選び、安全でないメソッドや安全性不明のメソッドを使ってはならない。425 Too Early は、リプレイされるかもしれない要求を処理するリスクをサーバーが負わないという信号である。再試行そのものに早期データを使ってはならない。中継が要求を Early-Data と印付けした後でハンドシェイクを待っても、要求は遡って安全にはならない。分散した実装は同じ方針で処理する必要がある。

証拠台帳では、セッションチケットと記憶された設定、0-RTT の試行・受理・拒否、パケット ACK、Early-Data の伝播と 425 の処理、要求識別子と冪等キー、実行試行、副作用、永続確定の受領、再試行やリプレイの観測、顧客または金銭の結果を別フィールドにする。冪等キー、取引ジャーナル、分散リプレイ台帳、業務結果の受領書は運用上の提案であり、アプリケーションプロトコルが定めない限り QUIC の要件ではない。

結論は一律停止ではなく、リプレイ時の影響を明確に限定できる操作にだけ 0-RTT を許すことである。受理は早期データの判断を示すが、取引確定を示さない。