RFC 8740 - Using TLS 1.3 with HTTP/2 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8740.html
タイトル : RFC 8740 - HTTP / 2でのTLS 1.3の使用
翻訳編集 : 自動生成

[要約] RFC 8740は、HTTP/2とTLS 1.3の組み合わせに関するガイドラインです。その目的は、より安全で効率的な通信を実現するために、これらのプロトコルの統合を推進することです。

Internet Engineering Task Force (IETF)                       D. Benjamin
Request for Comments: 8740                                    Google LLC
Updates: 7540                                              February 2020
Category: Standards Track
ISSN: 2070-1721

Using TLS 1.3 with HTTP/2

HTTP / 2でのTLS 1.3の使用

Abstract

概要

This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.

このドキュメントは、既存のTLS 1.2再ネゴシエーション制限に類似したものとして、TLS 1.3ハンドシェイク認証を禁止することによってRFC 7540を更新します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

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). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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 https://www.rfc-editor.org/info/rfc8740.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8740で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
   2.  Requirements Language
   3.  Post-Handshake Authentication in HTTP/2
   4.  Other Post-Handshake TLS Messages in HTTP/2
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Author's Address

1. Introduction

1. はじめに

TLS 1.2 [RFC5246] and earlier versions of TLS support renegotiation, a mechanism for changing parameters and keys partway through a connection. This was sometimes used to implement reactive client authentication in HTTP/1.1 [RFC7230], where the server decides whether or not to request a client certificate based on the HTTP request.

TLS 1.2 [RFC5246]および以前のバージョンのTLSは、接続の途中でパラメーターとキーを変更するメカニズムである再ネゴシエーションをサポートしています。これは、HTTP / 1.1 [RFC7230]でリアクティブクライアント認証を実装するために使用されることがあり、サーバーはHTTPリクエストに基づいてクライアント証明書をリクエストするかどうかを決定します。

HTTP/2 [RFC7540] multiplexes multiple HTTP requests over a single connection, which is incompatible with the mechanism above. Clients cannot correlate the certificate request with the HTTP request that triggered it. Thus, Section 9.2.1 of [RFC7540] forbids renegotiation.

HTTP / 2 [RFC7540]は、上記のメカニズムと互換性のない単一の接続を介して複数のHTTPリクエストを多重化します。クライアントは、証明書要求を、それをトリガーしたHTTP要求と関連付けることはできません。したがって、[RFC7540]のセクション9.2.1は再交渉を禁止しています。

TLS 1.3 [RFC8446] removes renegotiation and replaces it with separate post-handshake authentication and key update mechanisms. Post-handshake authentication has the same problems with multiplexed protocols as TLS 1.2 renegotiation, but the prohibition in [RFC7540] only applies to renegotiation.

TLS 1.3 [RFC8446]は再ネゴシエーションを削除し、それを個別のハンドシェイク後の認証およびキー更新メカニズムに置き換えます。ハンドシェイク後の認証には、TLS 1.2再ネゴシエーションと同じ多重プロトコルの問題がありますが、[RFC7540]の禁止は再ネゴシエーションにのみ適用されます。

This document updates HTTP/2 [RFC7540] to similarly forbid TLS 1.3 post-handshake authentication.

このドキュメントはHTTP / 2 [RFC7540]を更新して、TLS 1.3ハンドシェイク認証を同様に禁止します。

2. Requirements Language

2. 要件言語

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.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. Post-Handshake Authentication in HTTP/2

3. HTTP / 2でのハンドシェイク後の認証

HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages. HTTP/2 clients MUST treat such messages as connection errors (see Section 5.4.1 of [RFC7540]) of type PROTOCOL_ERROR.

HTTP / 2サーバーは、ハンドシェイク後のTLS 1.3 CertificateRequestメッセージを送信してはなりません（MUST NOT）。 HTTP / 2クライアントは、このようなメッセージをタイプPROTOCOL_ERRORの接続エラー（[RFC7540]のセクション5.4.1を参照）として扱う必要があります。

[RFC7540] permitted renegotiation before the HTTP/2 connection preface to provide confidentiality of the client certificate. TLS 1.3 encrypts the client certificate in the initial handshake, so this is no longer necessary. HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateRequest messages before the connection preface.

[RFC7540]クライアント証明書の機密性を提供するために、HTTP / 2接続序文の前に再ネゴシエーションを許可しました。 TLS 1.3は最初のハンドシェイクでクライアント証明書を暗号化するため、これは不要になりました。 HTTP / 2サーバーは、接続の前書きの前に、ハンドシェイク後のTLS 1.3 CertificateRequestメッセージを送信してはなりません（MUST NOT）。

The above applies even if the client offered the "post_handshake_auth" TLS extension. This extension is advertised independently of the selected Application-Layer Protocol Negotiation (ALPN) protocol [RFC7301], so it is not sufficient to resolve the conflict with HTTP/2. HTTP/2 clients that also offer other ALPN protocols, notably HTTP/1.1, in a TLS ClientHello MAY include the "post_handshake_auth" extension to support those other protocols. This does not indicate support in HTTP/2.

上記は、クライアントが "post_handshake_auth" TLS拡張を提供した場合でも適用されます。この拡張機能は、選択したアプリケーションレイヤープロトコルネゴシエーション（ALPN）プロトコル[RFC7301]とは無関係にアドバタイズされるため、HTTP / 2との競合を解決するには不十分です。 TLS ClientHelloで他のALPNプロトコル、特にHTTP / 1.1も提供するHTTP / 2クライアントは、それらの他のプロトコルをサポートするために "post_handshake_auth"拡張を含めることができます（MAY）。これは、HTTP / 2でのサポートを示すものではありません。

4. Other Post-Handshake TLS Messages in HTTP/2

4. HTTP / 2の他のハンドシェイク後のTLSメッセージ

[RFC8446] defines two other messages that are exchanged after the handshake is complete: KeyUpdate and NewSessionTicket.

[RFC8446]は、ハンドシェイクの完了後に交換される他の2つのメッセージ、KeyUpdateとNewSessionTicketを定義しています。

KeyUpdate messages only affect TLS itself and do not require any interaction with the application protocol. HTTP/2 implementations MUST support key updates when TLS 1.3 is negotiated.

KeyUpdateメッセージはTLS自体にのみ影響し、アプリケーションプロトコルとの対話を必要としません。 TLS 1.3がネゴシエートされるとき、HTTP / 2実装はキーの更新をサポートする必要があります。

NewSessionTicket messages are also permitted. Though these interact with HTTP when early data is enabled, these interactions are defined in [RFC8470] and are allowed for in the design of HTTP/2.

NewSessionTicketメッセージも許可されます。初期データが有効になると、これらはHTTPと相互作用しますが、これらの相互作用は[RFC8470]で定義されており、HTTP / 2の設計で許可されています。

Unless the use of a new type of TLS message depends on an interaction with the application-layer protocol, that TLS message can be sent after the handshake completes.

新しいタイプのTLSメッセージの使用がアプリケーション層プロトコルとの相互作用に依存しない限り、ハンドシェイクの完了後にそのTLSメッセージを送信できます。

5. Security Considerations

5. セキュリティに関する考慮事項

This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when supporting post-handshake authentication with HTTP/1.1. This lowers the barrier for deploying TLS 1.3, a major security improvement over TLS 1.2.

このドキュメントは、HTTP / 1.1でハンドシェイク後の認証をサポートする場合のHTTP / 2とTLS 1.3間の互換性の問題を解決します。これにより、TLS 1.2に比べてセキュリティが大幅に向上するTLS 1.3の展開の障壁が低くなります。

6. IANA Considerations

6. IANAに関する考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションはありません。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://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月、<https://www.rfc-editor.org/info / rfc5246>。

[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, <https://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月、<https://www.rfc-editor.org/info/ rfc7230>。

[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「Transport Layer Security（TLS）Application-Layer Protocol Negotiation Extension」、RFC 7301、DOI 10.17487 / RFC7301、2014年7月、< https://www.rfc-editor.org/info/rfc7301>。

[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://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月、<https：// www.rfc-editor.org/info/rfc7540>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。

7.2. Informative References

7.2. 参考引用

[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September 2018, <https://www.rfc-editor.org/info/rfc8470>.

[RFC8470] Thomson、M.、Nottingham、M。、およびW. Tarreau、「HTTPでのEarly Dataの使用」、RFC 8470、DOI 10.17487 / RFC8470、2018年9月、<https://www.rfc-editor.org/ info / rfc8470>。

Author's Address

著者のアドレス

David Benjamin Google LLC

デビッドベンジャミンGoogle LLC

   Email: davidben@google.com