[要約] RFC 8164は、HTTP/2のための機会主義的セキュリティに関する規格であり、HTTP/2通信のセキュリティを向上させることを目的としています。
Internet Engineering Task Force (IETF) M. Nottingham
Request for Comments: 8164
Category: Experimental M. Thomson
ISSN: 2070-1721 Mozilla
May 2017
Opportunistic Security for HTTP/2
HTTP / 2の日和見セキュリティ
Abstract
概要
This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.
このドキュメントでは、トランスポート層セキュリティ（TLS）およびHTTP / 2を使用して「http」のURIにアクセスし、広範囲にわたる監視攻撃を緩和する方法について説明します。このメカニズムは「https」URIの代替ではありません。能動的な攻撃に対して脆弱です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8164.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8164で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Goals and Non-goals ........................................3
1.2. Notational Conventions .....................................3
2. Using HTTP URIs over TLS ........................................3
2.1. Alternative Server Opt-In ..................................4
2.2. Interaction with "https" URIs ..............................5
2.3. The "http-opportunistic" Well-Known URI ....................5
3. IANA Considerations .............................................6
4. Security Considerations .........................................7
4.1. Security Indicators ........................................7
4.2. Downgrade Attacks ..........................................7
4.3. Privacy Considerations .....................................7
4.4. Confusion regarding Request Scheme .........................7
4.5. Server Controls ............................................8
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................9
Acknowledgements ...................................................9
Authors' Addresses ................................................10
This document describes a use of HTTP Alternative Services [RFC7838] to decouple the URI scheme from the use and configuration of underlying encryption. It allows an "http" URI [RFC7230] to be accessed using HTTP/2 and Transport Layer Security (TLS) [RFC5246] with Opportunistic Security [RFC7435].
このドキュメントでは、HTTP代替サービス[RFC7838]を使用して、基礎となる暗号化の使用と構成からURIスキームを分離する方法について説明します。 HTTP / 2およびトランスポート層セキュリティ（TLS）[RFC5246]とOpportunistic Security [RFC7435]を使用して、「http」URI [RFC7230]にアクセスできるようにします。
This document describes a usage model whereby sites can serve "http" URIs over TLS, thereby avoiding the problem of serving Mixed Content (described in [W3C.CR-mixed-content-20160802]) while still providing protection against passive attacks.
このドキュメントでは、サイトがTLS経由で「http」URIを提供できる使用モデルについて説明します。これにより、パッシブ攻撃に対する保護を提供しながら、混合コンテンツ（[W3C.CR-mixed-content-20160802]で説明）の提供の問題を回避できます。
Opportunistic Security does not provide the same guarantees as using TLS with "https" URIs, because it is vulnerable to active attacks, and does not change the security context of the connection. Normally, users will not be able to tell that it is in use (i.e., there will be no "lock icon").
Opportunistic Securityは、 "https" URIでTLSを使用する場合と同じ保証を提供しません。これは、アクティブな攻撃に対して脆弱であり、接続のセキュリティコンテキストを変更しないためです。通常、ユーザーはそれが使用中であることを知ることができません（つまり、「ロックアイコン」はありません）。
The immediate goal is to make the use of HTTP more robust in the face of pervasive passive monitoring [RFC7258].
当面の目標は、広範囲にわたるパッシブモニタリングに直面してHTTPの使用をより堅牢にすることです[RFC7258]。
A secondary (but significant) goal is to provide for ease of implementation, deployment, and operation. This mechanism is expected to have a minimal impact upon performance and require trivial administrative effort to configure.
第2の（ただし重要な）目標は、実装、展開、および操作を容易にすることです。このメカニズムは、パフォーマンスへの影響が最小限であり、構成するために簡単な管理作業を必要とすることが予想されます。
Preventing active attacks (such as man-in-the-middle attacks) is a non-goal for this specification. Furthermore, this specification is not intended to replace or offer an alternative to "https", since "https" both prevents active attacks and invokes a more stringent security model in most clients.
アクティブな攻撃（中間者攻撃など）を防止することは、この仕様の目標ではありません。さらに、「https」はアクティブな攻撃を防ぎ、ほとんどのクライアントでより厳格なセキュリティモデルを呼び出すため、この仕様は「https」に代わるものまたはその代替を提供することを意図していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
An origin server that supports the resolution of "http" URIs can indicate support for this specification by providing an alternative service advertisement [RFC7838] for a protocol identifier that uses TLS, such as "h2" [RFC7540]. Such a protocol MUST include an explicit indication of the scheme of the resource. This excludes HTTP/1.1; HTTP/1.1 clients are forbidden from including the absolute form of a URI in requests to origin servers (see Section 5.3.1 of [RFC7230]).
"http" URIの解決をサポートするオリジンサーバーは、 "h2" [RFC7540]などのTLSを使用するプロトコル識別子の代替サービスアドバタイズ[RFC7838]を提供することにより、この仕様のサポートを示すことができます。そのようなプロトコルは、リソースのスキームの明示的な表示を含まなければなりません。これにはHTTP / 1.1は含まれません。 HTTP / 1.1クライアントは、オリジナルサーバーへのリクエストに絶対形式のURIを含めることを禁止されています（[RFC7230]のセクション5.3.1を参照）。
A client that receives such an advertisement MAY make future requests intended for the associated origin [RFC6454] to the identified service (as specified by [RFC7838]), provided that the alternative service opts in as described in Section 2.1.
そのようなアドバタイズを受信するクライアントは、セクション2.1で説明されているように代替サービスがオプトインする場合、識別されたサービス（[RFC7838]で指定）に関連する起点[RFC6454]を対象とした将来のリクエストを行うことができます（MAY）。
A client that places the importance of protection against passive attacks over performance might choose to withhold requests until an encrypted connection is available. However, if such a connection cannot be successfully established, the client can resume its use of the cleartext connection.
パフォーマンスよりもパッシブ攻撃に対する保護を重要視するクライアントは、暗号化された接続が利用可能になるまで要求を保留することを選択する場合があります。ただし、そのような接続を正常に確立できない場合、クライアントはクリアテキスト接続の使用を再開できます。
A client can also explicitly probe for an alternative service advertisement by sending a request that bears little or no sensitive information, such as one with the OPTIONS method. Likewise, clients with existing alternative services information could make such a request before they expire, in order minimize the delays that might be incurred.
クライアントは、OPTIONSメソッドなどの機密情報をほとんどまたはまったく含まないリクエストを送信することで、代替サービスアドバタイズを明示的にプローブすることもできます。同様に、既存の代替サービス情報を持つクライアントは、発生する可能性のある遅延を最小限に抑えるために、有効期限が切れる前にそのような要求を行うことができます。
Client certificates are not meaningful for URLs with the "http" scheme; therefore, clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT present them. A server that also provides "https" resources on the same port can request a certificate during the TLS handshake, but it MUST NOT abort the handshake if the client does not provide one.
クライアント証明書は、「http」スキームのURLには意味がありません。したがって、この仕様の目的で代替サービスへの新しいTLS接続を作成するクライアントは、それらを提示してはなりません。同じポートで「https」リソースも提供するサーバーは、TLSハンドシェイク中に証明書を要求できますが、クライアントがハンドシェイクを提供しない場合は、ハンドシェイクを中止してはなりません。
For various reasons, it is possible that the server might become confused about whether requests' URLs have an "http" or "https" scheme (see Section 4.4). To ensure that the alternative service has opted into serving "http" URLs over TLS, clients are required to perform additional checks before directing "http" requests to it.
さまざまな理由により、リクエストのURLに「http」または「https」のスキームがあるかどうかについてサーバーが混乱する可能性があります（セクション4.4を参照）。代替サービスがTLSを介して「http」URLを提供することを選択したことを確認するために、クライアントは「http」要求をそこに送る前に追加のチェックを実行する必要があります。
Clients MUST NOT send "http" requests over a secured connection, unless the chosen alternative service presents a certificate that is valid for the origin as defined in [RFC2818]. Using an authenticated alternative service establishes "reasonable assurances" for the purposes of [RFC7838]. In addition to authenticating the server, the client MUST have obtained a valid "http-opportunistic" response for an origin (as per Section 2.3) using the authenticated connection. An exception to the latter restriction is made for requests for the "http-opportunistic" well-known URI.
[RFC2818]で定義されているように、選択された代替サービスがオリジンに対して有効な証明書を提示しない限り、クライアントは安全な接続を介して「http」リクエストを送信してはなりません（MUST NOT）。認証済みの代替サービスを使用すると、[RFC7838]の目的で「妥当な保証」が確立されます。サーバーの認証に加えて、クライアントは、認証された接続を使用して、オリジン（セクション2.3による）に対する有効な「http-opportunistic」応答を取得している必要があります。後者の制限の例外は、「http-opportunistic」の既知のURIに対する要求に対して行われます。
For example, assuming the following request is made over a TLS
connection that is successfully authenticated for those origins, the
following request/response pair would allow requests for the origins
"http://www.example.com" or "http://example.com" to be sent using a
secured connection:
HEADERS
+ END_STREAM
+ END_HEADERS
:method = GET
:scheme = http
:authority = example.com
:path = /.well-known/http-opportunistic
HEADERS
:status = 200
content-type = application/json
DATA
+ END_STREAM
[ "http://www.example.com", "http://example.com" ]
This document describes multiple origins, but only for operational convenience. Only a request made to an origin (over an authenticated connection) can be used to acquire the "http-opportunistic" resource for that origin. Thus, in the example, the request to "http://example.com" cannot be assumed to also provide a representation of the "http-opportunistic" resource for "http://www.example.com".
このドキュメントでは、複数のオリジンについて説明していますが、操作上の便宜のためだけです。 （認証された接続を介して）オリジンに対して行われたリクエストのみが、そのオリジンの「http-opportunistic」リソースを取得するために使用できます。したがって、この例では、「http://example.com」への要求は、「http://www.example.com」の「http-opportunistic」リソースの表現も提供するとは想定できません。
Clients MUST NOT send "http" and "https" requests on the same connection. Similarly, clients MUST NOT send "http" requests for multiple origins on the same connection.
クライアントは、同じ接続で「http」と「https」のリクエストを送信してはなりません。同様に、クライアントは同じ接続で複数のオリジンに対して「http」リクエストを送信してはなりません（MUST NOT）。
This specification defines the "http-opportunistic" well-known URI [RFC5785]. A client is said to have a valid "http-opportunistic" response for a given origin when:
この仕様は、「http-opportunistic」のよく知られたURI [RFC5785]を定義しています。次の場合、クライアントは指定されたオリジンに対して有効な「http-opportunistic」応答を持っていると言われます。
o The client has requested the well-known URI from the origin over an authenticated connection and a 200 (OK) response was provided,
o クライアントは認証された接続を介してオリジンから既知のURIを要求し、200（OK）応答が提供されました、
o That response is fresh [RFC7234] (potentially through revalidation [RFC7232]),
o その応答は新鮮です[RFC7234]（潜在的に再検証[RFC7232]による）、
o That response has the media type "application/json",
o その応答のメディアタイプは「application / json」で、
o That response's payload, when parsed as JSON [RFC7159], contains an array as the root, and
o その応答のペイロードは、JSON [RFC7159]として解析された場合、ルートとして配列を含み、
o The array contains a string that is a case-insensitive, character-for-character match for the origin in question, serialized into Unicode as per Section 6.1 of [RFC6454].
o 配列には、[RFC6454]のセクション6.1に従ってUnicodeにシリアル化された、問題の起点に対して大文字と小文字を区別せず、文字ごとに一致する文字列が含まれています。
A client MAY treat an "http-opportunistic" resource as invalid if values it contains are not strings.
クライアントは、「http-opportunistic」リソースに含まれる値が文字列でない場合、それを無効として扱うことができます。
This document does not define semantics for "http-opportunistic" resources on an "https" origin, nor does it define semantics if the resource includes "https" origins.
このドキュメントでは、「https」オリジンの「http-opportunistic」リソースのセマンティクスを定義せず、リソースに「https」オリジンが含まれる場合のセマンティクスも定義しません。
Allowing clients to cache the "http-opportunistic" resource means that all alternative services need to be able to respond to requests for "http" resources. A client is permitted to use an alternative service without acquiring the "http-opportunistic" resource from that service.
クライアントが「http-opportunistic」リソースをキャッシュできるようにすることは、すべての代替サービスが「http」リソースの要求に応答できる必要があることを意味します。クライアントは、そのサービスから「http-opportunistic」リソースを取得せずに代替サービスを使用することが許可されています。
A client MUST NOT use any cached copies of an "http-opportunistic" resource that was acquired (or revalidated) over an unauthenticated connection. To avoid potential errors, a client can request or revalidate the "http-opportunistic" resource before using any connection to an alternative service.
クライアントは、認証されていない接続を介して取得（または再検証）された「http-opportunistic」リソースのキャッシュされたコピーを使用してはなりません（MUST NOT）。潜在的なエラーを回避するために、クライアントは、代替サービスへの接続を使用する前に、「http-opportunistic」リソースを要求または再検証できます。
Clients that use cached "http-opportunistic" responses MUST ensure that their cache is cleared of any responses that were acquired over an unauthenticated connection. Revalidating an unauthenticated response using an authenticated connection does not ensure the integrity of the response.
キャッシュされた「http-opportunistic」応答を使用するクライアントは、認証されていない接続を介して取得された応答がキャッシュから確実にクリアされるようにする必要があります。認証された接続を使用して認証されていない応答を再検証しても、応答の整合性は保証されません。
This specification registers the following well-known URI [RFC5785]:
この仕様は、次の既知のURI [RFC5785]を登録します。
o URI Suffix: http-opportunistic
o URIサフィックス：http-opportunistic
o Change Controller: IETF
o コントローラの変更：IETF
o Specification Document(s): Section 2.3 of RFC 8164
o 仕様書：RFC 8164のセクション2.3
o Related Information:
o 関連情報：
User agents MUST NOT provide any special security indicators when an "http" resource is acquired using TLS. In particular, indicators that might suggest the same level of security as "https" MUST NOT be used (e.g., a "lock device").
TLSを使用して「http」リソースを取得する場合、ユーザーエージェントは特別なセキュリティインジケータを提供してはなりません（MUST NOT）。特に、「https」と同じレベルのセキュリティを示唆する可能性のあるインジケーターは使用してはなりません（たとえば、「ロックデバイス」）。
A downgrade attack against the negotiation for TLS is possible.
TLSのネゴシエーションに対するダウングレード攻撃が可能です。
For example, because the "Alt-Svc" header field [RFC7838] likely appears in an unauthenticated and unencrypted channel, it is subject to downgrade by network attackers. In its simplest form, an attacker that wants the connection to remain in the clear need only strip the "Alt-Svc" header field from responses.
たとえば、「Alt-Svc」ヘッダーフィールド[RFC7838]は認証されていない暗号化されていないチャネルに表示される可能性が高いため、ネットワーク攻撃者によってダウングレードされる可能性があります。最も単純な形式では、接続を平文のままにしたい攻撃者は、応答から「Alt-Svc」ヘッダーフィールドを削除するだけで済みます。
Cached alternative services can be used to track clients over time, e.g., using a user-specific hostname. Clearing the cache reduces the ability of servers to track clients; therefore, clients MUST clear cached alternative service information when clearing other origin-based state (i.e., cookies).
キャッシュされた代替サービスを使用して、たとえばユーザー固有のホスト名を使用するなど、クライアントを長期にわたって追跡できます。キャッシュをクリアすると、サーバーがクライアントを追跡する能力が低下します。したがって、クライアントは、他のオリジンベースの状態（Cookieなど）をクリアするときに、キャッシュされた代替サービス情報をクリアする必要があります。
HTTP implementations and applications sometimes use ambient signals to determine if a request is for an "https" resource; for example, they might look for TLS on the stack or a server port number of 443.
HTTP実装とアプリケーションは、アンビエントシグナルを使用して、リクエストが「https」リソースに対するものかどうかを判断することがあります。たとえば、スタックまたはサーバーポート番号443でTLSを探す場合があります。
This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme, and the resource might have been developed assuming HTTP/1.1), or it may be because of how the server and application are implemented (often, they are two separate entities, with a variety of possible interfaces between them).
これは、プロトコルの予想される制限が原因である可能性があります（最も一般的なHTTP / 1.1リクエストフォームはURIスキームの明示的な表示を含まず、リソースはHTTP / 1.1を想定して開発された可能性があります）、またはその方法が原因である可能性がありますサーバーとアプリケーションが実装されている（多くの場合、これらは2つの別個のエンティティーであり、それらの間にさまざまな可能なインターフェースがあります）。
Any security decisions based upon this information could be misled by the deployment of this specification, because it violates the assumption that the use of TLS (or port 443) means that the client is accessing an HTTPS URI and operating in the security context implied by HTTPS.
TLS（またはポート443）の使用がクライアントがHTTPS URIにアクセスし、HTTPSが暗示するセキュリティコンテキストで動作していることを意味するという仮定に違反するため、この情報に基づくセキュリティ決定は、この仕様の展開によって誤解される可能性があります。 。
Therefore, server implementers and administrators need to carefully examine the use of such signals before deploying this specification.
したがって、サーバーの実装者と管理者は、この仕様を展開する前に、そのような信号の使用を注意深く検討する必要があります。
This specification requires that a server send both an alternative service advertisement and host content in a well-known location to send HTTP requests over TLS. Servers SHOULD take suitable measures to ensure that the content of the well-known resource remains under their control. Likewise, because the "Alt-Svc" header field is used to describe policies across an entire origin, servers SHOULD NOT permit user content to set or modify the value of this header.
この仕様では、TLS経由でHTTPリクエストを送信するために、サーバーが代替サービスアドバタイズメントとホストコンテンツを既知の場所に送信する必要があります。サーバーは、既知のリソースのコンテンツが制御下にあることを保証するために適切な手段を講じるべきです（SHOULD）。同様に、「Alt-Svc」ヘッダーフィールドはオリジン全体のポリシーを説明するために使用されるため、サーバーはユーザーコンテンツがこのヘッダーの値を設定または変更することを許可しないでください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <http://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE. Hammer-Lahav、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<http://www.rfc-editor.org / info / rfc5785>。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, <http://www.rfc-editor.org/info/rfc6454>.
[RFC6454] Barth、A。、「The Web Origin Concept」、RFC 6454、DOI 10.17487 / RFC6454、2011年12月、<http://www.rfc-editor.org/info/rfc6454>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[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>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<http：// www.rfc-editor.org/info/rfc7540>。
[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>.
[RFC7838]ノッティンガム、M。、マクマナス、P。、およびJ.レシュケ、「HTTP Alternative Services」、RFC 7838、DOI 10.17487 / RFC7838、2016年4月、<http://www.rfc-editor.org/info/ rfc7838>。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258] Farrell、S。およびH. Tschofenig、「Pervasive Monitoring Is a Attack」、BCP 188、RFC 7258、DOI 10.17487 / RFC7258、2014年5月、<http://www.rfc-editor.org/info/rfc7258 >。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V。、「日和見セキュリティ：ほとんどの場合はある程度の保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<http://www.rfc-editor.org/info/rfc7435>。
[W3C.CR-mixed-content-20160802] West, M., "Mixed Content", World Wide Web Consortium CR CR-mixed-content-20160802, August 2016, <https://www.w3.org/TR/2016/CR-mixed-content-20160802>.
[W3C.CR-mixed-content-20160802] West、M。、「Mixed Content」、World Wide Web Consortium CR CR-mixed-content-20160802、2016年8月、<https://www.w3.org/TR/ 2016 / CR-mixed-content-20160802>。
Acknowledgements
謝辞
Mike Bishop contributed significant text to this document.
Mike Bishopがこのドキュメントに重要なテキストを寄稿しました。
Thanks to Patrick McManus, Stefan Eissing, Eliot Lear, Stephen Farrell, Guy Podjarny, Stephen Ludin, Erik Nygren, Paul Hoffman, Adam Langley, Eric Rescorla, Julian Reschke, Kari Hurtta, and Richard Barnes for their feedback and suggestions.
パトリック・マクマナス、ステファン・アイシング、エリオット・リア、スティーブン・ファレル、ガイ・ポジャーニー、スティーブン・ルディン、エリック・ナイグレン、ポール・ホフマン、アダム・ラングレー、エリック・レスコーラ、ジュリアン・レシュケ、カリ・ハータ、リチャード・バーンズのフィードバックと提案に感謝します。
Authors' Addresses
著者のアドレス
Mark Nottingham
マーク・ノッティンガム
Email: mnot@mnot.net
URI: https://www.mnot.net/
Martin Thomson Mozilla
マーティン・トムソン・モジラ
Email: martin.thomson@gmail.com