http-early-data-ja.html

<!DOCTYPE html><html><head><meta charset="utf-8">
<title>RFC 8470 — Using Early Data in HTTP（日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">
<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script>

Object.assign(source_data.st_phrase, {
	'425': 'Too Early',
});

</script>

<script type="text/plain" id="_source_data">

●●options

spec_title:RFC 8470 — Using Early Data in HTTP
trans_update:2023-01-23
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc8470.html
abbr_url:HTTPearlydata
spec_status:IETFPR
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2023-01-23

●●original_id_map

●●mdn_urls
header:HTTP/Status/425

●●link_map
	~RFCx/RFC7234 → ~HTTPcache

h.Early-Data:#header
st.425:#status

6.2:#be-consistent

●●words_table1

●●words_table

	●network
QUIC:
	~QUIC越しの~HTTP:HTTP/QUIC
HTTP2:HTTP/2
HTTP3:HTTP/3
0-RTT:
再現:replay::~
再現-:replay::~
早期:early::~
handshake::::ハンドシェイク
捕捉-:capture:~
多重化-:multiplex:~
横取りし:interceptし:~
到着-:arrive:~
高価:expensive:~
固定的:fixed:~
帯域外の:out-of-band:~
ticket::::チケット
hop:

	^i:ClientHello
	`経験的に~cache可能$:cacheable by default
	`内容$:payload
	`~target資源$:identified resource
	`~target資源$:the resources those requests target
	回送-先になり得る どの`生成元~server$も 〜ない:without at least one potential origin server that
	`上流$にあるどこかの:a previous
	`425$st 応答:425 (Too Early) status code
	`425^st0 応答:425 (Too Early) status code

	●保安
晒され:exposeされ:~
	晒されるアリ性がある:creates an exposure to the possibility of
	`安全$か否か:safety
	安全でない:unsafe

	●仕様
分析:analysis:~
commit:
策:strategy:~
合意-:agree:~
措置:measure:~
排-:eliminate:~
判定-:judge:~
普遍的:universal:~
楽観的:optimistic:~
放棄-:abandon:~
不確か:uncertain:~
助言:advice:~
受忍度:tolerance:~
協調:coordination:~
為す:makeする:~
critical:

	問われる:matter
	-:critically
	ある程度まで〜確約する:provides 〜 with some assurance
	アリ性:possibility
	アリ性があること:consequences of a possible 〜
	~~副作用を伴うことなく:without consequences
	違反している:in violation of
	気付かれることなく:without the awareness
	助けとして:to help
	自身に最も適する:best suits
	見込みが高い:likely
	必然的に伴うこともある:could entail
	満たす:meet
	用意がある:is willing to
	用意はない:unwilling:#1
	満たさ:met
	至らす:lead
	方々:people
	大きく貢献された:made substantial contributions
	仕立て上げる:make
	制作:to produce
	の対象になり得る:creates the potential for
	労による 〜 割に合わなく:expends significant effort for what can at best be a modest

	●未分類
復元-:recover:~
発-:emit:~
着手-:commence:~
反-:anti-:~

	〜を伴う:marked with
	高まり得る:could result in increased
	順序どおりでない:out of order
	順序どおりに〜ない:out of order
	副作用を伴う:produce side effects with
	まるごと:as a whole
	当の早期~data内:therein
	内に〜部分的な場合もある: in, or partially in
	2 回:twice
	完全さ:completeness
	直後:immediately after
	1 ~bitの:single bit of
	やりとりした:has spoken
	回数:number of
	等しく:equally
	選べる:chooseでき
	在る／無い:present
	識別され:identified
	高める:enhancement
	~~可能性~likelihood
	残される:leave
	上限:upper limit
	ごとに:per-〜 basis
	〜が無い下では:Absent 〜
	を成す残り:the remainder of
	~route法:routing
	高過ぎる:too great
	〜を伴う:marked with
	高まり得る:could result in increased
	順序どおりでない:out of order
	順序どおりに〜ない:out of order
	まるごと:as a whole
	当の早期~data内:therein
	内に〜部分的な場合もある: in, or partially in
	~~費やす:expend
	重複した:duplicated
	どの時点でも:any time
	渡り:span

●●ref_data
HQ=副    ~/http3-ja.html●日本語訳（RFC9114）

●●ref_normative

[ABNF]
    Crocker, D., Ed. and P. Overell, ＜Augmented BNF for Syntax Specifications: ABNF＞, STD 68, ~RFC5234
[RFC7230]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing＞, ~RFC7230
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119
[RFC7231]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content＞, ~RFC7231
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174
[TLS13]
    Rescorla, E., ＜The Transport Layer Security (TLS) Protocol Version 1.3＞, ~RFC8446

●●ref_informative

[ALPN]
    Friedl, S., Popov, A., Langley, A., and E. Stephan, ＜Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension＞, ~RFC7301
[HQ]
    Bishop, M., ＜Hypertext Transfer Protocol (HTTP) over QUIC＞, Work in Progress, draft-ietf-quic-http-14, August 2018.
[RFC7540]
    Belshe, M., Peon, R., and M. Thomson, Ed., ＜Hypertext Transfer Protocol Version 2 (HTTP/2)＞, ~RFC7540

●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 8470
<a href="~SPEC_URL">Using Early Data in HTTP</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	8470
分類
	Standards Track
ISSN
	2070-1721
編集
	<a href="mailto:martin.thomson@gmail.com">Martin Thomson</a> (Mozilla)
	<a href="mailto:mnot@mnot.net">Mark Nottingham</a> (Fastly)
	<a href="mailto:willy@haproxy.org">Willy Tarreau</a> (HAProxy Technologies)
日付
	2018 年 9 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc8470

</script>

<body>

<header>
	<hgroup>
<h1>HTTP における早期データの利用法</h1>
<p>RFC 8470 — Using Early Data in HTTP</p>
	</hgroup>
</header>

<div id="MAIN" hidden>
	<section id="rfc.abstract">
◎要約

<p>
~TLS早期~data（ `early data^en ）を利用すると、
再現~攻撃
（ `replay attack^en ）
【 “~~反射攻撃” とも呼ばれる】
に晒されるアリ性がある。
この文書は、［
早期~data内に送信された~HTTP要請
］について［
`~client$が`~server$と通信する
］ことを許容するための仕組みを定義するとともに，［
これらの仕組みを利用するにあたって再現の~riskを軽減する
］ための技法を述べる。
◎
Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.
</p>

	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright © 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、
この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">

	<section id="introduction">
<h2 class="np" title="Introduction">1. 序論</h2>

<p>
~TLS 1.3 `TLS13$r は、
早期~dataの概念を導入した
（往復-時間 0 な~data 
（ `zero round-trip time data^en, 略して ~0-RTT~data）
としても知られる）。
早期~dataは、
`~client$が［
近過去にやりとりした`~server$との接続
］の最初の往復において［
~TLS~handshakeが完了するまで待機することなく，~serverへ~dataを送信する
］ことを許容する。
◎
TLS 1.3 [TLS13] introduces the concept of early data (also known as zero round-trip time (0-RTT) data). If the client has spoken to the same server recently, early data allows a client to send data to a server in the first round trip of a connection, without waiting for the TLS handshake to complete.
</p>

<p>
早期~dataは、
~HTTP `RFC7230$r と伴に利用されるときには，
`~client$が要請を即時に送信することを許容する
— したがって、
~TLS~handshake用に必要になる 1 回または 2 回の往復による遅延を避ける。
これは、
処理能を有意に高めるが，有意な制限もある。
◎
When used with HTTP [HTTP], early data allows clients to send requests immediately, thus avoiding the one or two round-trip delays needed for the TLS handshake. This is a significant performance enhancement; however, it has significant limitations.
</p>

<p>
早期~dataを利用する際の首な~riskは、
攻撃者が［
早期~dataが包含する要請（たち）を捕捉して再現する
］かもしれないことである。
~TLS `TLS13$r は，［
攻撃者が ある要請を成功裡に再現する~~可能性
］を抑制するために利用できる技法を述べるが、
これらの技法は配備するのが困難なこともあり，
何らかの成功裡な攻撃のアリ性も依然として残される。
◎
The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. TLS [TLS13] describes techniques that can be used to reduce the likelihood that an attacker can successfully replay a request, but these techniques can be difficult to deploy and still leave some possibility of a successful attack.
</p>

<p>
これは、［
自動化された再試行／利用者が起動した再試行
］とは異なることに注意
— 再現は、
`~client$に気付かれることなく，攻撃者により起動される。
◎
Note that this is different from automated or user-initiated retries; replays are initiated by an attacker without the awareness of the client.
</p>

<p>
この文書は、
~HTTPにおける再現の~riskを軽減する助けとして：
◎
To help mitigate the risk of replays in HTTP, this document＼
</p>
<ul>
	<li>
`~server$において，これらの~riskを制御するための技法を成す概観を与える。
◎
gives an overview of techniques for controlling these risks in servers＼
</li>
	<li>
`~client$が早期~data内に要請を送信するための要件を定義する。
◎
and defines requirements for clients when sending requests in early data.
</li>
</ul>

<p>
この文書における助言は、
~QUIC越しの~HTTP `HQ$r における~0-RTTの利用にも適用される。
◎
The advice in this document also applies to use of 0-RTT in HTTP over QUIC [HQ].
</p>

		<section id="conventions-and-definitions">
<h3 title="Conventions and Definitions">1.1. 表記規約</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
</p>

		</section>
		<section id="_conventions">
<h3>【この訳に特有な表記規約】</h3>

<p>
この訳では、
この仕様が公表された当時の~HTTP仕様（ `RFC7230$r, `RFC7231$r ）を参照している箇所を，
現在の中核~HTTP仕様~内の`等価な記述を指すよう改めている＠~HTTPcommon#_terms-convention$。
</p>

		</section>
	</section>
	<section id="early-data-in-http">
<h2 title="Early Data in HTTP">2. ~HTTPにおける早期~data</h2>

<p>
早期~dataは、
概念的には，単独の~streamを形成するよう他の応用~dataと連結される。
このことは、要請は［
その一部に限り，早期~dataの中に包含される場合もある
］ことを意味する。
多重化された~protocol
— ~HTTP2 `RFC7540$r や~QUIC越しの~HTTP `HQ$r 【すなわち，~HTTP3（~RFC 9114 ）】など —
においては、
複数個の要請が，早期~data内に部分的に送達されるかもしれない。
◎
Conceptually, early data is concatenated with other application data to form a single stream. This can mean that requests are entirely contained within early data or that only part of a request is early. In a multiplexed protocol, like HTTP/2 [RFC7540] or HTTP/QUIC [HQ], multiple requests might be partially delivered in early data.
</p>

<p>
【！The model that】この文書は、［
~TLS~handshakeを完了したなら、［
当の~TLS接続にて受信された早期~dataは、
再現された複製ではない
］ことが既知になる
］ものと見做す。
しかしながら，重要なこととして、
このことは，早期~dataが別の接続においても再現され［
なくなる／なかった
］ことは意味しないことに注意。
◎
The model that this document assumes is that once the TLS handshake completes, the early data received on that TLS connection is known to not be a replayed copy of that data. However, it is important to note that this does not mean that early data will not be or has not been replayed on another connection.
</p>

	</section>
	<section id="supporting-early-data-in-http-servers">
<h2 title="Supporting Early Data in HTTP Servers">3. ~HTTP~serverにおける早期~dataの~support法</h2>

<p>
`~server$は、
~TLS~session~ticketを送信するときに［
未来の接続にて早期~dataを送信する能
］を`~client$に提供するか否かを裁定する。
◎
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket.
</p>

<p>
~TLS `TLS13$r は、［
攻撃者が早期~dataを成功裡に再現する能
］を［
抑制するための再現~検出~策
］の利用を義務付ける。
これらの反-再現~技法は、
~dataが再現される機会cを抑制するが，［
それを完全に排するもの
］でも［
再現の回数に対し固定的な上限を確保するもの
］でもない。
◎
TLS [TLS13] mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data. These anti-replay techniques reduce but don’t completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays.
</p>

<p>
`~server$が早期~dataを可能化するとき、
再現の~riskを軽減するために利用できる技法として，次が挙げられる
— ~serverは：
◎
When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay:
</p>
<ul>
	<li>
~TLS層にて早期~dataを却下できる
— ただし，それらを選択的には却下できないので、
早期~data内に送信された要請は，すべて破棄される結果になる。
◎
The server can reject early data at the TLS layer. A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.
</li>
	<li>
早期~dataの処理を
~TLS~handshakeが完了するまで遅延することを選べる
— 処理を先送りすることにより，［
当の早期~data内の要請（たち）用に利用される接続は、
成功裡に完了したものに限られる
］ことを確保できる。
これは、
早期~dataは再現されなかったことを ある程度まで`~server$に確約する。
`~server$は、
早期~data内に受信した各~要請ごとに［
~HTTP処理を先送りするか否か
］を決定できる。
◎
The server can choose to delay processing of early data until after the TLS handshake completes. By deferring processing, it can ensure that only a successfully completed connection is used for the request(s) therein. This provides the server with some assurance that the early data was not replayed. If the server receives multiple requests in early data, it can determine whether to defer HTTP processing on a per-request basis.
</li>
	<li>
再現の~riskが高過ぎるものと判定された事例では、
早期~dataを利用しない代わりに状態s~code `425$st で応答することにより，
個々の要請を`~client$に再試行させれる。
【！（ `425§st0 ）】
◎
The server can cause a client to retry individual requests and not use early data by responding with the 425 (Too Early) status code (Section 5.2) in cases where the risk of replay is judged too great.
</li>
</ul>

<p>
これらの技法は、
どれも等しく効果的である
— `~server$は、
自身に最も適する手法を利用できる。
【 “等しく効果的” の意味は、 `6.2§ を見よ。】
◎
All of these techniques are equally effective; a server can use the method that best suits it.
</p>

<p>
所与の要請が再現される~riskに対する受忍度の~levelは、
それが演算する`資源$に特有である
（したがって、
`生成元~server$にしか既知にならない）。
早期~dataを利用することに結付けられる首な~riskは、
要請を処理するとき`~server$がとる動作にある
— 重複した要請の処理による結果は、
重複した効果や副作用になるかもしれない。
`TLS13$r `E.5＠~RFCx/rfc8446#appendix-E.5§ は、
重複した要請を処理することにより生産される他の効果も述べる。
◎
For a given request, the level of tolerance to replay risk is specific to the resource it operates upon (and therefore only known to the origin server). The primary risk associated with using early data is in the actions a server takes when processing a request; processing a duplicated request might result in duplicated effects and side effects. Appendix E.5 of [TLS13] also describes other effects produced by processing duplicated requests.
</p>

<p>
`要請~method$が`安全$か否か【！`RFC7231$r `4.2.1＠~RFCx/rfc7231#section-4.2.1§】は、
これを決定する一つの仕方を成す。
しかしながら、［
一部の`資源$は、
`安全$な~methodであっても，副作用を伴う
］ので，これは［
普遍的に依拠できるもの
］ではない。
◎
The request method’s safety ([RFC7231], Section 4.2.1) is one way to determine this. However, some resources produce side effects with safe methods, so this cannot be universally relied upon.
</p>

<p>
`生成元~server$は、
各`資源$に対し，［
要請における早期~dataは適切かどうか
］を［
明示的に環境設定する
］ことを許容することが`推奨される^2119。
そのような明示的な情報が無い下では、
`生成元~server$は，［
早期~dataを却下する
］か［
この文書にて述べられる技法を実装する
］ことにより［
要請は、
~TLS~handshakeの完了に先立って処理されたものではない
］ことを確保しなければナラナイ。
◎
It is RECOMMENDED that origin servers allow resources to explicitly configure whether early data is appropriate in requests. Absent such explicit information, origin servers MUST either reject early data or implement the techniques described in this document for ensuring that requests are not processed prior to TLS handshake completion.
</p>

<p>
要請は、
早期~data内に部分的に送信されるかもしれない
— 残りは，~handshakeが完了した後に送信されるよう。
これは，要請の取扱いに影響するとは限らないが、
`~server$が要請の内容に対し，いつ動作し始めるかは問われる。
どの時点でも，どの~server~instanceも、［
~handshakeの完了に先立って，処理を起動する
］かもしれない
— すべての~server~instanceが［
早期~dataの再現のアリ性,
それが その処理にどう影響し得たか
］を織り込む必要がある
（`6.2§も見よ）。
◎
A request might be sent partially in early data with the remainder of the request being sent after the handshake completes. This does not necessarily affect handling of that request; what matters is when the server starts acting upon the contents of a request. Any time any server instance might initiate processing prior to completion of the handshake, all server instances need to account for the possibility of replay of early data and how that could affect that processing (see also Section 6.2).
</p>

<p>
`~server$は、
不完全な要請を部分的に処理できる。
~headerたちだけを構文解析して
— それらの値に対し動作することなく —
要請の~route法を決定することは，
副作用に関して安全になる見込みが高いが、
他の動作は，そうでないかもしれない。
◎
A server can partially process requests that are incomplete. Parsing header fields -- without acting on the values -- and determining request routing is likely to be safe from side effects but other actions might not be.
</p>

<p>
`媒介者$は、［
早期~dataを処理できるかどうか裁定するために足る情報
］を有さない。
`425§st0 は、
`生成元~server$用に，［
特定0の要請が早期~data用には適切でないこと
］を［
`媒介者$へ通達する仕方
］を述べる。
早期~dataを受容する`媒介者$は、
その仕組みを実装しなければナラナイ。
◎
Intermediary servers do not have sufficient information to decide whether early data can be processed, so Section 5.2 describes a way for the origin to signal to them that a particular request isn’t appropriate for early data. Intermediaries that accept early data MUST implement that mechanism.
</p>

<p>
`~server$は、［
~TLS層にて早期~dataを選択的に却下すること
］を選べないことに注意。
~TLSは、
早期~dataを［
常に受容する,
常に受容しない
］どちらかしか`~server$に許可しない。
`~server$は、
早期~dataを受容するものと裁定したなら，
早期~data内の要請をすべて処理しなければナラナイ
— `~server$が `425$st 応答を送信して要請を却下する場合でも。
◎
Note that a server cannot choose to selectively reject early data at the TLS layer. TLS only permits a server to either accept all early data or none of it. Once a server has decided to accept early data, it MUST process all requests in early data, even if the server rejects the request by sending a 425 (Too Early) response.
</p>

<p>
`~server$は、
`early_data^c ~TLS拡張の `max_early_data_size^c ~fieldで早期~dataの量を制限できる。
これは、［
~handshakeが完了するまで`~server$が先送りするかもしれない要請
］用に［
任意な量の~memoryを~commitする
］ことを避けるために利用できる。
◎
A server can limit the amount of early data with the max_early_data_size field of the early_data TLS extension. This can be used to avoid committing an arbitrary amount of memory for requests that it might defer until the handshake completes.
</p>

	</section>
	<section id="using-early-data-in-http-clients">
<h2 title="Using Early Data in HTTP Clients">4. ~HTTP~clientにおける早期~dataの利用-法</h2>

<p>
`~client$は、
早期~dataを利用したいと望むときは，［
~TLS `ClientHello^i を送信した直後
］に，~HTTP要請の送信に着手する。
◎
A client that wishes to use early data commences by sending HTTP requests immediately after sending the TLS ClientHello.
</p>

<p>
要請を早期~data内に送信するかどうかは，
その資質により`~client$が制御するので、
再現の~riskに対する制御も，`~client$に与えられる。
`~client$は、
他の情報が無い下では，早期~data内に［
`安全$な~HTTP~method【！`RFC7231$r `4.2.1＠~RFCx/rfc7231#section-4.2.1§】を伴う要請
］を
— それが可用ならば —
送信してもヨイ。
`~client$は、
早期~data内に［
`安全$でない／`安全$か否か既知でない
］~methodを伴う要請を送信してはナラナイ。
◎
By their nature, clients have control over whether a given request is sent in early data, thereby giving the client control over risk of replay. Absent other information, clients MAY send requests with safe HTTP methods ([RFC7231], Section 4.2.1) in early data when it is available and MUST NOT send unsafe methods (or methods whose safety is not known) in early data.
</p>

<p>
`~server$が~TLS層にて早期~dataを却下する場合、
`~client$は，再び送信を
— 当の接続は新たなものであったかのように —
開始しなければナラナイ。
これは、［
早期~data用に楽観的に利用した~protocolとは異なる~protocol
］を折衝して利用すること `ALPN$r を必然的に伴うこともある。
`~client$は、
早期~data内に送信した要請を
— それを放棄するものと裁定しない限り —
再び送信する必要がある。
◎
If the server rejects early data at the TLS layer, a client MUST start sending again as though the connection were new. This could entail using a different negotiated protocol [ALPN] than the one optimistically used for the early data. Any requests sent in early data will need to be sent again, unless the client decides to abandon those requests.
</p>

<p>
自動的な再試行は、
再現~攻撃の対象になり得る：
◎
Automatic retry creates the potential for a replay attack.＼
</p>
<ol>
	<li>
攻撃者は、
ある~server~instance A への早期~dataを利用する接続を横取りして，
当の早期~dataを別の~server~instance B へ複製する。
◎
An attacker intercepts a connection that uses early data and copies the early data to another server instance.＼
</li>
	<li>
~server B は、
~TLS~handshakeを完了しないことになる場合でも，
当の早期~dataを受容して処理する。
◎
The second server instance accepts and processes the early data, even though it will not complete the TLS handshake.＼
</li>
	<li>
攻撃者は、
元の接続を完了することを許容する。
◎
The attacker then allows the original connection to complete.＼
</li>
	<li>
~server A は、
当の早期~dataが重複であり却下されるものとして検出した場合でも，
当の接続を完了することを許容するかもしれない。
当の`~client$が早期~data内に送信した要請を再試行した場合、
要請は， 2 回~処理されることになる。
◎
Even if the early data is detected as a duplicate and rejected, the first server instance might allow the connection to complete. If the client then retries requests that were sent in early data, the request will be processed twice.
</li>
</ol>

<p>
再現は、［
早期~dataを受容する~server~instanceが複数~在る場合／
同じ`~server$が早期~dataを複数回~受容する場合
］にもアリになる
（後者は、
`TLS13$r `8＠~RFCx/rfc8446#section-8§ における要件に違反しているが）。
◎
Replays are also possible if there are multiple server instances that will accept early data or if the same server accepts early data multiple times (though the latter would be in violation of requirements in Section 8 of [TLS13]).
</p>

<p>
早期~dataを利用する`~client$は、
`425$st 応答を受信したときは，要請を再試行しなければナラナイ
— `425§st0 を見よ。
◎
Clients that use early data MUST retry requests upon receipt of a 425 (Too Early) status code; see Section 5.2.
</p>

<p>
`媒介者$は、
次のいずれかに該当する場合を除き，
早期~dataを利用して要請を回送してはナラナイ：
◎
An intermediary MUST NOT use early data when forwarding a request unless＼
</p>
<ul>
	<li>
`上流$にあるどこかの~hopにて早期~dataが利用された。
【~hopとは、接続の`連鎖$を成す各~接続（隣接する 2 つの参加者の合間）を意味する。】
◎
early data was used on a previous hop,＼
</li>
	<li>
<p>
［
当の要請は、
~~副作用を伴うことなく安全に再試行できる
］ことを
（概して，帯域外の環境設定†を利用して）
知る場合。
◎
or it knows that the request can be retried safely without consequences (typically, using out-of-band configuration).＼
</p>

<p class="trans-note">【†
すなわち，
`5＠#extensions-for-early-data-in-http§ にて述べられる “協調” ／
`6.2§ にて述べられる “合意-”
】</p>
	</li>
</ul>

<p>
すなわち、
より良い情報が無い下で，`媒介者$が【自身が回送する要請~用に】早期~dataを利用できるのは、
当の要請が［
早期~data内に到着した
］か［
値 `1^c に設定された `Early-Data$h ~headerを伴って到着した
］場合に限られる
（ `Early-Data§h を見よ）。
◎
Absent better information, that means that an intermediary can only use early data if the request either arrived in early data or arrived with the Early-Data header field set to “1” (see Section 5.1).
</p>

	</section>
	<section id="extensions-for-early-data-in-http">
<h2 title="Extensions for Early Data in HTTP">5. ~HTTPにおける早期~data用の拡張</h2>

<p>
~HTTP要請は，複数の “~hop” に渡り得るので、
次に挙げるものが必要yである：
◎
Because HTTP requests can span multiple “hops”,＼
</p>
<ul>
	<li>
次について明示的に通信すること
⇒
`上流$にあるどこかの~hopにて，要請が早期~data内に送信されたかどうか
◎
it is necessary to explicitly communicate whether a request has been sent in early data on a previous hop.＼
</li>
	<li>
次を行うための何らかの手段
⇒
早期~dataが欲されないときには、
再試行を明示的に誘発する
◎
Likewise, it is necessary to have some means of explicitly triggering a retry when early data is not desired.＼
</li>
	<li>
次について知ること
⇒
そのような再試行を，`~client$が実際に遂行することになるかどうか
◎
Finally, it is necessary to know whether the client will actually perform such a retry.
</li>
</ul>

<p>
これらの必要性を満たすための仕組みとして、
次に挙げる通達-法が定義される：
◎
To meet these needs, two signaling mechanisms are defined:
</p>
<ul>
	<li>
次に該当する要請~内には `Early-Data$h ~headerが内包される
⇒
［
`媒介者$と`~client$との~TLS~handshakeの完了
］に先立って［
`媒介者$により回送されたかもしれない要請
］
◎
The Early-Data header field is included in requests that might have been forwarded by an intermediary prior to the completion of the TLS handshake with its client.
</li>
	<li>
`~server$が次を指示するための状態s~code `425$st
⇒
当の応答が応対した要請は、
再現~攻撃のアリ性があることに因り処理できなかった
◎
The 425 (Too Early) status code is defined for a server to indicate that a request could not be processed due to the consequences of a possible replay attack.
</li>
</ul>

<p>
これらの仕組みは、
`~gateway$【！(also “reverse proxy”, “Content Delivery Network”, or “surrogate”)】が在る下でも，
`~UA$から`生成元~server$までの間で［
早期~dataの利用を より良い協調の下で可能化する
］よう設計された。
◎
They are designed to enable better coordination of the use of early data between the user agent and origin server, and also when a gateway (also “reverse proxy”, “Content Delivery Network”, or “surrogate”) is present.
</p>

<p>
`~gateway$は、
概して，［
早期~data内に送信された所与の要請は，安全に処理できるかどうか
］について特有な情報を有さない。
多くの事例では、［
再現の~riskは受容-可能かどうか裁定するために必要yな情報
］を有するのは，`生成元~server$に限られる。
上述した拡張は、
`~gateway$と`生成元~server$との協調を許容する。
◎
Gateways typically don’t have specific information about whether a given request can be processed safely when it is sent in early data. In many cases, only the origin server has the necessary information to decide whether the risk of replay is acceptable. These extensions allow coordination between a gateway and its origin server.
</p>

		<section id="header">
<h3 title="The Early-Data Header Field">5.1. `Early-Data^h ~header</h3>

<p>
`Early-Data^h 要請~headerは、
次を指示する
⇒
当の要請は、
早期~data内に伝達された。
`~client$は、
状態s~code `425$st を解する。
◎
The Early-Data request header field indicates that the request has been conveyed in early data and that a client understands the 425 (Too Early) status code.
</p>

<p>
妥当な値は `1^c しかない
— その構文は、
次の~ABNF `ABNF$r により定義される：
◎
It has just one valid value: “1”. Its syntax is defined by the following ABNF [ABNF]:
</p>

<pre class="bnf">
Early-Data = "1"
</pre>

<div class="example">
<p>
例えば：
◎
For example:
</p>

<pre class="lang-http">
GET /resource HTTP/1.0
Host: example.com
Early-Data: 1
</pre>
</div>

<p>
`媒介者$は：
◎
↓</p>
<ul>
	<li>
`~client$との~TLS~handshakeの完了に先立って要請を回送する場合には、［
`1^c に設定した `Early-Data^h ~header
］を伴わせて送信しなければナラナイ
（すなわち，`媒介者$は、
`Early-Data^h ~headerが当の要請~内に無い場合には，それを追加する）。
◎
An intermediary that forwards a request prior to the completion of the TLS handshake with its client MUST send it with the Early-Data header field set to “1” (i.e., it adds it if not present in the request).＼
</li>
	<li>
要請が［
再現の~subjectであったかもしれない場合／【！and】
自身または別の~instanceによりすでに回送されたかもしれない
］場合には，
`Early-Data^h ~headerを利用しなければナラナイ
（ `6.2＠#be-consistent§を見よ）。
◎
An intermediary MUST use the Early-Data header field if the request might have been subject to a replay and might already have been forwarded by it or another instance (see Section 6.2).
</li>
	<li>
`Early-Data^h ~headerが要請~内に在る場合、
それを除去してはナラナイ。
◎
An intermediary MUST NOT remove this header field if it is present in a request.＼
</li>
</ul>

<p>
【`~field名$としての】 `Early-Data^h は、
`Connection$h ~headerの`~field値$に出現してはナラナイ。
◎
Early-Data MUST NOT appear in a Connection header field.
</p>

<p>
`Early-Data^h ~headerは、
`~UA$（すなわち，要請の元の起動元）による利用~用に意図されたものではない。
要請を早期~data内に送信することは、
`~client$は［
この仕様を解する
］かつ［
`425$st 応答に呼応して要請を再試行する用意がある
］ことを含意する。
`~UA$は、
要請を早期~data内に送信する場合でも，
`Early-Data^h ~headerを内包する必要は無い。
◎
The Early-Data header field is not intended for use by user agents (that is, the original initiator of a request). Sending a request in early data implies that the client understands this specification and is willing to retry a request in response to a 425 (Too Early) status code. A user agent that sends a request in early data does not need to include the Early-Data header field.
</p>

<p>
`~server$は、
`Early-Data^h ~headerを包含する要請を［
~handshakeが完了するまで待機することにより，処理しても安全なものに仕立て上げる
］ことはできない。
そのような要請は，
`上流$にある どこかの~hopにて早期~data内に送信されたので、
安全に処理できない場合には，
状態s~code `425$st を利用して却下しなければナラナイ。
◎
A server cannot make a request that contains the Early-Data header field safe for processing by waiting for the handshake to complete. A request that is marked with Early-Data was sent in early data on a previous hop. Requests that contain the Early-Data header field and cannot be safely processed MUST be rejected using the 425 (Too Early) status code.
</p>

<p>
`Early-Data^h ~headerは、
1 ~bitの情報を運ぶ。
`~client$は、
この~headerを複数個~内包してはナラナイ。
`~server$は、［
この~headerが複数個~在る場合には 1 個だけ在る ／
この~headerの値が妥当でない場合には，値 `1^c を伴う
］ものとして扱わなければナラナイ。
◎
The Early-Data header field carries a single bit of information, and clients MUST include at most one instance. Multiple or invalid instances of the header field MUST be treated as equivalent to a single instance with a value of 1 by a server.
</p>

<p>
`Early-Data^h ~headerは、［
応答／`~trailer節$
］内に内包してはナラナイ。
◎
An Early-Data header field MUST NOT be included in responses or request trailers.
</p>

		</section>
		<section id="status">
<h3 title="The 425 (Too Early) Status Code">5.2. 状態s~code `425^st</h3>

<p>
`状態s~code$ `425^st は、
次を指示する
⇒
`~server$は、
再現されたかもしれない要請を処理する~riskをとる用意はない。
◎
A 425 (Too Early) status code indicates that the server is unwilling to risk processing a request that might be replayed.
</p>

<p>
早期~data内に要請を送信する`~UA$は、
対する応答にて `425^st を受信したときは，
当の要請を再試行することが期待される。
`~UA$は，自動的に再試行するベキであるが、
再試行を早期~data内に送信してはナラナイ。
◎
User agents that send a request in early data are expected to retry the request when receiving a 425 (Too Early) response status code. A user agent SHOULD retry automatically, but any retries MUST NOT be sent in early data.
</p>

<p>
`媒介者$は、
すべての事例で，
`425^st0 応答を回送できる。
`媒介者$は、
自身が受信して回送した要請 %要請 に対し，
`425^st0 応答 %応答 を受信したときは：
◎
In all cases, an intermediary can forward a 425 (Too Early) status code.＼
</p>
<ul>
	<li>
%要請 が `Early-Data$h ~headerを包含していた場合には、
%応答 を回送しなければナラナイ。
◎
Intermediaries MUST forward a 425 (Too Early) status code if the request that it received and forwarded contained an Early-Data header field.＼
</li>
	<li>
<p>
他の場合、
早期~data内に受信した %要請 を自動的に再試行してもヨイが，［
%要請 用の接続における~TLS~handshakeが完了する
］まで待機しなければナラナイ。
</p>

<p class="trans-note">【
%要請 が早期~dataの外で受信されたものであった場合に どう挙動するのかは、
述べられていない。
】</p>
◎
Otherwise, an intermediary that receives a request in early data MAY automatically retry that request in response to a 425 (Too Early) status code, but it MUST wait for the TLS handshake to complete on the connection where it received the request.
</li>
</ul>

<p>
`~server$が［
`~client$は要請を再試行-可能である
］と見做せるのは、
当の要請が［
早期~data内に受信された／
`1^c に設定された `Early-Data$h ~headerを伴う
］場合に限られる。
`~server$は、
これらの条件いずれかが満たされない限り，
`425^st0 応答を発するベキでない。
◎
The server cannot assume that a client is able to retry a request unless the request is received in early data or the Early-Data header field is set to “1”. A server SHOULD NOT emit the 425 status code unless one of these conditions is met.
</p>

<p>
`425^st0 応答は、
`経験的に~cache可能$ではない。
その`内容$は、
当の応答が応対した要請の`~target資源$の`表現$ではない。
◎
The 425 (Too Early) status code is not cacheable by default. Its payload is not the representation of any identified resource.
</p>

		</section>
	</section>
	<section id="security-considerations">
<h2 title="Security Considerations">6. ~securityの考慮点</h2>

<p>
早期~dataを利用すると、
`~client$は［
早期~data内の要請が再現される~risk
］に晒される。
［
再試行された要請／再現された要請
］は、
`~server$に対し，【元の要請とは】異なる副作用を生産し得る。
そのような副作用に加えて、［
再試行／再現
］は，［
当の要請／当の要請の`~target資源$
］についての情報を復元するために［
流通~分析~用に利用される
］かもしれない。
特に、［
再現された要請による結果の応答
］は，異なるかもしれない
— そのことは、［
当の`内容$が機密的であり続ける場合
］でも［
保護された~dataの長さから観測-可能になる
］かもしれない。
◎
Using early data exposes a client to the risk that their request is replayed. A retried or replayed request can produce different side effects on the server. In addition to those side effects, replays and retries might be used for traffic analysis to recover information about requests or the resources those requests target. In particular, a request that is replayed might result in a different response, which might be observable from the length of protected data even if the content remains confidential.
</p>

		<section id="gateways-and-early-data">
<h3 title="Gateways and Early Data">6.1. ~gatewayと早期~data</h3>

<p>
`~gateway$は、
早期~data内に受信した要請に対しては：
◎
↓</p>
<ul>
	<li>
その回送-先である`生成元~server$が［
`Early-Data$h ~headerを解する
］かつ［
`425$st 応答を正しく`生成-$することになる
］ことを知っている場合を除き，回送してはナラナイ。
◎
A gateway MUST NOT forward requests that were received in early data unless it knows that the origin server it will forward to understands the Early-Data header field and will correctly generate a 425 (Too Early) status code.＼
</li>
	<li>
`生成元~server$による そのような~supportについて不確かな場合には、［
`~client$との~TLS~handshakeが完了するまで，要請を回送するのを遅延する
］か［
対する応答~内に状態s~code `425$st を送信する
］ベキである。
◎
A gateway that is uncertain about origin server support for a given request SHOULD either delay forwarding the request until the TLS handshake with its client completes or send a 425 (Too Early) status code in response.
</li>
</ul>

<p>
`~gateway$が早期~dataを可能化する労による処理能の便益は、
回送-先になり得る どの`生成元~server$も `Early-Data$h ~headerを~supportしない場合には，
割に合わなくなる。
そのような場合、
早期~dataをまるごと不能化する方が効率的になる。
◎
A gateway without at least one potential origin server that supports the Early-Data header field expends significant effort for what can at best be a modest performance benefit from enabling early data. If no origin server supports early data, it is more efficient to disable early data entirely.
</p>

		</section>
		<section id="be-consistent">
<h3 title="Consistent Handling of Early Data">6.2. 早期~dataの一貫した取扱い</h3>

<p>
早期~data内に到着した（部分的な場合もある）要請に対する一貫した扱いは、
再現された要請の不適切な処理を避けるために~criticalである。
~TLS~handshakeが完了する前に要請を処理するのは安全でない場合、
すべての~server~instance（`~gateway$を含む）が［
要請を却下するのか，その処理を遅延するのか
］について合意する必要がある。
◎
Consistent treatment of a request that arrives in, or partially in, early data is critical to avoiding inappropriate processing of replayed requests. If a request is not safe to process before the TLS handshake completes, then all instances of the server (including gateways) need to agree and either reject the request or delay processing.
</p>

<p>
［
早期~dataを不能化すること,
要請を遅延すること,
要請を `425$st 応答で却下すること
］は、
どれも，［
再現に対し脆弱かもしれない要請に対する再現~攻撃
］を［
軽減するための措置
］として等しく良いものになる。
各~server~instanceは、
これらの措置のうち どれでも実装でき，［
~instanceごとに利用する手法が異なる場合でも，一貫である
］ものと見なされる。
【！critically,】このことは、［
他の条件
— `~server$負荷など —
に対する反応において，いつもと異なる軽減策を使役する
］こともアリであることを意味する。
◎
Disabling early data, delaying requests, or rejecting requests with the 425 (Too Early) status code are all equally good measures for mitigating replay attacks on requests that might be vulnerable to replay. Server instances can implement any of these measures and be considered consistent, even if different instances use different methods. Critically, this means that it is possible to employ different mitigations in reaction to other conditions, such as server load.
</p>

<p>
`~server$は、
早期~dataに対し，［
自身／他の~server~instance
］が［
同じ~dataを取扱う方法
］について［
異なる裁定を為すこともある
］場合には［
~handshakeが完了する前に動作してはナラナイ
］。
◎
A server MUST NOT act on early data before the handshake completes if it and any other server instance could make a different decision about how to handle the same data.
</p>

		</section>
		<section id="denial-of-service">
<h3 title="Denial of Service">6.3. ~DoS</h3>

<p>
早期~dataを受容すると、
`~server$は，［
取扱うには高価な要請の再現
］を通して~DoS攻撃に晒されることにもなり得る。
`~server$は、
負荷が高いときは，［
~TLS早期~dataを まるごと却下する
］ことを選好するベキである
— ［
早期~dataを受容して要請を選択的に処理する
］のではなく。
状態s~code［
`503$st ／ `425$st 
］を`生成-$すると、［
`~client$が要請を再試行する
］よう至らすことが多い
— その結果，負荷も高まり得る。
◎
Accepting early data exposes a server to potential denial of service through the replay of requests that are expensive to handle. A server that is under load SHOULD prefer rejecting TLS early data as a whole rather than accepting early data and selectively processing requests. Generating a 503 (Service Unavailable) or 425 (Too Early) status code often leads to clients retrying requests, which could result in increased load.
</p>

		</section>
		<section id="out-of-order-delivery">
<h3 title="Out-of-Order Delivery">6.4. 順序どおりでない送達</h3>

<p>
~dataを順序どおりに送達しない~protocol（~QUIC `HQ$r など）においては、
早期~dataは，~handshakeが完了した後に到着することもある。
`~server$は、［
他の~server~instanceが同じ要請に対する再現を正しく取扱っている
］ことに依拠できる場合に限り，［
~handshakeを完了した後に早期~data内に受信した要請
］を処理してもヨイ。
◎
In protocols that deliver data out of order (such as QUIC [HQ]), early data can arrive after the handshake completes. A server MAY process requests received in early data after handshake completion only if it can rely on other instances correctly handling replays of the same requests.
</p>

		</section>
	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">7. ~IANA考慮点</h2>

<p>
この文書は、
`恒久的~message~header名~registry＠~IANA-a/message-headers$cite
内に `Early-Data$h ~headerを登録する。
◎
This document registers the Early-Data header field in the “Permanent Message Header Field Names” registry located at &lt;https://www.iana.org/assignments/message-headers&gt;.
</p>
<div>
<ul>
	<li>
~header名
⇒
`Early-Data^h
</li>
	<li>
適用-可能な~protocol
⇒
http
</li>
	<li>
位置付け
⇒
standard
</li>
	<li>
作者／変更~制御者
⇒
IETF
</li>
	<li>
仕様~文書
⇒
この文書
</li>
	<li>
関係する情報
⇒
なし
</li>
</ul>
◎
Header field name:
• Early-Data
Applicable protocol:
• http
Status:
• standard
Author/Change controller:
• IETF
Specification document(s):
• This document
Related information:
• (empty)
</div>

<p>
この文書は、
`~HTTP状態s~code~registry＠~IANA-a/http-status-codes$cite
内に
状態s~code `425$st を登録する。
◎
This document registers the 425 (Too Early) status code in the “HTTP Status Codes” registry located at &lt;https://www.iana.org/assignments/http-status-codes&gt;.
</p>
<div>
<ul>
	<li>
値
⇒
`425$st
</li>
	<li>
記述
⇒
Too Early
</li>
	<li>
参照
⇒
この文書
</li>
</ul>
◎
Value:
• 425
Description:
• Too Early
Reference:
• This document
</div>

	</section>
	<section id="acknowledgments">
<h2 title="Acknowledgments">謝辞</h2>

<p>
この文書の制作は容易でなかった。
次に挙げる方々は、
この文書の品質と完全さに大きく貢献された
⇒
`David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev^en
◎
This document was not easy to produce. The following people made substantial contributions to the quality and completeness of the document: David Benjamin, Subodh Iyengar, Benjamin Kaduk, Ilari Liusavaara, Kazuho Oku, Eric Rescorla, Kyle Rose, and Victor Vasiliev.
</p>

	</section>
</main></div>