HTTP における早期データの使用

これはインターネット標準トラック文書です。

本書はインターネット技術タスクフォース (IETF) の成果物です。IETF コミュニティの合意を示すものであり、公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 7841 のセクション 2 を参照してください。

本書の現行の状態、訂正情報（errata）、およびフィードバックの方法については https://www.rfc-editor.org/info/rfc8470 を参照してください。

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

TLS 1.3 [TLS13] は early data（ゼロラウンドトリップ（0-RTT）データとも呼ばれる）の概念を導入します。クライアントが同一のサーバーと最近やり取りしている場合、early data によってクライアントは TLS ハンドシェイクの完了を待たずに接続の最初の往復でサーバーにデータを送信できます。

HTTP と組み合わせて使用する場合 [HTTP]、 early data はクライアントがリクエストを直ちに送信できるようにし、TLS ハンドシェイクに必要な 1 回または 2 回の往復遅延を回避します。これは大きな性能向上ですが、重大な制約も伴います。

early data を使用する主なリスクは、攻撃者がそれを取得して再生（replay）する可能性があることです。TLS [TLS13] は攻撃者がリクエストの再生に成功する可能性を下げるための技術を示していますが、これらの技術は展開が難しく、依然として成功する可能性が残ることがあります。

これは自動的またはユーザーによる再試行とは異なることに注意してください；リプレイはクライアントの知らないところで攻撃者によって開始されます。

HTTP におけるリプレイのリスクを軽減するために、本書はサーバー側のリスク制御手法の概観を示し、クライアントが early data でリクエストを送信する際の要件を定義します。

本書の助言は、HTTP over QUIC における 0-RTT の使用（[HQ]）にも適用されます。

概念的には、early data は他のアプリケーションデータと連結されて単一のストリームを形成します。これにより、リクエスト全体が early data に含まれる場合もあれば、リクエストの一部だけが early data である場合もあります。HTTP/2 [RFC7540] や HTTP/QUIC [HQ] のような多重化プロトコルでは、複数のリクエストが部分的に early data で配信されることがありえます。

本書が想定するモデルでは、TLS ハンドシェイクが完了した後、その TLS 接続で受信された early data はその接続上で再生されたコピーではないことが分かる、という扱いです。しかし、これは early data が別の接続で再生されないことを意味するものではない点に注意が必要です。

サーバーは TLS セッションチケットを送る際に、将来の接続でクライアントが early data を送信できるようにするかどうかを決定します。

TLS [TLS13] は、攻撃者が early data を再生して成功させる能力を低減する再生検出戦略の使用を義務付けています。これらの対再生技術はリプレイの可能性を減らしますが完全には排除せず、かつ再生回数に上限を設けます。

1. サーバーは TLS レイヤーで early data を拒否することができます。サーバーは early data を選択的に拒否できないため、これを行うと early data で送信されたすべてのリクエストが破棄されます。
2. サーバーは early data の処理を TLS ハンドシェイク完了まで遅延させる選択ができます。処理を遅らせることで、接続が正常に完了した場合にのみその接続上のリクエストを使用するという保証を得られます。複数のリクエストが early data に含まれる場合、サーバーはリクエストごとに HTTP 処理を遅らせるかどうかを決められます。
3. サーバーはリプレイのリスクが高いと判断した場合、個々のリクエストに対して 425 (Too Early) ステータスコード（Section 5.2）でクライアントに再試行させ、early data を使わせないようにすることができます。

これらの技術はいずれも同等に有効であり、サーバーは自分に最も適した方法を用いることができます。

特定のリクエストに対するリプレイリスクへの許容度は、そのリクエストが操作するリソースに依存し（したがって起源サーバーだけが知り得る）、複製されたリクエストの処理が重複した効果や副作用をもたらす点が主たるリスクです。Appendix E.5（[TLS13]）も、複製リクエストの処理で生じる他の影響を記述しています。

リクエストメソッドの安全性（[RFC7231], Section 4.2.1）は、判断の一助となります。ただし、安全と見なされるメソッドでも一部のリソースは副作用を生むため、これだけに全面的に依存できるわけではありません。

起源サーバーは、リソースがリクエストにおける early data の使用に適するかどうかを明示的に設定できるようにすることが推奨されます。こうした明示的情報がない場合、起源サーバーは early data を拒否するか、本書で述べる TLS ハンドシェイク完了前のリクエスト処理を防ぐ技術を実装しなければなりません。

リクエストの一部が early data で送信され、残りがハンドシェイク完了後に送信されることがあります。これは必ずしもそのリクエストの扱いに影響しません；重要なのはサーバーがいつリクエストの内容に基づいて動作を開始するかです。いかなる時点でも、任意のサーバーインスタンスがハンドシェイク完了前に処理を開始する可能性がある場合、すべてのサーバーインスタンスは early data の再生が処理にどのように影響するかを考慮する必要があります（Section 6.2 も参照）。

不完全なリクエストをサーバーが部分的に処理することは可能です。ヘッダーフィールドの解析（値に基づいて行動することなく）やリクエストのルーティング決定は副作用のない比較的安全な処理ですが、その他の動作はそうではないかもしれません。

中継サーバー（インターミディアリ）は early data を処理できるかどうかを決めるための十分な情報を持たないことが多いため、Section 5.2 は起源からのシグナリング方法を記述しています。early data を受け入れる中継サーバーはそのメカニズムを実装しなければなりません。

サーバーは TLS レイヤーで early data を選択的に拒否できないことに注意してください。TLS はサーバーに対して early data をすべて受け入れるか全く受け入れないかのどちらかしか許しません。サーバーが early data の受け入れを決めた場合、たとえサーバーがリクエストを 425 (Too Early) で拒否したとしても、early data 内のすべてのリクエストは受信扱いとなります。

サーバーは TLS 拡張の early_data の max_early_data_size フィールドで early data の量を制限できます。これはハンドシェイク完了まで延期する可能性のあるリクエストのために任意の量のメモリを確保するのを避けるために役立ちます。

early data を使用したいクライアントは、TLS ClientHello を送信した直後に HTTP リクエストを送ることから開始します。

本質的に、クライアントは特定のリクエストを early data で送るかどうかを制御できるため、リプレイリスクの管理をクライアント側で行えます。追加情報がない場合、クライアントは early data が利用可能な場合に安全な HTTP メソッド（[RFC7231], Section 4.2.1）のリクエストを early data で送信してもよい（MAY）ですが、安全でないメソッド（または安全性が不明なメソッド）は early data で送信してはなりません（MUST NOT）。

サーバーが TLS レイヤーで early data を拒否した場合、クライアントは接続が新規であるかのように再送を開始しなければなりません。これは、early data に楽観的に使用したプロトコル（例えば ALPN によるネゴシエーションで選んだもの）とは異なるプロトコルを用いることを含む可能性があります。early data で送ったリクエストは、クライアントが放棄しない限り再度送信する必要があります。

自動再試行はリプレイ攻撃の可能性を生みます。攻撃者が early data を使う接続を傍受して early data を別のサーバーインスタンスにコピーすると、第二のインスタンスは early data を受け入れて処理しうる一方で TLS ハンドシェイクは完了しません。その後攻撃者が元の接続を完了させると、元の接続のインスタンスが early data を重複として検出して拒否したとしても、クライアントが early data 内で送ったリクエストを再送するとリクエストは二重に処理されることになります。

複数のサーバーインスタンスが early data を受け入れる場合や、同じサーバーが複数回 early data を受け入れる場合にもリプレイは発生し得ます（後者は TLS13 Section 8 の要件に反する行為です）。

early data を使用するクライアントは 425 (Too Early) ステータスコードを受け取った場合、リクエストを再試行しなければなりません（MUST）；詳細は Section 5.2 を参照してください。

中継サーバーは、前のホップで early data が使われた場合、またはリクエストを安全に再試行できることが確実に分かっている（通常はアウトオブバンド設定を用いる場合）場合を除き、リクエストの転送に early data を使用してはなりません。十分な情報がない場合、中継サーバーはリクエストが early data で到着したか、あるいは Early-Data ヘッダーフィールドが “1” に設定されている場合にのみ early data を使用できます（Section 5.1 参照）。

HTTP リクエストは複数の「ホップ」に渡ることがあるため、あるリクエストが前のホップで early data として送信されたかどうかを明示的に伝える必要があります。同様に、early data が望ましくない場合に明示的に再試行を引き起こす手段も必要です。最後に、クライアントが実際に再試行を行うかどうかを知る手段も必要です。

• Early-Data ヘッダーフィールドは、中継がクライアントとの TLS ハンドシェイク完了前にリクエストを転送した可能性があることを示すためにリクエストに含められます。
• 425 (Too Early) ステータスコードは、サーバーが再生の結果として発生しうる影響のためリクエストを処理できないことを示すために定義されます。

これらはユーザーエージェントと起源サーバー、さらにゲートウェイ（リバースプロキシ、CDN、サロゲート等）が存在する場合の早期データ利用の調整を可能にするよう設計されています。

ゲートウェイは一般に、特定のリクエストが early data で安全に処理できるかどうかについての具体的な情報を持ちません。多くの場合、リプレイの許容性を判断できるのは起源サーバーだけです。これらの拡張は、ゲートウェイと起源サーバー間の調整を可能にします。

early data を使用すると、クライアントはリクエストが再生されるリスクに晒されます。再試行または再生されたリクエストはサーバー上で異なる副作用を生むことがあります。これらの副作用に加え、リプレイや再試行はトラフィック解析によりリクエストやその対象リソースに関する情報を回復するために利用される可能性があります。特に、再生されたリクエストが異なるレスポンスを生み、その長さから保護されたデータの長さが観測されうる点に注意が必要です。

本書は Early-Data ヘッダーフィールドを “Permanent Message Header Field Names” レジストリ（<https://www.iana.org/assignments/message-headers>）に登録します。

Header field name:

Early-Data

Applicable protocol:

http

Status:

standard

Author/Change controller:

IETF

Specification document(s):

This document

Related information:

(empty)

本書は 425 (Too Early) ステータスコードを “HTTP Status Codes” レジストリ（<https://www.iana.org/assignments/http-status-codes>）に登録します。

Value:

425

Description:

Too Early

Reference:

This document

本書の作成は容易ではありませんでした。以下の人々は文書の品質と完全性に多大な貢献をしました：David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, Victor Vasiliev。