[要約] RFC 8744は、TLS (Transport Layer Security) におけるServer Name Identification (SNI) 暗号化の問題点と要件に焦点を当てた文書です。SNIは、単一のサーバーが複数のドメインをホストする際に、クライアントが接続先のドメイン名をサーバーに伝えるために使用されます。しかし、SNI情報が暗号化されていないと、第三者が通信を監視し、ユーザーのプライバシーを侵害する可能性があります。このRFCは、SNI情報を保護するための暗号化技術の要件を定義し、関連するセキュリティ上の課題を議論します。関連するRFCには、TLS 1.3を定義するRFC 8446などがあります。
Internet Engineering Task Force (IETF) C. Huitema
Request for Comments: 8744 Private Octopus Inc.
Category: Informational July 2020
ISSN: 2070-1721
Issues and Requirements for Server Name Identification (SNI) Encryption in TLS
TLSでのサーバー名識別（SNI）暗号化の問題と要件
Abstract
概要
This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions.
このドキュメントでは、サーバー名識別（SNI）TLSパラメータの暗号化に関する一般的な問題について説明します。提案されたソリューションは、フロントサービスの背後に隠れたサービスを隠し、外部サービスにフロントサービスのSNIを開示するだけです。このドキュメントでは、SNI暗号化に対する既知の攻撃を示し、現在の「HTTPコテナンシー」ソリューションについて説明し、将来のTLSレイヤーソリューションの要件を示します。
In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.
実際には、ソリューションがすべての要件を満たすことができず、実際のソリューションではある程度の妥協が必要になる場合があります。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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 https://www.rfc-editor.org/info/rfc8744.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8744で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（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. History of the TLS SNI Extension 2.1. Unanticipated Usage of SNI Information 2.2. SNI Encryption Timeliness 2.3. End-to-End Alternatives 3. Security and Privacy Requirements for SNI Encryption 3.1. Mitigate Cut-and-Paste Attacks 3.2. Avoid Widely Shared Secrets 3.3. Prevent SNI-Based Denial-of-Service Attacks 3.4. Do Not Stick Out 3.5. Maintain Forward Secrecy 3.6. Enable Multi-party Security Contexts 3.7. Support Multiple Protocols 3.7.1. Hiding the Application-Layer Protocol Negotiation 3.7.2. Supporting Other Transports than TCP 4. HTTP Co-tenancy Fronting 4.1. HTTPS Tunnels 4.2. Delegation Control 4.3. Related Work 5. Security Considerations 6. IANA Considerations 7. Informative References Acknowledgements Author's Address
1. はじめに2. TLS SNI拡張の歴史2.1。 SNI情報の予期しない使用2.2。 SNI暗号化の適時性2.3。エンドツーエンドの代替3. SNI暗号化のセキュリティおよびプライバシー要件3.1。カットアンドペースト攻撃を緩和する3.2。広く共有されている秘密を避ける3.3。 SNIベースのサービス拒否攻撃の防止3.4。 3.5を突き出さないでください。 Forward Secrecy 3.6を維持します。マルチパーティセキュリティコンテキストを有効にする3.7。複数のプロトコルをサポート3.7.1。アプリケーションレイヤープロトコルネゴシエーションの非表示3.7.2。 TCP以外のトランスポートのサポート4. HTTP Co-tenancy Fronting 4.1。 HTTPSトンネル4.2。委任管理4.3。関連研究5.セキュリティに関する考慮事項6. IANAに関する考慮事項7.参考情報謝辞作者のアドレス
Historically, adversaries have been able to monitor the use of web services through three primary channels: looking at DNS requests, looking at IP addresses in packet headers, and looking at the data stream between user and services. These channels are getting progressively closed. A growing fraction of Internet communication is encrypted, mostly using Transport Layer Security (TLS) [RFC8446]. Progressive deployment of solutions like DNS over TLS [RFC7858] and DNS over HTTPS [RFC8484] mitigates the disclosure of DNS information. More and more services are colocated on multiplexed servers, loosening the relation between IP address and web service. For example, in virtual hosting solutions, multiple services can be hosted as co-tenants on the same server, and the IP address and port do not uniquely identify a service. In cloud or Content Delivery Network (CDN) solutions, a given platform hosts the services or servers of a lot of organizations, and looking up what netblock an IP address belongs to reveals little. However, multiplexed servers rely on the Server Name Information (SNI) TLS extension [RFC6066] to direct connections to the appropriate service implementation. This protocol element is transmitted in cleartext. As the other methods of monitoring get blocked, monitoring focuses on the cleartext SNI. The purpose of SNI encryption is to prevent that and aid privacy.
歴史的に、攻撃者は3つの主要なチャネルを通じてWebサービスの使用を監視することができました。DNS要求の確認、パケットヘッダーのIPアドレスの確認、ユーザーとサービス間のデータストリームの確認です。これらのチャネルは徐々に閉鎖されています。インターネット通信の一部が暗号化され、主にトランスポート層セキュリティ（TLS）[RFC8446]を使用しています。 DNS over TLS [RFC7858]やDNS over HTTPS [RFC8484]などのソリューションを段階的に導入すると、DNS情報の開示が軽減されます。ますます多くのサービスが多重化サーバーに配置され、IPアドレスとWebサービスの関係が緩和されています。たとえば、仮想ホスティングソリューションでは、複数のサービスを同じサーバー上のコテナントとしてホストでき、IPアドレスとポートはサービスを一意に識別しません。クラウドまたはコンテンツ配信ネットワーク（CDN）ソリューションでは、特定のプラットフォームが多くの組織のサービスまたはサーバーをホストし、IPアドレスがどのネットブロックに属しているかを調べてもほとんど明らかになりません。ただし、多重化サーバーは、サーバー名情報（SNI）TLS拡張[RFC6066]に依存して、適切なサービス実装への接続を指示します。このプロトコル要素はクリアテキストで送信されます。監視の他の方法がブロックされると、監視はクリアテキストSNIに焦点を当てます。 SNI暗号化の目的は、それを防止してプライバシーを保護することです。
Replacing cleartext SNI transmission by an encrypted variant will improve the privacy and reliability of TLS connections, but the design of proper SNI encryption solutions is difficult. In the past, there have been multiple attempts at defining SNI encryption. These attempts have generally floundered, because the simple designs fail to mitigate several of the attacks listed in Section 3. In the absence of a TLS-level solution, the most popular approach to SNI privacy for web services is HTTP-level fronting, which we discuss in Section 4.
クリアテキストSNI送信を暗号化されたバリアントに置き換えると、TLS接続のプライバシーと信頼性が向上しますが、適切なSNI暗号化ソリューションの設計は困難です。これまで、SNI暗号化を定義する試みは複数ありました。単純な設計ではセクション3に記載されているいくつかの攻撃を緩和できないため、これらの試みは一般に失敗しています。TLSレベルのソリューションがない場合、WebサービスのSNIプライバシーへの最も一般的なアプローチはHTTPレベルの前面です。セクション4で説明します。
This document does not present the design of a solution but provides guidelines for evaluating proposed solutions. (The review of HTTP-level solutions in Section 4 is not an endorsement of these solutions.) The need for related work on the encryption of the Application-Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in Section 3.7.1.
このドキュメントでは、ソリューションの設計については説明しませんが、提案されたソリューションを評価するためのガイドラインを提供します。 （セクション4のHTTPレベルのソリューションのレビューは、これらのソリューションの推奨ではありません。）TLSのアプリケーションレイヤープロトコルネゴシエーション（ALPN）パラメーターの暗号化に関する関連作業の必要性については、セクション3.7.1で説明します。
The SNI extension was specified in 2003 in [RFC3546] to facilitate management of "colocation servers", in which multiple services shared the same IP address. A typical example would be multiple websites served by the same web server. The SNI extension carries the name of a specific server, enabling the TLS connection to be established with the desired server context. The current SNI extension specification can be found in [RFC6066].
SNI拡張は、複数のサービスが同じIPアドレスを共有する「コロケーションサーバー」の管理を容易にするために[RFC3546]で2003年に指定されました。典型的な例は、同じWebサーバーによって提供される複数のWebサイトです。 SNI拡張は特定のサーバーの名前を伝達し、目的のサーバーコンテキストでTLS接続を確立できるようにします。現在のSNI拡張仕様は[RFC6066]にあります。
The SNI specification allowed for different types of server names, though only the "hostname" variant was specified and deployed. In that variant, the SNI extension carries the domain name of the target server. The SNI extension is carried in cleartext in the TLS "ClientHello" message.
SNI仕様ではさまざまなタイプのサーバー名が許可されていましたが、「ホスト名」のバリアントのみが指定およびデプロイされました。このバリアントでは、SNI拡張はターゲットサーバーのドメイン名を伝達します。 SNI拡張は、TLS「ClientHello」メッセージでクリアテキストで伝送されます。
The SNI was defined to facilitate management of servers, but the developers of middleboxes found out that they could take advantage of the information. Many examples of such usage are reviewed in [RFC8404]. Other examples came out during discussions of this document. They include:
SNIはサーバーの管理を容易にするために定義されましたが、ミドルボックスの開発者は情報を利用できることがわかりました。そのような使用法の多くの例は[RFC8404]で見直されます。このドキュメントの議論中に他の例が出てきました。以下が含まれます：
* Filtering or censoring specific services for a variety of reasons
* さまざまな理由で特定のサービスをフィルタリングまたは検閲する
* Content filtering by network operators or ISPs blocking specific websites, for example, to implement parental controls or to prevent access to phishing or other fraudulent websites
* 特定のWebサイトをブロックするネットワークオペレーターまたはISPによるコンテンツフィルタリング。たとえば、ペアレンタルコントロールを実装したり、フィッシングやその他の詐欺Webサイトへのアクセスを防止したりします。
* ISP assigning different QoS profiles to target services
* ISPがターゲットサービスに異なるQoSプロファイルを割り当てる
* Firewalls within enterprise networks blocking websites not deemed appropriate for work
* 企業ネットワーク内のファイアウォールが仕事に適切とは見なされないWebサイトをブロックしている
* Firewalls within enterprise networks exempting specific websites from man-in-the-middle (MITM) inspection, such as healthcare or financial sites for which inspection would intrude on the privacy of employees
* 検査が従業員のプライバシーに侵入するヘルスケアまたは金融サイトなど、特定のWebサイトを中間者（MITM）検査から除外する企業ネットワーク内のファイアウォール
The SNI is probably also included in the general collection of metadata by pervasive surveillance actors [RFC7258], for example, to identify services used by surveillance targets.
SNIは、たとえば、監視対象が使用するサービスを識別するために、広範にわたる監視アクター[RFC7258]によるメタデータの一般的なコレクションにも含まれている可能性があります。
The cleartext transmission of the SNI was not flagged as a problem in the Security Considerations sections of [RFC3546], [RFC4366], or [RFC6066]. These specifications did not anticipate the alternative usage described in Section 2.1. One reason may be that, when these RFCs were written, the SNI information was available through a variety of other means, such as tracking IP addresses, DNS names, or server certificates.
SNIのクリアテキスト送信は、[RFC3546]、[RFC4366]、または[RFC6066]の[セキュリティに関する考慮事項]セクションの問題としてフラグが付けられていませんでした。これらの仕様は、セクション2.1で説明されている代替の使用法を想定していませんでした。これらのRFCが作成されたときに、SNI情報がIPアドレス、DNS名、サーバー証明書の追跡など、他のさまざまな手段を通じて利用可能であったことが1つの理由である可能性があります。
Many deployments still allocate different IP addresses to different services, so that different services can be identified by their IP addresses. However, CDNs commonly serve a large number of services through a comparatively small number of addresses.
多くの展開では、異なるサービスに異なるIPアドレスが割り当てられているため、異なるサービスをIPアドレスで識別できます。ただし、CDNは通常、比較的少数のアドレスを通じて多数のサービスを提供します。
The SNI carries the domain name of the server, which is also sent as part of the DNS queries. Most of the SNI usage described in Section 2.1 could also be implemented by monitoring DNS traffic or controlling DNS usage. But this is changing with the advent of DNS resolvers providing services like DNS over TLS [RFC7858] or DNS over HTTPS [RFC8484].
SNIはサーバーのドメイン名を伝送します。これもDNSクエリの一部として送信されます。セクション2.1で説明されているSNIの使用のほとんどは、DNSトラフィックを監視するか、DNSの使用を制御することでも実装できます。しかし、これはDNS over TLS [RFC7858]やDNS over HTTPS [RFC8484]のようなサービスを提供するDNSリゾルバーの出現で変化しています。
The subjectAltName extension of type dNSName of the server certificate (or in its absence, the common name component) exposes the same name as the SNI. In TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2 [RFC5246], servers send certificates in cleartext, ensuring that there would be limited benefits in hiding the SNI. However, in TLS 1.3 [RFC8446], server certificates are encrypted in transit. Note that encryption alone is insufficient to protect server certificates; see Section 3.1 for details.
サーバー証明書のdNSNameタイプのsubjectAltName拡張（またはそれがない場合は、共通名コンポーネント）は、SNIと同じ名前を公開します。 TLSバージョン1.0 [RFC2246]、1.1 [RFC4346]、および1.2 [RFC5246]では、サーバーはクリアテキストで証明書を送信するため、SNIを非表示にすることで限られた利点があることが保証されます。ただし、TLS 1.3 [RFC8446]では、サーバー証明書は送信中に暗号化されます。暗号化だけではサーバー証明書を保護するには不十分であることに注意してください。詳細については、セクション3.1を参照してください。
The decoupling of IP addresses and server names, deployment of DNS privacy, and protection of server certificate transmissions all contribute to user privacy in the face of an RFC 7258-style adversary [RFC7258]. Encrypting the SNI complements this push for privacy and makes it harder to censor or otherwise provide differential treatment to specific Internet services.
IPアドレスとサーバー名の分離、DNSプライバシーの展開、およびサーバー証明書送信の保護はすべて、RFC 7258スタイルの敵対者[RFC7258]に直面してユーザーのプライバシーに貢献します。 SNIを暗号化することで、このプライバシー保護への取り組みが補完され、特定のインターネットサービスを検閲したり、差別化した扱いをしたりすることが困難になります。
Deploying SNI encryption helps thwart most of the unanticipated SNI usages, including censorship and pervasive surveillance, but it also will break or reduce the efficacy of the operational practices and techniques implemented in middleboxes, as described in Section 2.1. Most of these functions can, however, be realized by other means. For example, some DNS service providers offer customers the provision to "opt in" to filtering services for parental control and phishing protection. Per-stream QoS could be provided by a combination of packet marking and end-to-end agreements. As SNI encryption becomes common, we can expect more deployment of such "end-to-end" solutions.
SNI暗号化を導入すると、検閲や広範囲にわたる監視など、予期しないSNIの使用のほとんどが阻止されますが、セクション2.1で説明されているように、ミドルボックスに実装されている運用慣行や技術の有効性が損なわれたり低下したりします。ただし、これらの機能のほとんどは、他の方法で実現できます。たとえば、一部のDNSサービスプロバイダーは、ペアレンタルコントロールとフィッシング保護のためにフィルターサービスに "オプトイン"するためのプロビジョニングを顧客に提供しています。ストリームごとのQoSは、パケットマーキングとエンドツーエンドの合意の組み合わせによって提供できます。 SNI暗号化が一般的になるにつれて、そのような「エンドツーエンド」ソリューションのさらなる展開が期待できます。
At the time of this writing, enterprises have the option of installing a firewall performing SNI filtering to prevent connections to certain websites. With SNI encryption, this becomes ineffective. Obviously, managers could block usage of SNI encryption in enterprise computers, but this wide-scale blocking would diminish the privacy protection of traffic leaving the enterprise, which may not be desirable. Enterprise managers could rely instead on filtering software and management software deployed on the enterprise's computers.
この記事の執筆時点では、企業はSNIフィルタリングを実行するファイアウォールをインストールして、特定のWebサイトへの接続を防止するオプションを選択できます。 SNI暗号化では、これは効果がなくなります。明らかに、管理者は企業のコンピューターでのSNI暗号化の使用をブロックできますが、この大規模なブロックは、企業を離れるトラフィックのプライバシー保護を低下させるため、望ましくない場合があります。エンタープライズマネージャーは、企業のコンピューターに展開されたフィルタリングソフトウェアと管理ソフトウェアに依存することができます。
Over the past years, there have been multiple proposals to add an SNI encryption option in TLS. A review of the TLS mailing list archives shows that many of these proposals appeared promising but were rejected after security reviews identified plausible attacks. In this section, we collect a list of these known attacks.
過去数年にわたって、TLSにSNI暗号化オプションを追加するための複数の提案がありました。 TLSメーリングリストのアーカイブを確認すると、これらの提案の多くは有望であるように見えましたが、セキュリティレビューでもっともらしい攻撃が特定されたため拒否されました。このセクションでは、これらの既知の攻撃のリストを収集します。
The simplest SNI encryption designs replace the cleartext SNI in the initial TLS exchange with an encrypted value, using a key known to the multiplexed server. Regardless of the encryption used, these designs can be broken by a simple cut-and-paste attack, which works as follows:
最も単純なSNI暗号化設計は、多重化サーバーに既知の鍵を使用して、初期TLS交換のクリアテキストSNIを暗号化された値に置き換えます。使用される暗号化に関係なく、これらの設計は、次のように機能する単純なカットアンドペースト攻撃によって破られる可能性があります。
1. The user starts a TLS connection to the multiplexed server, including an encrypted SNI value.
1. ユーザーは、暗号化されたSNI値を含め、多重化サーバーへのTLS接続を開始します。
2. The adversary observes the exchange and copies the encrypted SNI parameter.
2. 攻撃者は交換を監視し、暗号化されたSNIパラメータをコピーします。
3. The adversary starts its own connection to the multiplexed server, including in its connection parameters the encrypted SNI copied from the observed exchange.
3. 攻撃者は、観測された交換からコピーされた暗号化されたSNIを接続パラメーターに含めて、多重化サーバーへの独自の接続を開始します。
4. The multiplexed server establishes the connection to the protected service, which sends its certificate, thus revealing the identity of the service.
4. 多重化されたサーバーは、保護されたサービスへの接続を確立します。保護されたサービスは証明書を送信し、サービスのIDを明らかにします。
One of the goals of SNI encryption is to prevent adversaries from knowing which hidden service the client is using. Successful cut-and-paste attacks break that goal by allowing adversaries to discover that service.
SNI暗号化の目標の1つは、クライアントが使用している隠しサービスを敵が知ることを防ぐことです。カットアンドペースト攻撃が成功すると、攻撃者がそのサービスを発見できるようになるため、その目標は達成されます。
It is easy to think of simple schemes in which the SNI is encrypted or hashed using a shared secret. This symmetric key must be known by the multiplexed server and by every user of the protected services. Such schemes are thus very fragile, since the compromise of a single user would compromise the entire set of users and protected services.
共有シークレットを使用してSNIが暗号化またはハッシュされる単純なスキームを考えるのは簡単です。この対称鍵は、多重化されたサーバーと保護されたサービスのすべてのユーザーが知っている必要があります。したがって、このようなスキームは非常に脆弱です。1人のユーザーが侵害されると、ユーザー全体と保護されたサービスが侵害されるためです。
Encrypting the SNI may create extra load for the multiplexed server. Adversaries may mount denial-of-service (DoS) attacks by generating random encrypted SNI values and forcing the multiplexed server to spend resources in useless decryption attempts.
SNIを暗号化すると、多重化サーバーに余分な負荷がかかる場合があります。攻撃者は、ランダムな暗号化されたSNI値を生成し、多重化されたサーバーに無用な復号化試行にリソースを費やすことを強制することにより、サービス拒否（DoS）攻撃を仕掛けることがあります。
It may be argued that this is not an important avenue for DoS attacks, as regular TLS connection attempts also require the server to perform a number of cryptographic operations. However, in many cases, the SNI decryption will have to be performed by a front-end component with limited resources, while the TLS operations are performed by the component dedicated to their respective services. SNI-based DoS attacks could target the front-end component.
定期的なTLS接続の試行でもサーバーがいくつかの暗号化操作を実行する必要があるため、これはDoS攻撃の重要な手段ではないと主張される場合があります。ただし、多くの場合、SNI復号化はリソースが制限されたフロントエンドコンポーネントによって実行される必要がありますが、TLS操作はそれぞれのサービス専用のコンポーネントによって実行されます。 SNIベースのDoS攻撃は、フロントエンドコンポーネントを標的にする可能性があります。
In some designs, handshakes using SNI encryption can be easily differentiated from "regular" handshakes. For example, some designs require specific extensions in the ClientHello packets or specific values of the cleartext SNI parameter. If adversaries can easily detect the use of SNI encryption, they could block it, or they could flag the users of SNI encryption for special treatment.
一部の設計では、SNI暗号化を使用したハンドシェイクは、「通常の」ハンドシェイクと簡単に区別できます。たとえば、設計によっては、ClientHelloパケット内の特定の拡張またはクリアテキストSNIパラメータの特定の値が必要です。敵対者がSNI暗号化の使用を簡単に検出できる場合は、それをブロックするか、特別な扱いのためにSNI暗号化のユーザーにフラグを立てることができます。
In the future, it might be possible to assume that a large fraction of TLS handshakes use SNI encryption. If that were the case, the detection of SNI encryption would be a lesser concern. However, we have to assume that, in the near future, only a small fraction of TLS connections will use SNI encryption.
将来的には、TLSハンドシェイクの大部分がSNI暗号化を使用すると想定できるようになる可能性があります。その場合、SNI暗号化の検出はそれほど問題ではありません。ただし、近い将来、TLS接続のごく一部のみがSNI暗号化を使用すると想定する必要があります。
This requirement to not stick out may be difficult to meet in practice, as noted in Section 5.
セクション5で述べたように、この要件が突出しないようにすることは、実際には満たすことが難しい場合があります。
TLS 1.3 [RFC8446] is designed to provide forward secrecy, so that (for example) keys used in past sessions will not be compromised even if the private key of the server is compromised. The general concerns about forward secrecy apply to SNI encryption as well. For example, some proposed designs rely on a public key of the multiplexed server to define the SNI encryption key. If the corresponding private key should be compromised, the adversaries would be able to process archival records of past connections and retrieve the protected SNI used in these connections. These designs fail to maintain forward secrecy of SNI encryption.
TLS 1.3 [RFC8446]は転送秘密を提供するように設計されているため、たとえば、過去のセッションで使用された鍵は、サーバーの秘密鍵が侵害された場合でも侵害されません。前方機密に関する一般的な懸念は、SNI暗号化にも適用されます。たとえば、提案されている一部の設計では、多重化サーバーの公開鍵を使用してSNI暗号化鍵を定義しています。対応する秘密鍵が侵害された場合、攻撃者は過去の接続のアーカイブレコードを処理し、これらの接続で使用されている保護されたSNIを取得することができます。これらの設計では、SNI暗号化の転送秘密を維持できません。
We can design solutions in which a fronting service acts as a relay to reach the protected service. Some of those solutions involve just one TLS handshake between the client and the fronting service. The master secret is verified by verifying a certificate provided by the fronting service but not by the protected service. These solutions expose the client to a MITM attack by the fronting service. Even if the client has some reasonable trust in this service, the possibility of a MITM attack is troubling.
保護されたサービスに到達するための中継としてフロントサービスが機能するソリューションを設計できます。これらのソリューションの一部には、クライアントとフロントサービスの間のTLSハンドシェイクが1つだけ含まれます。マスターシークレットは、保護されたサービスではなく、フロントサービスから提供された証明書を検証することによって検証されます。これらのソリューションは、クライアントをフロントサービスによるMITM攻撃にさらします。クライアントがこのサービスにある程度の信頼を置いている場合でも、MITM攻撃の可能性は厄介です。
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service. These solutions offer more protection against a MITM attack by the fronting service. The downside is that the client will not verify the identity of the fronting service, which enables fronting server spoofing attacks, such as the "honeypot" attack discussed below. Overall, end-to-end TLS to the protected service is preferable, but it is important to also provide a way to authenticate the fronting service.
保護されたサービスによって提供される証明書を検証することによってマスターシークレットが検証されるソリューションの他のクラスがあります。これらのソリューションは、フロントサービスによるMITM攻撃に対する保護を強化します。欠点は、クライアントがフロントサービスのIDを検証しないため、以下で説明する「ハニーポット」攻撃などのフロントサーバースプーフィング攻撃が可能になることです。全体として、保護されたサービスへのエンドツーエンドのTLSが望ましいですが、フロントサービスを認証する方法を提供することも重要です。
The fronting service could be pressured by adversaries. By design, it could be forced to deny access to the protected service or to divulge which client accessed it. But if a MITM attack is possible, the adversaries would also be able to pressure the fronting service into intercepting or spoofing the communications between client and protected service.
前線サービスは敵によって圧迫される可能性があります。設計上、保護されたサービスへのアクセスを拒否したり、アクセスしたクライアントを漏らしたりすることが強制される可能性があります。しかし、MITM攻撃が可能な場合、攻撃者はフロントサービスにクライアントと保護されたサービス間の通信を傍受またはスプーフィングするように圧力をかけることもできます。
Adversaries could also mount an attack by spoofing the fronting service. A spoofed fronting service could act as a "honeypot" for users of hidden services. At a minimum, the fake server could record the IP addresses of these users. If the SNI encryption solution places too much trust on the fronting server, the fake server could also serve fake content of its own choosing, including various forms of malware.
攻撃者は、フロントサービスを偽装して攻撃を仕掛けることもできます。なりすましのフロントサービスは、隠れたサービスのユーザーにとって「ハニーポット」として機能する可能性があります。少なくとも、偽のサーバーはこれらのユーザーのIPアドレスを記録できます。 SNI暗号化ソリューションがフロントサーバーに過度の信頼を置く場合、偽のサーバーは、さまざまな形式のマルウェアを含む、独自に選択した偽のコンテンツも提供する可能性があります。
There are two main channels by which adversaries can conduct this attack. Adversaries can simply try to mislead users into believing that the honeypot is a valid fronting server, especially if that information is carried by word of mouth or in unprotected DNS records. Adversaries can also attempt to hijack the traffic to the regular fronting server, using, for example, spoofed DNS responses or spoofed IP-level routing, combined with a spoofed certificate.
攻撃者がこの攻撃を実行できる2つの主要なチャネルがあります。攻撃者は、ハニーポットが有効なフロントサーバーであるとユーザーに誤解させようとする可能性があります（特に、その情報が口コミや保護されていないDNSレコードに含まれている場合）。攻撃者は、たとえば、偽装されたDNS応答または偽装されたIPレベルのルーティングと偽装された証明書を組み合わせて使用して、通常のフロントサーバーへのトラフィックの乗っ取りを試みることもできます。
The SNI encryption requirement does not stop with HTTP over TLS. Multiple other applications currently use TLS, including, for example, SMTP [RFC3207], DNS [RFC7858], IMAP [RFC8314], and the Extensible Messaging and Presence Protocol (XMPP) [RFC7590]. These applications, too, will benefit from SNI encryption. HTTP-only methods, like those described in Section 4.1, would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling service described in Section 4.1 is compatible with HTTP 1.0 and HTTP 1.1 but interacts awkwardly with the multiple streams feature of HTTP/2 [RFC7540]. This points to the need for an application-agnostic solution, which would be implemented fully in the TLS layer.
SNI暗号化要件は、HTTP over TLSで停止しません。現在、SMTP [RFC3207]、DNS [RFC7858]、IMAP [RFC8314]、Extensible Messaging and Presence Protocol（XMPP）[RFC7590]など、他の複数のアプリケーションがTLSを使用しています。これらのアプリケーションも、SNI暗号化の恩恵を受けます。セクション4.1で説明されているようなHTTPのみのメソッドはここでは適用されません。実際、HTTPSの場合でも、セクション4.1で説明されているHTTPSトンネリングサービスはHTTP 1.0およびHTTP 1.1と互換性がありますが、HTTP / 2 [RFC7540]の複数のストリーム機能と不自然に相互作用します。これは、アプリケーションにとらわれないソリューションの必要性を示しており、TLSレイヤーに完全に実装されます。
The Application-Layer Protocol Negotiation (ALPN) parameters of TLS allow implementations to negotiate the application-layer protocol used on a given connection. TLS provides the ALPN values in cleartext during the initial handshake. While exposing the ALPN does not create the same privacy issues as exposing the SNI, there is still a risk. For example, some networks may attempt to block applications that they do not understand or that they wish users would not use.
TLSのアプリケーション層プロトコルネゴシエーション（ALPN）パラメーターを使用すると、実装は、特定の接続で使用されるアプリケーション層プロトコルをネゴシエートできます。 TLSは、初期ハンドシェイク中にALPN値をクリアテキストで提供します。 ALPNを公開することは、SNIを公開することと同じプライバシー問題を引き起こしませんが、それでもリスクがあります。たとえば、一部のネットワークでは、ユーザーが理解できない、またはユーザーが使用しないことを望むアプリケーションをブロックしようとする場合があります。
In a sense, ALPN filtering could be very similar to the filtering of specific port numbers exposed in some networks. This filtering by ports has given rise to evasion tactics in which various protocols are tunneled over HTTP in order to use open ports 80 or 443. Filtering by ALPN would probably beget the same responses, in which the applications just move over HTTP and only the HTTP ALPN values are used. Applications would not need to do that if the ALPN were hidden in the same way as the SNI.
ある意味で、ALPNフィルタリングは、一部のネットワークで公開されている特定のポート番号のフィルタリングと非常に類似している可能性があります。このポートによるフィルタリングは、オープンポート80または443を使用するために、さまざまなプロトコルがHTTPを介してトンネリングされる回避策を生み出しました。ALPNによるフィルタリングは、おそらく同じ応答を取得します。 ALPN値が使用されます。 ALPNがSNIと同じ方法で隠されている場合、アプリケーションはその必要はありません。
In addition to hiding the SNI, it is thus desirable to also hide the ALPN. Of course, this implies engineering trade-offs. Using the same technique for hiding the ALPN and encrypting the SNI may result in excess complexity. It might be preferable to encrypt these independently.
したがって、SNIを非表示にすることに加えて、ALPNも非表示にすることが望ましいです。もちろん、これはエンジニアリングのトレードオフを意味します。 ALPNの非表示とSNIの暗号化に同じ手法を使用すると、過度に複雑になる可能性があります。これらを個別に暗号化することをお勧めします。
The TLS handshake is also used over other transports, such as UDP with both DTLS [DTLS-1.3] and QUIC [QUIC]. The requirement to encrypt the SNI applies just as well for these transports as for TLS over TCP.
TLSハンドシェイクは、DTLS [DTLS-1.3]とQUIC [QUIC]の両方を備えたUDPなどの他のトランスポートでも使用されます。 SNIを暗号化する要件は、これらのトランスポートにもTLS over TCPと同様に適用されます。
This points to a requirement for SNI encryption mechanisms to also be applicable to non-TCP transports such as DTLS or QUIC.
これは、SNI暗号化メカニズムがDTLSやQUICなどの非TCPトランスポートにも適用できる必要があることを示しています。
In the absence of TLS-level SNI encryption, many sites rely on an "HTTP co-tenancy" solution, often referred to as "domain fronting" [DOMFRONT]. The TLS connection is established with the fronting server, and HTTP requests are then sent over that connection to the hidden service. For example, the TLS SNI could be set to "fronting.example.com" (the fronting server), and HTTP requests sent over that connection could be directed to "hidden.example.com" (accessing the hidden service). This solution works well in practice when the fronting server and the hidden server are "co-tenants" of the same multiplexed server.
TLSレベルのSNI暗号化がない場合、多くのサイトが「HTTP共同テナンシー」ソリューションに依存します。これは、しばしば「ドメインフロントリング」[DOMFRONT]と呼ばれます。 TLS接続がフロントサーバーと確立され、HTTP要求がその接続を介して隠しサービスに送信されます。たとえば、TLS SNIを "fronting.example.com"（フロントサーバー）に設定し、その接続を介して送信されるHTTP要求を "hidden.example.com"（非表示のサービスにアクセスする）に送信できます。このソリューションは、フロントサーバーと隠しサーバーが同じ多重化サーバーの「コテナント」である場合に、実際にうまく機能します。
The HTTP domain fronting solution can be deployed without modification to the TLS protocol and does not require using any specific version of TLS. There are, however, a few issues regarding discovery, client implementations, trust, and applicability:
HTTPドメインフロンティングソリューションは、TLSプロトコルを変更せずに展開でき、特定のバージョンのTLSを使用する必要はありません。ただし、検出、クライアントの実装、信頼、および適用性に関するいくつかの問題があります。
* The client has to discover that the hidden service can be accessed through the fronting server.
* クライアントは、隠しサービスがフロントサーバーからアクセスできることを検出する必要があります。
* The client's browser has to be directed to access the hidden service through the fronting service.
* クライアントのブラウザは、フロントサービスを介して非表示のサービスにアクセスするように指定する必要があります。
* Since the TLS connection is established with the fronting service, the client has no cryptographic proof that the content does, in fact, come from the hidden service. Thus, the solution does not mitigate the context sharing issues described in Section 3.6. Note that this is already the case for co-tenanted sites.
* TLS接続はフロントサービスで確立されているため、クライアントはコンテンツが実際には隠しサービスからのものであることを暗号で証明することができません。したがって、このソリューションは、セクション3.6で説明されているコンテキスト共有の問題を軽減しません。これは既に共同テナントサイトに当てはまることに注意してください。
* Since this is an HTTP-level solution, it does not protect non-HTTP protocols, as discussed in Section 3.7.
* これはHTTPレベルのソリューションであるため、セクション3.7で説明するように、非HTTPプロトコルを保護しません。
The discovery issue is common to most SNI encryption solutions. The browser issue was solved in [DOMFRONT] by implementing domain fronting as a pluggable transport for the Tor browser. The multi-protocol issue can be mitigated by implementing other applications over HTTP, for example, DNS over HTTPS [RFC8484]. The trust issue, however, requires specific developments.
発見の問題は、ほとんどのSNI暗号化ソリューションに共通しています。ブラウザーの問題は、[DOMFRONT]で、Torブラウザーのプラグイン可能なトランスポートとしてドメインフロンティングを実装することで解決されました。マルチプロトコルの問題は、HTTPSを介した他のアプリケーション（DNS over HTTPS [RFC8484]など）を実装することで軽減できます。ただし、信頼の問題には特定の開発が必要です。
The HTTP domain fronting solution places a lot of trust in the fronting server. This required trust can be reduced by tunneling HTTPS in HTTPS, which effectively treats the fronting server as an HTTP proxy. In this solution, the client establishes a TLS connection to the fronting server and then issues an HTTP connect request to the hidden server. This will establish an end-to-end HTTPS-over-TLS connection between the client and the hidden server, mitigating the issues described in Section 3.6.
HTTPドメインのフロントソリューションは、フロントサーバーに多くの信頼を置きます。この必要な信頼は、HTTPSでHTTPSをトンネリングすることによって減らすことができます。これにより、フロントサーバーをHTTPプロキシとして効果的に扱います。このソリューションでは、クライアントはフロントサーバーへのTLS接続を確立してから、隠しサーバーにHTTP接続要求を発行します。これにより、クライアントと隠しサーバーの間にエンドツーエンドのHTTPS-over-TLS接続が確立され、セクション3.6で説明されている問題が軽減されます。
The HTTPS-in-HTTPS solution requires double encryption of every packet. It also requires that the fronting server decrypt and relay messages to the hidden server. Both of these requirements make the implementation onerous.
HTTPS-in-HTTPSソリューションでは、すべてのパケットの二重暗号化が必要です。また、フロントサーバーがメッセージを復号化して非表示サーバーに中継することも必要です。これらの両方の要件により、実装が面倒になります。
Clients would see their privacy compromised if they contacted the wrong fronting server to access the hidden service, since this wrong server could disclose their access to adversaries. This requires a controlled way to indicate which fronting server is acceptable by the hidden service.
不正なフロントサーバーにアクセスして隠しサービスにアクセスすると、クライアントはプライバシーが侵害されたと見なします。これは、この不正なサーバーが敵へのアクセスを公開する可能性があるためです。これには、隠しサービスがどのフロントサーバーを受け入れるかを制御する方法が必要です。
This problem is similar to the "word of mouth" variant of the "fronting server spoofing" attack described in Section 3.6. The spoofing would be performed by distributing fake advice, such as "to reach hidden.example.com, use fake.example.com as a fronting server", when "fake.example.com" is under the control of an adversary.
この問題は、セクション3.6で説明されている「フロントサーバーのなりすまし」攻撃の「口コミ」バリアントに似ています。 「fake.example.com」が攻撃者の制御下にある場合、なりすましは、「hidden.example.comに到達するには、fake.example.comをフロントサーバーとして使用する」などの偽のアドバイスを配布することによって実行されます。
In practice, this attack is well mitigated when the hidden service is accessed through a specialized application. The name of the fronting server can then be programmed in the code of the application. But the attack is harder to mitigate when the hidden service has to be accessed through general-purpose web browsers.
実際には、この攻撃は、特殊なアプリケーションを介して隠しサービスにアクセスすることで軽減されます。次に、フロントサーバーの名前をアプリケーションのコードにプログラムできます。しかし、隠しサービスに汎用Webブラウザーを介してアクセスする必要がある場合、攻撃を緩和するのはより困難です。
There are several proposed solutions to this problem, such as creating a special form of certificate to codify the relation between the fronting and hidden server or obtaining the relation between the hidden and fronting service through the DNS, possibly using DNSSEC, to avoid spoofing. The experiment described in [DOMFRONT] solved the issue by integrating with the Lantern Internet circumvention tool.
この問題に対して提案されている解決策はいくつかあります。たとえば、特別な形式の証明書を作成して、フロントと非表示のサーバー間の関係を体系化したり、DNSを介して非表示とフロントのサービス間の関係を取得したり、DNSSECを使用して、なりすましを回避したりします。 [DOMFRONT]で説明されている実験は、Lanternインターネット迂回ツールと統合することで問題を解決しました。
We can observe that CDNs have a similar requirement. They need to convince the client that "www.example.com" can be accessed through the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs have deployed DNS-based solutions to this problem. However, the CDN often holds the authoritative certificate of the origin. There is, simultaneously, verification of a relationship between the origin and the CDN (through the certificate) and a risk that the CDN can spoof the content from the origin.
CDNにも同様の要件があることがわかります。彼らは、「www.example.com」には一見無関係な「cdn-node-xyz.example.net」を通じてアクセスできることをクライアントに納得させる必要があります。ほとんどのCDNは、この問題に対してDNSベースのソリューションを展開しています。ただし、CDNは多くの場合、発行元の信頼できる証明書を保持しています。同時に、（証明書を介して）発信元とCDNの関係が検証され、CDNが発信元のコンテンツを偽装できるリスクがあります。
The ORIGIN frame defined for HTTP/2 [RFC8336] can be used to flag content provided by the hidden server. Secondary certificate authentication [HTTP2-SEC-CERTS] can be used to manage authentication of hidden server content or to perform client authentication before accessing hidden content.
HTTP / 2 [RFC8336]に定義されているORIGINフレームは、隠しサーバーによって提供されるコンテンツにフラグを付けるために使用できます。セカンダリ証明書認証[HTTP2-SEC-CERTS]を使用して、非表示のサーバーコンテンツの認証を管理したり、非表示のコンテンツにアクセスする前にクライアント認証を実行したりできます。
This document lists a number of attacks against SNI encryption in Sections 3 and 4.2 and presents a list of requirements to mitigate these attacks. Current HTTP-based solutions described in Section 4 only meet some of these requirements. In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises.
このドキュメントでは、セクション3および4.2のSNI暗号化に対する多数の攻撃をリストし、これらの攻撃を緩和するための要件のリストを提示します。セクション4で説明されている現在のHTTPベースのソリューションは、これらの要件の一部のみを満たしています。実際には、ソリューションがすべての要件を満たすことができず、実際のソリューションではある程度の妥協が必要になる場合があります。
In particular, the requirement to not stick out, presented in Section 3.4, may have to be lifted, especially for proposed solutions that could quickly reach large-scale deployments.
特に、セクション3.4で提示されている、突き出さないという要件は、特に大規模な展開にすぐに到達する可能性のある提案されたソリューションでは解除する必要がある場合があります。
Replacing cleartext SNI transmission by an encrypted variant will break or reduce the efficacy of the operational practices and techniques implemented in middleboxes, as described in Section 2.1. As explained in Section 2.3, alternative solutions will have to be developed.
セクション2.1で説明されているように、クリアテキストSNI送信を暗号化されたバリアントに置き換えると、ミドルボックスに実装されている運用慣行と技術の有効性が損なわれるか、または低下します。 2.3節で説明したように、代替ソリューションを開発する必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[DOMFRONT] Fifield, D., Lan, C., Hynes, R., Wegmann, P., and V. Paxson, "Blocking-resistant communication through domain fronting", DOI 10.1515/popets-2015-0009, 2015, <https://www.bamsoftware.com/papers/fronting/>.
[DOMFRONT] Fifield、D.、Lan、C.、Hynes、R.、Wegmann、P。、およびV. Paxson、「ドメインフロインティングによるブロッキング耐性通信」、DOI 10.1515 / popets-2015-0009、2015、< https://www.bamsoftware.com/papers/fronting/>。
[DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-dtls13-38, 29 May 2020, <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
[DTLS-1.3] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「Datagram Transport Layer Security（DTLS）Protocol Version 1.3」、Work in Progress、Internet-Draft、draft-ietf-tls-dtls13- 38、2020年5月29日、<https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>。
[HTTP2-SEC-CERTS] Bishop, M., Sullivan, N., and M. Thomson, "Secondary Certificate Authentication in HTTP/2", Work in Progress, Internet-Draft, draft-ietf-httpbis-http2-secondary-certs-06, 14 May 2020, <https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-06>.
[HTTP2-SEC-CERTS] Bishop、M.、Sullivan、N。、およびM. Thomson、「HTTP / 2での2次証明書認証」、Work in Progress、Internet-Draft、draft-ietf-httpbis-http2-secondary- certs-06、2020年5月14日、<https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-06>。
[QUIC] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-tls-29, 9 June 2020, <https://tools.ietf.org/html/draft-ietf-quic-tls-29>.
[QUIC] Thomson、M。、およびS. Turner、「TLSを使用したQUICの保護」、Work in Progress、Internet-Draft、draft-ietf-quic-tls-29、2020年6月9日、<https：//tools.ietf .org / html / draft-ietf-quic-tls-29>。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>.
[RFC2246] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、DOI 10.17487 / RFC2246、1999年1月、<https://www.rfc-editor.org/info/rfc2246>。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3207] Hoffman、P.、「セキュアSMTP over Transport Layer SecurityのSMTPサービス拡張」、RFC 3207、DOI 10.17487 / RFC3207、2002年2月、<https://www.rfc-editor.org/info/rfc3207>。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, DOI 10.17487/RFC3546, June 2003, <https://www.rfc-editor.org/info/rfc3546>.
[RFC3546] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、DOI 10.17487 / RFC3546、2003年6月、<https://www.rfc-editor.org/info/rfc3546>。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、DOI 10.17487 / RFC4346、2006年4月、<https://www.rfc-editor.org/info / rfc4346>。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.
[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、DOI 10.17487 / RFC4366、2006年4月、<https://www.rfc-editor.org/info/rfc4366>。
[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>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://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月、<https://www.rfc-editor.org/info/rfc7258 >。
[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>。
[RFC7590] Saint-Andre, P. and T. Alkemade, "Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP)", RFC 7590, DOI 10.17487/RFC7590, June 2015, <https://www.rfc-editor.org/info/rfc7590>.
[RFC7590] Saint-Andre、P。およびT. Alkemade、「Extensible Messaging and Presence Protocol（XMPP）でのトランスポート層セキュリティ（TLS）の使用」、RFC 7590、DOI 10.17487 / RFC7590、2015年6月、<https：/ /www.rfc-editor.org/info/rfc7590>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「DNS over Transport Layer Security（TLS）の仕様」、RFC 7858、DOI 10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, <https://www.rfc-editor.org/info/rfc8314>.
[RFC8314]ムーアK.およびC.ニューマン、「廃止されたクリアテキスト：メール送信とアクセスのためのトランスポート層セキュリティ（TLS）の使用」、RFC 8314、DOI 10.17487 / RFC8314、2018年1月、<https：// www。 rfc-editor.org/info/rfc8314>。
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, March 2018, <https://www.rfc-editor.org/info/rfc8336>.
[RFC8336]ノッティンガム、M。およびE.ナイグレン、「The ORIGIN HTTP / 2 Frame」、RFC 8336、DOI 10.17487 / RFC8336、2018年3月、<https://www.rfc-editor.org/info/rfc8336>。
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of Pervasive Encryption on Operators", RFC 8404, DOI 10.17487/RFC8404, July 2018, <https://www.rfc-editor.org/info/rfc8404>.
[RFC8404]モリアーティ、K。、エド。 A.モートン編、「オペレーターに対するパーベイシブ暗号化の影響」、RFC 8404、DOI 10.17487 / RFC8404、2018年7月、<https://www.rfc-editor.org/info/rfc8404>。
[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>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] Hoffman、P。およびP. McManus、「HTTPS経由のDNSクエリ（DoH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https://www.rfc-editor.org/info/rfc8484> 。
Acknowledgements
謝辞
A large part of this document originated in discussion of SNI encryption on the TLS WG mailing list, including comments after the tunneling approach was first proposed in a message to that list: <https://mailarchive.ietf.org/arch/msg/tls/ tXvdcqnogZgqmdfCugrV8M90Ftw>.
このドキュメントの大部分は、TLS WGメーリングリストでのSNI暗号化の議論に端を発し、トンネリングアプローチがそのリストへのメッセージで最初に提案された後のコメントを含みます：<https://mailarchive.ietf.org/arch/msg/ tls / tXvdcqnogZgqmdfCugrV8M90Ftw>。
Thanks to Eric Rescorla for his multiple suggestions, reviews, and edits to the successive draft versions of this document.
このドキュメントの連続したドラフトバージョンに対する複数の提案、レビュー、編集をしてくれたEric Rescorlaに感謝します。
Thanks to Daniel Kahn Gillmor for a pretty detailed review of the initial draft of this document. Thanks to Bernard Aboba, Mike Bishop, Alissa Cooper, Roman Danyliw, Stephen Farrell, Warren Kumari, Mirja Kuelewind, Barry Leiba, Martin Rex, Adam Roach, Meral Shirazipour, Martin Thomson, Eric Vyncke, and employees of the UK National Cyber Security Centre for their reviews. Thanks to Chris Wood, Ben Kaduk, and Sean Turner for helping move this document toward publication.
このドキュメントの最初のドラフトをかなり詳細にレビューしてくれたDaniel Kahn Gillmorに感謝します。 Bernard Aboba、Mike Bishop、Alissa Cooper、Roman Danyliw、Stephen Farrell、Warren Kumari、Mirja Kuelewind、Barry Leiba、Martin Rex、Adam Roach、Meral Shirazipour、Martin Thomson、Eric Vyncke、およびUK National Cyber Security Centerの従業員に感謝彼らのレビューのため。このドキュメントの発行に向けて協力してくれたChris Wood、Ben Kaduk、およびSean Turnerに感謝します。
Author's Address
著者のアドレス
Christian Huitema Private Octopus Inc. Friday Harbor, WA 98250 United States of America
Christian Huitema Private Octopus Inc.フライデーハーバー、ワシントン州98250アメリカ合衆国
Email: huitema@huitema.net