インターネット技術タスクフォース (IETF) M. Nottingham
Request for Comments: 8336 E. Nygren
カテゴリー: Standards Track Akamai
ISSN: 2070-1721 2018年3月

ORIGIN HTTP/2 フレーム

概要

本書は HTTP/2 の ORIGIN フレームを規定し、特定の接続でどのオリジンが利用可能であるかを示す方法を定めます。

本メモの状態

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

この文書は Internet Engineering Task Force (IETF) の成果物です。IETF コミュニティの合意を表しています。公開審査を受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準に関するさらなる情報は RFC 7841 のセクション 2 をご覧ください。

この文書の現状、訂正情報、およびフィードバックの送付方法に関する情報は https://www.rfc-editor.org/info/rfc8336 で入手できます。

Copyright Notice

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.

1. 導入

HTTP/2 [RFC7540] は、 いくつかの条件が満たされる場合にクライアントが異なるオリジン（[RFC6454]）を同じ接続に統合（coalesce）できるようにします。しかし、場合によっては接続が統合されたオリジンに対して使用できないことがあり、そのため 421 (Misdirected Request) ステータスコード（[RFC7540]、Section 9.1.2）が定義されました。

ステータスコードをこのように用いることで、クライアントは誤った宛先へのリクエストから回復できますが、遅延が増えるという代償があります。これに対処するため、本仕様は新しい HTTP/2 フレームタイプ「ORIGIN」を定義し、サーバーがどのオリジンに対して接続が使用可能であるかを示せるようにします。

さらに、実運用の経験から、DNS とサーバーの証明書の両方を使ってサーバーの権限を確立するという HTTP/2 の要件は負担が大きいことが示されています。本仕様は ORIGIN フレーム使用時に DNS チェックの要件を緩和します。これにより、いくつかの DNS ルックアップに伴う遅延が除去されるなどの追加の利点も得られます。

1.1. 表記規約

この文書内のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表示される場合に限り、BCP 14 [RFC2119] と [RFC8174] に記載されているとおりに解釈されます。

2. ORIGIN HTTP/2 フレーム

本書は新しい HTTP/2 フレームタイプ（[RFC7540]、Section 4）である ORIGIN を定義します。これによりサーバーは、接続内でクライアントが Origin Set（Section 2.3）のメンバーとみなすべきオリジン（[RFC6454]）を示すことができます。

2.1. 構文

ORIGIN フレームタイプは 0xc（10 進で 12）であり、0 個以上の Origin-Entry フィールドを含みます。

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Origin-Entry は長さ限定の文字列です：

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

具体的には：

Origin-Len:
ASCII-Origin フィールドの長さ（オクテット単位）を示す符号なし 16 ビット整数。
Origin:
この接続が権威を持つ、または持ち得ると送信者が主張するオリジンの ASCII シリアライゼーション（[RFC6454]、Section 6.2）を含む、OPTIONAL な文字列列。

ORIGIN フレームはフラグを定義しません。ただし、本仕様の将来の更新でフラグが定義される可能性があります。詳細は Section 2.2 を参照してください。

2.2. ORIGIN フレームの処理

ORIGIN フレームは HTTP/2 に対する非クリティカルな拡張です。このフレームをサポートしていないエンドポイントは、受信時に安全に無視できます。

実装されたクライアントが受信すると、Origin Set の初期化および操作に使用されます（Section 2.3参照）。これによりクライアントがオリジンサーバーの権限をどのように確立するかが変わります（Section 2.4参照）。

ORIGIN フレームは stream 0 で送信されなければなりません；stream 0 以外での ORIGIN フレームは無効であり、無視されなければなりません。

同様に、ORIGIN フレームは "h2" プロトコル識別子の接続、またはプロトコル定義で明示的に指定された場合にのみ有効です；"h2c" プロトコル識別子の接続で受信された場合は無視されなければなりません。

本仕様は ORIGIN フレームのフラグを定義しませんが、本仕様の将来の更新（IETF の合意による）でその意味を変更するためにフラグが使われる可能性があります。最初の 4 ビットのフラグ（0x1, 0x2, 0x4, 0x8）は後方互換性を壊す変更のために予約されています；したがって、これらのいずれかがセットされている場合、そのフレームはクライアントによって理解されない限り無視されなければなりません。残りのフラグは後方互換性のある変更のために予約されており、本仕様に準拠するクライアントの処理に影響を与えません。

ORIGIN フレームは接続の特性を記述するため、ホップバイホップで処理されます。仲介者は ORIGIN フレームを転送してはなりません。プロキシを使用するように設定されたクライアントは、そのプロキシから受信した ORIGIN フレームを無視しなければなりません。

フレームのペイロード内の各 ASCII-Origin フィールドは、オリジンの ASCII シリアライゼーションとして解析されなければなりません（[RFC6454]、Section 6.2）。解析に失敗した場合、そのフィールドは無視されなければなりません。

ORIGIN フレームはワイルドカード名（例："*.example.com"）を Origin-Entry でサポートしない点に注意してください。その結果、ワイルドカード証明書を使用している場合に ORIGIN を送信すると、クライアントが ORIGIN を理解する場合には明示的に列挙されていないオリジンが無効化されることになります。

ORIGIN フレームの処理に関する例示的なアルゴリズムは 付録 A を参照してください。

2.3. オリジン集合

ある接続が使用され得るオリジンの集合（[RFC6454] に従う）は、本仕様では Origin Set と呼ばれます。

デフォルトでは、接続の Origin Set は初期化されていません。初期化されていない Origin Set は、クライアントが [RFC7540] の Section 9.1.1 の統合ルールを適用することを意味します。

ORIGIN フレームが最初に受信されクライアントによって正常に処理されると、その接続の Origin Set は初期オリジンを含むように定義されます。初期オリジンは次から構成されます：

  • スキーム: "https"
  • ホスト: Server Name Indication (SNI)（[RFC6066]、Section 3）で送信された値を小文字に変換したもの；SNI がない場合は接続のリモートアドレス（つまりサーバーの IP アドレス）
  • ポート: 接続のリモートポート（つまりサーバーのポート）

その ORIGIN フレーム（およびそれ以降のフレーム）の内容により、サーバーは Origin Set に新しいオリジンを逐次追加することができます（Section 2.2参照）。

Origin Set はまた、[RFC7540] の Section 9.1.2 で定義された 421 (Misdirected Request) レスポンスステータスコードの影響を受けます。このステータスコードを含むレスポンスを受け取った実装クライアントは、対応するリクエストのオリジンの ASCII シリアライゼーション（[RFC6454]、Section 6.2 に従う）を作成し、存在するならば接続の Origin Set からそれを削除しなければなりません。

注記:
代替サービス（[RFC7838]）として初期化された接続に ORIGIN フレームを送信する場合、初期 Origin Set（Section 2.3）には適切なスキームとホスト名を持つオリジンが含まれます（RFC 7838 はオリジンのホスト名が SNI に送られることを規定しているため）。しかし、初期 Origin Set は実際に使用されているポートを用いて計算されるため、意図したオリジンのポートと異なる可能性があります。この場合、意図したオリジンは ORIGIN フレーム内で明示的に送信される必要があります。
例えば、クライアントが "https://example.com" のリクエストを行っていて、代替サービス ("h2", "x.example.net", "8443") に誘導されたとします。この代替サービスが ORIGIN フレームを送ると、初期オリジンは "https://example.com:8443" になります。クライアントは、そのオリジンが ORIGIN フレームに明示的に含まれていない限り、代替サービスを使って "https://example.com" へのリクエストを行うことはできません。

2.4. 権限、プッシュ、および ORIGIN による統合

[RFC7540] の Section 10.1 は、HTTP/1.1 と同様に、接続が権威を持つオリジンサーバーを確立するために DNS と提示された TLS 証明書の両方を使用することを述べています（[RFC7230] 参照）。

さらに、[RFC7540] の Section 9.1.1 は、接続が権威的であれば複数のオリジンサーバーに対して使用できることを明示的に許可しています。これは、直接のリクエストへの応答およびサーバープッシュ（[RFC7540]、Section 8.2.2）に対してどの応答が権威的と見なされるかに影響します。間接的には、クライアントが一般にそのオリジンに対して権威があると信じる接続上でのみリクエストを送るため、どのリクエストが接続上で送信されるかにも影響します。

一度接続の Origin Set が初期化されると、本仕様を実装するクライアントはそれを接続が何に対して権威的であるかを判断するために使用します。具体的には、そのようなクライアントは Origin Set に存在しないオリジンに対して接続を権威的と見なしてはならず（MUST NOT）、接続が権威的である Origin Set 内のオリジンへのすべてのリクエストに対して、運用上の理由で新しい接続を開くべき場合を除き、その接続を使用するべきです（SHOULD）。

ある接続が特定のオリジンに対して権威的であると見なされるためには、サーバーが適切な検査を通過する証明書で認証される必要があることに注意してください。詳細は [RFC7540] の Section 9.1.1 を参照してください。これには証明書の subjectAltName フィールドの dNSName 値とホストを一致させる検証（[RFC2818] に定義されたルール）を含みます；（[RFC5280]、Section 4.2.1.6 も参照）。

さらに、クライアントは Origin Set 内のオリジンに対する新しいリクエストのために DNS を参照することを回避することができます（MAY）。ただし、それを行うクライアントはセクション 4 に記載されたような新たなリスクに直面することになります。

ORIGIN は時間とともに接続が使用されるオリジンの集合を変更できるため、クライアントはある時点でオリジンへの複数の有効な接続を持つことがあり得ます。この場合、クライアントは Origin Set が他の接続の Origin Set の真部分集合である任意の接続上で新しいリクエストを送信すべきでなく（SHOULD NOT）、未処理のリクエストがすべて完了したらその接続を閉じるべきです（SHOULD）。

Origin Set はサーバーが行う代替サービス（[RFC7838]）の広告によって影響を受けません。代替サービスを広告しても、サーバーが権威的であるかどうかには影響しません。

3. IANA の考慮事項

本仕様は "HTTP/2 Frame Type" レジストリにエントリを追加します。

  • Frame Type: ORIGIN
  • Code: 0xc
  • Specification: RFC 8336

4. セキュリティ上の考慮事項

ORIGIN フレームの内容を盲目的に信頼するクライアントは多くの攻撃に対して脆弱になります。緩和策については Section 2.4 を参照してください。

オリジンの権限を決定する際に DNS を参照する要件を緩和することは、有効な証明書を持つ攻撃者がパス上に存在する必要がなくなることを意味します。つまり、DNS を改変する代わりに、攻撃者はユーザーに別のウェブサイトを訪問させるだけで、ターゲットへの接続を自分の既存の接続に統合させることが可能になります。

したがって、DNS を参照しないことを選択するクライアントは、証明書が正当であると高い確信を得るための他の手段を用いるべきです。例えば、クライアントは証明書が Certificate Transparency ログへの包含の証明を受け取った場合にのみ DNS 参照を省略する、あるいは最近の OCSP レスポンス（[RFC6960]）を持っていて証明書が失効していないことを示せる場合に限定するなどの方法があります（"status_request" TLS 拡張（[RFC6066]）を使用する可能性もあります）。

Origin Set のサイズは本仕様では上限を設けていないため、攻撃者がクライアントのリソースを枯渇させるために悪用する可能性があります。このリスクを緩和するため、クライアントは自らの状態負荷を監視し、過大であると判断した場合は接続を切断できます。

5. 参考文献

5.2. 参考資料

[RFC6960]
Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, “X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP”, RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6962]
Laurie, B., Langley, A., and E. Kasper, “Certificate Transparency”, RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC7230]
Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7838]
Nottingham, M., McManus, P., and J. Reschke, “HTTP Alternative Services”, RFC 7838, DOI 10.17487/RFC7838, April 2016, <http://www.rfc-editor.org/info/rfc7838>.
[RFC8288]
Nottingham, M., “Web Linking”, RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.

付録 A. 非規範的処理アルゴリズム

以下のアルゴリズムは、クライアントが受信した ORIGIN フレームをどのように処理できるかを示す例です：

  1. クライアントがその接続に対してプロキシを使うよう設定されている場合、フレームを無視して処理を停止する。
  2. 接続が "h2" プロトコル識別子または本仕様に明示的にオプトインした別のプロトコルで識別されていない場合、フレームを無視して処理を停止する。
  3. フレームが stream 0 以外の任意のストリームで発生した場合、フレームを無視して処理を停止する。
  4. フラグ 0x1, 0x2, 0x4, または 0x8 のいずれかがセットされている場合、フレームを無視して処理を停止する。
  5. 接続上で以前にこのステップに到達した ORIGIN フレームがない場合、Section 2.3 に従って Origin Set を初期化する。
  6. フレームペイロードの各 Origin-Entry について：
    1. ASCII-Origin をオリジンの ASCII シリアライゼーションとして解析し（[RFC6454]、Section 6.2）、結果を parsed_origin とする。解析に失敗した場合、次の Origin-Entry に移る。
    2. parsed_origin を Origin Set に追加する。

付録 B. サーバーの運用上の考慮事項

ORIGIN フレームは、サーバーがある接続をどのオリジンに対して使用すべきかを示すことを可能にします。この機構で広告されるオリジンの集合はサーバーの制御下にあり、サーバーはそれを使用する義務も、応答可能なすべてのオリジンを広告する義務もありません。

例えば、空の ORIGIN フレームを送信することで接続が SNI ベースのオリジンのみに使用されるべきであることをクライアントに通知できます。あるいは、ペイロードを含めることでより多くのオリジンを示すことができます。

一般に、この情報は新しい接続を開始する可能性のあるレスポンスの一部を送信する前に送ることが最も有用です。例えば、"Link" レスポンスヘッダーフィールド（[RFC8288]）やレスポンス本文中のリンクなどが該当します。

したがって、ORIGIN フレームは接続上できるだけ早く、理想的には HEADERS や PUSH_PROMISE フレームの前に送信されるべきです。

ただし、多数のオリジンを接続に関連付けたい場合、それらのサイズによりエンドユーザーが感じる遅延を招く可能性があります。その結果、最初に送信する「コア」オリジン集合を選択し、後続の ORIGIN フレームで接続に使用されるオリジン集合を拡張する（例えば接続がアイドルのときに）必要が生じるかもしれません。

とはいえ、送信者は可能な限り多くのオリジンを単一の ORIGIN フレーム内に含めることが推奨されます。クライアントは接続を動的に生成する判断を行う必要があり、Origin Set が多くのフレームに分割されると動作が最適でなくなる可能性があります。

送信者は、[RFC6454] の Section 4 の手順に従い、ORIGIN ヘッダ内の値はシリアライズ前にケース正規化される必要があることに注意してください。

最後に、代替サービスをホストするサーバー（[RFC7838]）は、接続の初期 Origin Set が（Section 2.3 の規定により）代替サービスのオリジンを含まないため、ORIGIN を送信する際に自分のオリジンを明示的に広告する必要があることに注意してください。

著者の連絡先

Mark Nottingham
EMail: mnot@mnot.net
URI: https://www.mnot.net/
Erik Nygren
Akamai
EMail: nygren@akamai.com