tls E. Rescorla
Internet-Draft RTFM, Inc.
Intended status: Standards Track K. Oku
Expires: 11 April 2024 Fastly
N. Sullivan
C. A. Wood
Cloudflare
9 October 2023
TLS Encrypted Client Hello draft-ietf-tls-esni-17
TLS暗号化されたクライアントHello Draft-ITETF-TLS-ESNI-17
Abstract
概要
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.
このドキュメントでは、サーバーの公開キーの下でクライアントヘロメッセージを暗号化するための輸送層セキュリティ（TLS）のメカニズムについて説明します。
Discussion Venues
ディスカッション会場
This note is to be removed before publishing as an RFC.
このメモは、RFCとして公開する前に削除されます。
Source for this draft and an issue tracker can be found at https://github.com/tlswg/draft-ietf-tls-esni (https://github.com/tlswg/draft-ietf-tls-esni).
このドラフトのソースと問題トラッカーは、https：//github.com/tlswg/draft-ietf-tls-esni（https://github.com/tlswg/draft-ietf-tls-esni）にあります。
Status of This Memo
本文書の位置付け
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
このインターネットドラフトは、BCP 78およびBCP 79の規定に完全に適合して提出されています。
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
インターネットドラフトは、インターネットエンジニアリングタスクフォース（IETF）の作業文書です。他のグループは、作業文書をインターネットドラフトとして配布する場合もあることに注意してください。現在のインターネットドラフトのリストは、https：//datatracker.ietf.org/drafts/current/にあります。
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
インターネットドラフトは、最大6か月間有効なドラフトドキュメントであり、いつでも他のドキュメントに更新、交換、または廃止される場合があります。インターネットドラフトを参照資料として使用したり、「進行中の作業」以外に引用することは不適切です。
This Internet-Draft will expire on 11 April 2024.
このインターネットドラフトは、2024年4月11日に期限切れになります。
Copyright Notice
著作権表示
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Encrypted ClientHello (ECH) . . . . . . . . . . . . . . . 6
4. Encrypted ClientHello Configuration . . . . . . . . . . . . . 7
4.1. Configuration Identifiers . . . . . . . . . . . . . . . . 9
4.2. Configuration Extensions . . . . . . . . . . . . . . . . 9
5. The "encrypted_client_hello" Extension . . . . . . . . . . . 10
5.1. Encoding the ClientHelloInner . . . . . . . . . . . . . . 11
5.2. Authenticating the ClientHelloOuter . . . . . . . . . . . 13
6. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Offering ECH . . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Encrypting the ClientHello . . . . . . . . . . . . . 16
6.1.2. GREASE PSK . . . . . . . . . . . . . . . . . . . . . 17
6.1.3. Recommended Padding Scheme . . . . . . . . . . . . . 18
6.1.4. Determining ECH Acceptance . . . . . . . . . . . . . 19
6.1.5. Handshaking with ClientHelloInner . . . . . . . . . . 19
6.1.6. Handshaking with ClientHelloOuter . . . . . . . . . . 20
6.1.7. Authenticating for the Public Name . . . . . . . . . 21
6.2. GREASE ECH . . . . . . . . . . . . . . . . . . . . . . . 22
7. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Client-Facing Server . . . . . . . . . . . . . . . . . . 23
7.1.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 25
7.2. Backend Server . . . . . . . . . . . . . . . . . . . . . 26
7.2.1. Sending HelloRetryRequest . . . . . . . . . . . . . . 27
8. Compatibility Issues . . . . . . . . . . . . . . . . . . . . 28
8.1. Misconfiguration and Deployment Concerns . . . . . . . . 28
8.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 28
9. Compliance Requirements . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.1. Security and Privacy Goals . . . . . . . . . . . . . . . 29
10.2. Unauthenticated and Plaintext DNS . . . . . . . . . . . 30
10.3. Client Tracking . . . . . . . . . . . . . . . . . . . . 31
10.4. Ignored Configuration Identifiers and Trial
Decryption . . . . . . . . . . . . . . . . . . . . . . 31
10.5. Outer ClientHello . . . . . . . . . . . . . . . . . . . 31
10.6. Related Privacy Leaks . . . . . . . . . . . . . . . . . 32
10.7. Cookies . . . . . . . . . . . . . . . . . . . . . . . . 33
10.8. Attacks Exploiting Acceptance Confirmation . . . . . . . 33
10.9. Comparison Against Criteria . . . . . . . . . . . . . . 34
10.9.1. Mitigate Cut-and-Paste Attacks . . . . . . . . . . . 34
10.9.2. Avoid Widely Shared Secrets . . . . . . . . . . . . 34
10.9.3. Prevent SNI-Based Denial-of-Service Attacks . . . . 34
10.9.4. Do Not Stick Out . . . . . . . . . . . . . . . . . . 35
10.9.5. Maintain Forward Secrecy . . . . . . . . . . . . . . 36
10.9.6. Enable Multi-party Security Contexts . . . . . . . . 36
10.9.7. Support Multiple Protocols . . . . . . . . . . . . . 36
10.10. Padding Policy . . . . . . . . . . . . . . . . . . . . . 37
10.11. Active Attack Mitigations . . . . . . . . . . . . . . . 37
10.11.1. Client Reaction Attack Mitigation . . . . . . . . . 37
10.11.2. HelloRetryRequest Hijack Mitigation . . . . . . . . 38
10.11.3. ClientHello Malleability Mitigation . . . . . . . . 39
10.11.4. ClientHelloInner Packet Amplification Mitigation . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. Update of the TLS ExtensionType Registry . . . . . . . . 41
11.2. Update of the TLS Alert Registry . . . . . . . . . . . . 41
12. ECHConfig Extension Guidance . . . . . . . . . . . . . . . . 41
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
13.1. Normative References . . . . . . . . . . . . . . . . . . 42
13.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Alternative SNI Protection Designs . . . . . . . . . 44
A.1. TLS-layer . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1.1. TLS in Early Data . . . . . . . . . . . . . . . . . . 44
A.1.2. Combined Tickets . . . . . . . . . . . . . . . . . . 45
A.2. Application-layer . . . . . . . . . . . . . . . . . . . . 45
A.2.1. HTTP/2 CERTIFICATE Frames . . . . . . . . . . . . . . 45
Appendix B. Linear-time Outer Extension Processing . . . . . . . 45
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 46
D.1. Since draft-ietf-tls-esni-16 . . . . . . . . . . . . . . 46
D.2. Since draft-ietf-tls-esni-15 . . . . . . . . . . . . . . 46
D.3. Since draft-ietf-tls-esni-14 . . . . . . . . . . . . . . 46
D.4. Since draft-ietf-tls-esni-13 . . . . . . . . . . . . . . 46
D.5. Since draft-ietf-tls-esni-12 . . . . . . . . . . . . . . 46
D.6. Since draft-ietf-tls-esni-11 . . . . . . . . . . . . . . 47
D.7. Since draft-ietf-tls-esni-10 . . . . . . . . . . . . . . 47
D.8. Since draft-ietf-tls-esni-09 . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
DISCLAIMER: This draft is work-in-progress and has not yet seen significant (or really any) security analysis. It should not be used as a basis for building production systems. This published version of the draft has been designated an "implementation draft" for testing and interop purposes.
免責事項：このドラフトは進行中であり、まだ重要な（または実際にはすべての）セキュリティ分析を見ていません。生産システムを構築するための基礎として使用しないでください。このドラフトの公開されたバージョンは、テストと相互作用の目的のための「実装ドラフト」に指定されています。
Although TLS 1.3 [RFC8446] encrypts most of the handshake, including the server certificate, there are several ways in which an on-path attacker can learn private information about the connection. The plaintext Server Name Indication (SNI) extension in ClientHello messages, which leaks the target domain for a given connection, is perhaps the most sensitive, unencrypted information in TLS 1.3.
TLS 1.3 [RFC8446]は、サーバー証明書を含むほとんどの握手を暗号化しますが、オンパス攻撃者が接続に関する個人情報を学ぶことができるいくつかの方法があります。特定の接続のターゲットドメインを漏らすClientHelloメッセージのプレーンテキストサーバー名表示（SNI）拡張機能は、おそらくTLS 1.3で最も敏感で暗号化されていない情報です。
The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses. However, DoH [RFC8484] and DPRIVE [RFC7858] [RFC8094] provide mechanisms for clients to conceal DNS lookups from network inspection, and many TLS servers host multiple domains on the same IP address. Private origins may also be deployed behind a common provider, such as a reverse proxy. In such environments, the SNI remains the primary explicit signal used to determine the server's identity.
ターゲットドメインは、プレーンテキストクライアントDNSクエリや表示可能なサーバーIPアドレスなど、他のチャネルを介して表示される場合があります。ただし、DOH [RFC8484]およびDPRIVE [RFC7858] [RFC8094]は、クライアントがネットワーク検査からDNSルックアップを隠すメカニズムを提供し、多くのTLSサーバーが同じIPアドレスで複数のドメインをホストします。私的な起源は、逆プロキシなどの共通プロバイダーの背後に展開される場合があります。このような環境では、SNIはサーバーのIDを決定するために使用される主要な明示的信号のままです。
This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to such a deployment. This protects the SNI and other potentially sensitive fields, such as the ALPN list [RFC7301]. Co-located servers with consistent externally visible TLS configurations, including supported versions and cipher suites, form an anonymity set. Usage of this mechanism reveals that a client is connecting to a particular service provider, but does not reveal which server from the anonymity set terminates the connection.
このドキュメントは、暗号化されたクライアントHello（ECH）と呼ばれる新しいTLS拡張機能を指定します。これにより、クライアントはClientHelloをそのような展開に暗号化できます。これにより、ALPNリスト[RFC7301]など、SNIおよびその他の潜在的に敏感なフィールドが保護されます。サポートされているバージョンや暗号スイートを含む、一貫した外部で可視されるTLS構成を備えた共同配置サーバーが匿名セットを形成します。このメカニズムを使用すると、クライアントが特定のサービスプロバイダーに接続していることが明らかになりましたが、匿名セットからどのサーバーが接続を終了するかは明らかにしていません。
ECH is supported in TLS 1.3 [RFC8446], DTLS 1.3 [RFC9147], and newer versions of the TLS and DTLS protocols.
ECHは、TLS 1.3 [RFC8446]、DTLS 1.3 [RFC9147]、およびTLSおよびDTLSプロトコルの新しいバージョンでサポートされています。
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. All TLS notation comes from [RFC8446], Section 3.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。すべてのTLS表記は、[RFC8446]、セクション3からのものです。
This protocol is designed to operate in one of two topologies illustrated below, which we call "Shared Mode" and "Split Mode".
このプロトコルは、以下に示す2つのトポロジのいずれかで動作するように設計されており、「共有モード」と「スプリットモード」と呼ばれます。
+---------------------+
| |
| 2001:DB8::1111 |
| |
Client <-----> | private.example.org |
| |
| public.example.com |
| |
+---------------------+
Server
(Client-Facing and Backend Combined)
Figure 1: Shared Mode Topology
図1：共有モードトポロジ
In Shared Mode, the provider is the origin server for all the domains whose DNS records point to it. In this mode, the TLS connection is terminated by the provider.
共有モードでは、プロバイダーは、DNSレコードがそれを指しているすべてのドメインのOrigin Serverです。このモードでは、TLS接続はプロバイダーによって終了します。
+--------------------+ +---------------------+
| | | |
| 2001:DB8::1111 | | 2001:DB8::EEEE |
Client <----------------------------->| |
| public.example.com | | private.example.com |
| | | |
+--------------------+ +---------------------+
Client-Facing Server Backend Server
Figure 2: Split Mode Topology
図2：分割モードトポロジ
In Split Mode, the provider is not the origin server for private domains. Rather, the DNS records for private domains point to the provider, and the provider's server relays the connection back to the origin server, who terminates the TLS connection with the client. Importantly, the service provider does not have access to the plaintext of the connection beyond the unencrypted portions of the handshake.
スプリットモードでは、プロバイダーはプライベートドメインのOrigin Serverではありません。むしろ、プライベートドメインのDNSレコードはプロバイダーを指し、プロバイダーのサーバーは接続をリレーして、クライアントとのTLS接続を終了するOrigin Serverに戻ります。重要なことに、サービスプロバイダーは、握手の暗号化されていない部分を超えて、接続の平文にアクセスできないことです。
In the remainder of this document, we will refer to the ECH-service provider as the "client-facing server" and to the TLS terminator as the "backend server". These are the same entity in Shared Mode, but in Split Mode, the client-facing and backend servers are physically separated.
このドキュメントの残りの部分では、ECHサービスプロバイダーを「クライアント向けサーバー」と呼び、TLSターミネーターを「バックエンドサーバー」と呼びます。これらは共有モードで同じエンティティですが、スプリットモードでは、クライアントの向きサーバーとバックエンドサーバーが物理的に分離されています。
A client-facing server enables ECH by publishing an ECH configuration, which is an encryption public key and associated metadata. The server must publish this for all the domains it serves via Shared or Split Mode. This document defines the ECH configuration's format, but delegates DNS publication details to [HTTPS-RR]. Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured.
クライアント向けサーバーは、暗号化の公開キーと関連するメタデータであるECH構成を公開することにより、ECHを有効にします。サーバーは、共有モードまたはスプリットモードを介して提供するすべてのドメインに対してこれを公開する必要があります。このドキュメントでは、ECH構成の形式を定義しますが、DNS出版物の詳細を[HTTPS-RR]に委任します。他の送達メカニズムも可能です。たとえば、クライアントはECH構成を事前に設定している場合があります。
When a client wants to establish a TLS session with some backend server, it constructs a private ClientHello, referred to as the ClientHelloInner. The client then constructs a public ClientHello, referred to as the ClientHelloOuter. The ClientHelloOuter contains innocuous values for sensitive extensions and an "encrypted_client_hello" extension (Section 5), which carries the encrypted ClientHelloInner. Finally, the client sends ClientHelloOuter to the server.
クライアントがバックエンドサーバーでTLSセッションを確立したい場合、ClientHelloinnerと呼ばれるプライベートクライアントヘロを構築します。クライアントは、ClientHelloouterと呼ばれるPublic ClientHelloを構築します。clienthelloouterには、機密拡張機能の無害な値と、暗号化されたClienthelloinnerを搭載した「encrypted_client_hello」拡張機能（セクション5）が含まれています。最後に、クライアントはclienthelloouterをサーバーに送信します。
The server takes one of the following actions:
サーバーは、次のアクションのいずれかを取得します。
1. If it does not support ECH or cannot decrypt the extension, it completes the handshake with ClientHelloOuter. This is referred to as rejecting ECH.
1. ECHをサポートしていない場合、または拡張機能を解読できない場合、ClientHelloouterで握手が完了します。これは拒否ECHと呼ばれます。
2. If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which completes the handshake. This is referred to as accepting ECH.
2. 拡張機能が正常に復号化された場合、ClientHelloinnerをバックエンドサーバーに転送し、握手が完了します。これは、ECHの受け入れと呼ばれます。
Upon receiving the server's response, the client determines whether or not ECH was accepted (Section 6.1.4) and proceeds with the handshake accordingly. When ECH is rejected, the resulting connection is not usable by the client for application data. Instead, ECH rejection allows the client to retry with up-to-date configuration (Section 6.1.6).
サーバーの応答を受信すると、クライアントはECHが受け入れられたかどうか（セクション6.1.4）かどうかを判断し、それに応じて握手を進めます。ECHが拒否された場合、結果の接続は、アプリケーションデータについてクライアントが使用できません。代わりに、ECH拒絶により、クライアントは最新の構成で再試行できます（セクション6.1.6）。
The primary goal of ECH is to ensure that connections to servers in the same anonymity set are indistinguishable from one another. Moreover, it should achieve this goal without affecting any existing security properties of TLS 1.3. See Section 10.1 for more details about the ECH security and privacy goals.
ECHの主な目標は、同じ匿名セットのサーバーへの接続が互いに区別できないことを確認することです。さらに、TLS 1.3の既存のセキュリティプロパティに影響を与えることなく、この目標を達成する必要があります。ECHセキュリティとプライバシーの目標の詳細については、セクション10.1を参照してください。
ECH uses HPKE for public key encryption [HPKE]. The ECH configuration is defined by the following ECHConfig structure.
ECHは、公開キーの暗号化[HPKE]にHPKEを使用します。ECH構成は、次のECHCONFIG構造によって定義されます。
opaque HpkePublicKey<1..2^16-1>;
uint16 HpkeKemId; // Defined in RFC9180
uint16 HpkeKdfId; // Defined in RFC9180
uint16 HpkeAeadId; // Defined in RFC9180
struct {
HpkeKdfId kdf_id;
HpkeAeadId aead_id;
} HpkeSymmetricCipherSuite;
struct {
uint8 config_id;
HpkeKemId kem_id;
HpkePublicKey public_key;
HpkeSymmetricCipherSuite cipher_suites<4..2^16-4>;
} HpkeKeyConfig;
struct {
HpkeKeyConfig key_config;
uint8 maximum_name_length;
opaque public_name<1..255>;
Extension extensions<0..2^16-1>;
} ECHConfigContents;
struct {
uint16 version;
uint16 length;
select (ECHConfig.version) {
case 0xfe0d: ECHConfigContents contents;
}
} ECHConfig;
The structure contains the following fields:
構造には次のフィールドが含まれています。
version The version of ECH for which this configuration is used. Beginning with draft-08, the version is the same as the code point for the "encrypted_client_hello" extension. Clients MUST ignore any ECHConfig structure with a version they do not support.
バージョンこの構成が使用されるECHのバージョン。ドラフト-08から始まるバージョンは、「encrypted_client_hello」拡張子のコードポイントと同じです。クライアントは、サポートしていないバージョンを使用して、eChConfig構造を無視する必要があります。
length The length, in bytes, of the next field. This length field allows implementations to skip over the elements in such a list where they cannot parse the specific version of ECHConfig.
次のフィールドの長さ、バイト単位の長さ。この長さのフィールドにより、実装は、ECHCONFIGの特定のバージョンを解析できないこのようなリストの要素をスキップできます。
contents An opaque byte string whose contents depend on the version. For this specification, the contents are an ECHConfigContents structure.
内容内容がバージョンに依存する不透明なバイト文字列。この仕様では、内容はeChConfigContents構造です。
The ECHConfigContents structure contains the following fields:
eChConfigContents構造には、次のフィールドが含まれています。
key_config A HpkeKeyConfig structure carrying the configuration information associated with the HPKE public key. Note that this structure contains the config_id field, which applies to the entire ECHConfigContents.
key_config hpkeの公開キーに関連付けられた構成情報を運ぶhpkekeyconfig構造。この構造には、eChConfigContents全体に適用されるconfig_idフィールドが含まれていることに注意してください。
maximum_name_length The longest name of a backend server, if known. If not known, this value can be set to zero. It is used to compute padding (Section 6.1.3) and does not constrain server name lengths. Names may exceed this length if, e.g., the server uses wildcard names or added new names to the anonymity set.
Maximum_name_length既知の場合、バックエンドサーバーの最長名。不明な場合、この値はゼロに設定できます。パディング（セクション6.1.3）の計算に使用され、サーバー名の長さを制約しません。たとえば、サーバーがワイルドカード名を使用するか、匿名セットに新しい名前を追加した場合、名前はこの長さを超える場合があります。
public_name The DNS name of the client-facing server, i.e., the entity trusted to update the ECH configuration. This is used to correct misconfigured clients, as described in Section 6.1.6.
public_nameクライアント向けサーバーのDNS名、つまりECH構成の更新と信頼されているエンティティ。これは、セクション6.1.6で説明されているように、誤ったクライアントを修正するために使用されます。
Clients MUST ignore any ECHConfig structure whose public_name is not parsable as a dot-separated sequence of LDH labels, as defined in [RFC5890], Section 2.3.1 or which begins or end with an ASCII dot.
クライアントは、[RFC5890]、セクション2.3.1で定義されている、またはASCII DOTで始まるまたは終了するように、public_nameがLDHラベルのドット分離されたシーケンスとして解析できないeChConfig構造を無視する必要があります。
Clients SHOULD ignore the ECHConfig if it contains an encoded IPv4 address. To determine if a public_name value is an IPv4 address, clients can invoke the IPv4 parser algorithm in [WHATWG-IPV4]. It returns a value when the input is an IPv4 address.
エンコードされたIPv4アドレスが含まれている場合、クライアントはECHCONFIGを無視する必要があります。public_name値がIPv4アドレスであるかどうかを判断するために、クライアントは[whatwg-ipv4]でIPv4パーサーアルゴリズムを呼び出すことができます。入力がIPv4アドレスである場合、値を返します。
See Section 6.1.7 for how the client interprets and validates the public_name.
クライアントがpublic_nameを解釈および検証する方法については、セクション6.1.7を参照してください。
extensions A list of extensions that the client must take into consideration when generating a ClientHello message. These are described below (Section 4.2).
拡張クライアントHelloメッセージを生成するときにクライアントが考慮しなければならない拡張機能のリスト。これらについては、以下に説明します（セクション4.2）。
[[OPEN ISSUE: determine if clients should enforce a 63-octet label limit for public_name]] [[OPEN ISSUE: fix reference to WHATWG-IPV4]]
[[Open Issue：クライアントがpublic_nameの63-OCTETラベルの制限を実施する必要があるかどうかを判断]
The HpkeKeyConfig structure contains the following fields:
hpkekeyconfig構造には、次のフィールドが含まれています。
config_id A one-byte identifier for the given HPKE key configuration. This is used by clients to indicate the key used for ClientHello encryption. Section 4.1 describes how client-facing servers allocate this value.
config_id指定されたHPKEキー構成の1バイト識別子。これは、クライアントヘロ暗号化に使用されるキーを示すためにクライアントが使用します。セクション4.1では、クライアント向けサーバーがこの値を割り当てる方法について説明します。
kem_id The HPKE KEM identifier corresponding to public_key. Clients MUST ignore any ECHConfig structure with a key using a KEM they do not support.
kem_id public_keyに対応するhpke kem識別子。クライアントは、サポートしていないKEMを使用してキーを使用して、eChConfig構造を無視する必要があります。
public_key The HPKE public key used by the client to encrypt ClientHelloInner.
public_key clienthelloinnerを暗号化するためにクライアントが使用するHPKE公開キー。
cipher_suites The list of HPKE KDF and AEAD identifier pairs clients can use for encrypting ClientHelloInner. See Section 6.1 for how clients choose from this list.
cipher_suites HPKE KDFおよびAEAD識別子ペアのリストは、クライアントHelloInnerの暗号化に使用できます。クライアントがこのリストからどのように選択するかについては、セクション6.1を参照してください。
The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.
クライアント向けサーバーは、次のようにシリアル化されたクライアントに一連のECH構成を宣伝します。
ECHConfig ECHConfigList<1..2^16-1>;
The ECHConfigList structure contains one or more ECHConfig structures in decreasing order of preference. This allows a server to support multiple versions of ECH and multiple sets of ECH parameters.
eChConfiglist構造には、優先順位の減少に1つ以上のECHCONFIG構造が含まれています。これにより、サーバーはECHの複数のバージョンと複数のECHパラメーターセットをサポートできます。
A client-facing server has a set of known ECHConfig values, with corresponding private keys. This set SHOULD contain the currently published values, as well as previous values that may still be in use, since clients may cache DNS records up to a TTL or longer.
クライアント向けサーバーには、対応するプライベートキーを持つ既知のeChConfig値のセットがあります。このセットには、現在公開されている値と、まだ使用されている以前の値が含まれている必要があります。これは、クライアントがDNSレコードをTTL以上にキャッシュすることができるためです。
Section 7.1 describes a trial decryption process for decrypting the ClientHello. This can impact performance when the client-facing server maintains many known ECHConfig values. To avoid this, the client-facing server SHOULD allocate distinct config_id values for each ECHConfig in its known set. The RECOMMENDED strategy is via rejection sampling, i.e., to randomly select config_id repeatedly until it does not match any known ECHConfig.
セクション7.1では、clienthelloを復号化するための試行復号化プロセスについて説明します。これは、クライアント向けサーバーが多くの既知のECHCONFIG値を維持する場合、パフォーマンスに影響を与える可能性があります。これを回避するために、クライアント向けサーバーは、既知のセットの各eChConfigの個別のconfig_id値を割り当てる必要があります。推奨される戦略は、拒否サンプリングを介して、つまり、既知のeChConfigと一致しないまでconfig_idを繰り返し選択することです。
It is not necessary for config_id values across different client-facing servers to be distinct. A backend server may be hosted behind two different client-facing servers with colliding config_id values without any performance impact. Values may also be reused if the previous ECHConfig is no longer in the known set.
異なるクライアント向けサーバーのconfig_id値が異なることは必要ありません。バックエンドサーバーは、パフォーマンスに影響を与えずにCONFIG_ID値を衝突させる2つの異なるクライアント向けサーバーの背後にホストされる場合があります。以前のeChConfigが既知のセットにない場合、値は再利用される場合があります。
ECH configuration extensions are used to provide room for additional functionality as needed. See Section 12 for guidance on which types of extensions are appropriate for this structure.
ECH構成拡張機能は、必要に応じて追加の機能の余地を提供するために使用されます。この構造に適切な拡張機能のガイダンスについては、セクション12を参照してください。
The format is as defined in [RFC8446], Section 4.2. The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block. An extension can be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.
この形式は、[RFC8446]、セクション4.2で定義されています。同じ解釈ルールが適用されます：拡張機能は任意の順序で表示される場合がありますが、拡張ブロックに同じタイプの拡張機能が複数ある必要があります。拡張機能は、高次ビットを1に設定した拡張型型CodePointを使用することにより、必須としてタグ付けできます。
Clients MUST parse the extension list and check for unsupported mandatory extensions. If an unsupported mandatory extension is present, clients MUST ignore the ECHConfig.
クライアントは、拡張リストを解析し、サポートされていない必須拡張機能を確認する必要があります。サポートされていない必須拡張機能が存在する場合、クライアントはeChConfigを無視する必要があります。
To offer ECH, the client sends an "encrypted_client_hello" extension in the ClientHelloOuter. When it does, it MUST also send the extension in ClientHelloInner.
ECHを提供するために、クライアントはclienthelloouterで「encrypted_client_hello」拡張子を送信します。それが行われた場合、それはまた、clienthelloinnerで拡張機能を送信する必要があります。
enum {
encrypted_client_hello(0xfe0d), (65535)
} ExtensionType;
The payload of the extension has the following structure:
拡張機能のペイロードには、次の構造があります。
enum { outer(0), inner(1) } ECHClientHelloType;
struct {
ECHClientHelloType type;
select (ECHClientHello.type) {
case outer:
HpkeSymmetricCipherSuite cipher_suite;
uint8 config_id;
opaque enc<0..2^16-1>;
opaque payload<1..2^16-1>;
case inner:
Empty;
};
} ECHClientHello;
The outer extension uses the outer variant and the inner extension uses the inner variant. The inner extension has an empty payload. The outer extension has the following fields:
外側の拡張は外側のバリアントを使用し、内側の延長は内側のバリアントを使用します。内側の拡張機能には空のペイロードがあります。外側の拡張機能には次のフィールドがあります。
config_id The ECHConfigContents.key_config.config_id for the chosen ECHConfig.
config_id選択したechconfigのechconfigcontents.key_config.config_id。
cipher_suite The cipher suite used to encrypt ClientHelloInner. This MUST match a value provided in the corresponding ECHConfigContents.cipher_suites list.
cipher_suite cipherスイートは、clienthelloinnerを暗号化するために使用されていました。これは、対応するeChConfigContents.cipher_suitesリストで提供される値と一致する必要があります。
enc The HPKE encapsulated key, used by servers to decrypt the corresponding payload field. This field is empty in a ClientHelloOuter sent in response to HelloRetryRequest.
対応するペイロードフィールドを復号化するためにサーバーが使用するHPKEカプセル化キーをencします。このフィールドは、HelloretryRequestに応じて送信されたclienthelloouterで空です。
payload The serialized and encrypted ClientHelloInner structure, encrypted using HPKE as described in Section 6.1.
セクション6.1で説明されているように、HPKEを使用して暗号化されたシリアル化および暗号化されたClientHelloinner構造をペイロードします。
When a client offers the outer version of an "encrypted_client_hello" extension, the server MAY include an "encrypted_client_hello" extension in its EncryptedExtensions message, as described in Section 7.1, with the following payload:
クライアントが「encrypted_client_hello」拡張機能の外側バージョンを提供する場合、サーバーには、セクション7.1で説明されているように、次のペイロードを使用して、暗号化されたedextensionsメッセージに「necrypted_client_hello」拡張機能を含めることができます。
struct {
ECHConfigList retry_configs;
} ECHEncryptedExtensions;
The response is valid only when the server used the ClientHelloOuter. If the server sent this extension in response to the inner variant, then the client MUST abort with an "unsupported_extension" alert.
応答は、サーバーがclienthelloouterを使用した場合にのみ有効です。サーバーが内側のバリアントに応じてこの拡張機能を送信した場合、クライアントは「unsupported_extension」アラートで中止する必要があります。
retry_configs An ECHConfigList structure containing one or more ECHConfig structures, in decreasing order of preference, to be used by the client as described in Section 6.1.6. These are known as the server's "retry configurations".
retry_configsセクション6.1.6で説明されているように、クライアントが使用する、優先順位を減らすために、1つ以上のeChConfig構造を含むエクコンフィグリスト構造を含む。これらは、サーバーの「再試行構成」として知られています。
Finally, when the client offers the "encrypted_client_hello", if the payload is the inner variant and the server responds with HelloRetryRequest, it MUST include an "encrypted_client_hello" extension with the following payload:
最後に、クライアントが「encrypted_client_hello」を提供する場合、ペイロードが内側のバリアントであり、サーバーがhelloretryrequestで応答する場合、次のペイロードを含む「encrypted_client_hello」拡張機能を含める必要があります。
struct {
opaque confirmation[8];
} ECHHelloRetryRequest;
The value of ECHHelloRetryRequest.confirmation is set to hrr_accept_confirmation as described in Section 7.2.1.
echhelloretretyRequest.confirmationの値は、セクション7.2.1で説明されているように、HRR_ACCEPT_CONFIRMATIONに設定されています。
This document also defines the "ech_required" alert, which the client MUST send when it offered an "encrypted_client_hello" extension that was not accepted by the server. (See Section 11.2.)
このドキュメントでは、「ech_required」アラートも定義します。これは、サーバーが受け入れられなかった「necrypted_client_hello」拡張機能を提供したときにクライアントが送信する必要があります。（セクション11.2を参照してください。）
Before encrypting, the client pads and optionally compresses ClientHelloInner into a EncodedClientHelloInner structure, defined below:
暗号化する前に、クライアントはclienthelloinnerをパッドにパッドし、以下に定義するEncodedClientHelloinner構造に圧縮します。
struct {
ClientHello client_hello;
uint8 zeros[length_of_padding];
} EncodedClientHelloInner;
The client_hello field is computed by first making a copy of ClientHelloInner and setting the legacy_session_id field to the empty string. Note this field uses the ClientHello structure, defined in Section 4.1.2 of [RFC8446] which does not include the Handshake structure's four byte header. The zeros field MUST be all zeroes.
client_helloフィールドは、最初にclienthelloinnerのコピーを作成し、regacy_session_idフィールドを空の文字列に設定することによって計算されます。注このフィールドは、[RFC8446]のセクション4.1.2で定義されているClientHello構造を使用します。これには、ハンドシェイク構造の4バイトヘッダーが含まれていません。Zerosフィールドはすべてゼロでなければなりません。
Repeating large extensions, such as "key_share" with post-quantum algorithms, between ClientHelloInner and ClientHelloOuter can lead to excessive size. To reduce the size impact, the client MAY substitute extensions which it knows will be duplicated in ClientHelloOuter. It does so by removing and replacing extensions from EncodedClientHelloInner with a single "ech_outer_extensions" extension, defined as follows:
QuirnHelloinnerとclienthelloouterの間で、ポストカントムアルゴリズムを使用して「key_share」などの大規模な拡張機能を繰り返すと、過度のサイズにつながる可能性があります。サイズの影響を減らすために、クライアントはClientHelloouterで複製されることがわかっている拡張機能を置き換える場合があります。EncodedClientHelloInnerから拡張機能を削除および交換することにより、次のように定義された単一の「ECH_OUTER_EXTENSIONS」拡張機能で次のように置き換えます。
enum {
ech_outer_extensions(0xfd00), (65535)
} ExtensionType;
ExtensionType OuterExtensions<2..254>;
OuterExtensions contains the removed ExtensionType values. Each value references the matching extension in ClientHelloOuter. The values MUST be ordered contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST be inserted in the corresponding position in EncodedClientHelloInner. Additionally, the extensions MUST appear in ClientHelloOuter in the same relative order. However, there is no requirement that they be contiguous. For example, OuterExtensions may contain extensions A, B, C, while ClientHelloOuter contains extensions A, D, B, C, E, F.
outourextensionsには、削除されたextensionType値が含まれています。各値は、clienthelloouterの一致する拡張機能を参照します。値はclienthelloinnerで連続的に順序付けられる必要があり、「ech_outer_extensions」拡張子をencodedclienthelloinnerの対応する位置に挿入する必要があります。さらに、拡張機能は同じ相対順序でclienthelloouterに表示される必要があります。ただし、それらが隣接するという要件はありません。たとえば、outerextensionsには拡張機能a、b、cが含まれている場合がありますが、clienthelloouterには拡張機能a、d、b、c、e、fが含まれます。
The "ech_outer_extensions" extension can only be included in EncodedClientHelloInner, and MUST NOT appear in either ClientHelloOuter or ClientHelloInner.
「ech_outer_extensions」拡張機能は、ecodedclienthelloinnerにのみ含めることができ、clienthelloouterまたはclienthelloinnerに表示されないでください。
Finally, the client pads the message by setting the zeros field to a byte string whose contents are all zeros and whose length is the amount of padding to add. Section 6.1.3 describes a recommended padding scheme.
最後に、クライアントは、内容物がすべてゼロであり、その長さが追加するパディングの量であるバイト文字列にゼロフィールドを設定することにより、メッセージをパッドします。セクション6.1.3では、推奨されるパディングスキームについて説明します。
The client-facing server computes ClientHelloInner by reversing this process. First it parses EncodedClientHelloInner, interpreting all bytes after client_hello as padding. If any padding byte is non-zero, the server MUST abort the connection with an "illegal_parameter" alert.
クライアント向けサーバーは、このプロセスを逆転させることにより、ClientHelloinnerを計算します。最初に、client_helloの後にすべてのバイトをパディングとして解釈し、エンコードされたclienthelloinnerを解析します。パディングバイトがゼロでない場合、サーバーは「Illegal_Parameter」アラートとの接続を中止する必要があります。
Next it makes a copy of the client_hello field and copies the legacy_session_id field from ClientHelloOuter. It then looks for an "ech_outer_extensions" extension. If found, it replaces the extension with the corresponding sequence of extensions in the ClientHelloOuter. The server MUST abort the connection with an "illegal_parameter" alert if any of the following are true:
次に、client_helloフィールドのコピーを作成し、clienthelloouterからregacy_session_idフィールドをコピーします。次に、「ech_outer_extensions」拡張子を探します。見つかった場合、拡張子をClientHelloouterの対応する拡張シーケンスに置き換えます。サーバーは、以下のいずれかが当てはまる場合は、「Illegal_Parameter」アラートに接続を中止する必要があります。
* Any referenced extension is missing in ClientHelloOuter.
* 参照されている拡張機能は、clienthelloouterで欠落しています。
* Any extension is referenced in OuterExtensions more than once.
* 任意の拡張機能は、outourextensionsで複数回参照されます。
* "encrypted_client_hello" is referenced in OuterExtensions.
* 「encrypted_client_hello」は、outourextensionsで参照されます。
* The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.
* Auterextensionsの拡張機能に対応するClientHelloouterの拡張機能は、同じ順序で発生しません。
These requirements prevent an attacker from performing a packet amplification attack, by crafting a ClientHelloOuter which decompresses to a much larger ClientHelloInner. This is discussed further in Section 10.11.4.
これらの要件により、攻撃者は、はるかに大きなClientHelloinnerに減圧するクライアントヘロウターを作成することにより、パケット増幅攻撃を実行することができません。これについては、セクション10.11.4でさらに説明します。
Implementations SHOULD bound the time to compute a ClientHelloInner proportionally to the ClientHelloOuter size. If the cost is disproportionately large, a malicious client could exploit this in a denial of service attack. Appendix B describes a linear-time procedure that may be used for this purpose.
実装は、ClientHelloouterサイズに比例してClientHelloinnerを計算する時間を削減する必要があります。コストが不釣り合いに大きい場合、悪意のあるクライアントはサービス拒否攻撃でこれを悪用する可能性があります。付録Bでは、この目的に使用できる線形時間手順について説明しています。
To prevent a network attacker from modifying the reconstructed ClientHelloInner (see Section 10.11.3), ECH authenticates ClientHelloOuter by passing ClientHelloOuterAAD as the associated data for HPKE sealing and opening operations. The ClientHelloOuterAAD is a serialized ClientHello structure, defined in Section 4.1.2 of [RFC8446], which matches the ClientHelloOuter except the payload field of the "encrypted_client_hello" is replaced with a byte string of the same length but whose contents are zeros. This value does not include the four-byte header from the Handshake structure.
ネットワーク攻撃者が再構築されたClientHelloinnerを変更するのを防ぐため（セクション10.11.3を参照）、ECHはHPKEシーリングおよびオープニング操作の関連データとしてClientHelloouteraadを渡すことにより、ClientHelloouterを認証します。clienthelloouteraadは、[RFC8446]のセクション4.1.2で定義されているシリアル化されたクライアントヘロ構造です。これは、「necrypted_client_hello」のペイロードフィールドを除き、クライアントヘロウターと一致します。この値には、ハンドシェイク構造からの4バイトヘッダーは含まれません。
The client follows the procedure in Section 6.1.1 to first construct ClientHelloOuterAAD with a placeholder payload field, then replace the field with the encrypted value to compute ClientHelloOuter.
クライアントは、セクション6.1.1の手順に従って、最初にプレースホルダーペイロードフィールドを使用してclienthelloouteraadを構築し、次にフィールドを暗号化された値に置き換えて、clienthelloouterを計算します。
The server then receives ClientHelloOuter and computes ClientHelloOuterAAD by making a copy and replacing the portion corresponding to the payload field with zeros.
次に、サーバーはClientHelloouterを受信し、ColienthelloouteraadをCopientherosに作成し、ペイロードフィールドに対応する部分をZerosに置き換えることで計算します。
The payload and the placeholder strings have the same length, so it is not necessary for either side to recompute length prefixes when applying the above transformations.
ペイロードとプレースホルダーの文字列は同じ長さであるため、上記の変換を適用するときにどちらの側が長さのプレフィックスを再計算する必要はありません。
The decompression process in Section 5.1 forbids "encrypted_client_hello" in OuterExtensions. This ensures the unauthenticated portion of ClientHelloOuter is not incorporated into ClientHelloInner.
セクション5.1の減圧プロセスは、outourextensionsの「encrypted_client_hello」を禁止します。これにより、clienthelloouterの認知度のない部分がClientHelloinnerに組み込まれていないことが保証されます。
Clients that implement the ECH extension behave in one of two ways: either they offer a real ECH extension, as described in Section 6.1; or they send a GREASE ECH extension, as described in Section 6.2. Clients of the latter type do not negotiate ECH. Instead, they generate a dummy ECH extension that is ignored by the server. (See Section 10.9.4 for an explanation.) The client offers ECH if it is in possession of a compatible ECH configuration and sends GREASE ECH otherwise.
ECH拡張機能を実装するクライアントは、セクション6.1で説明されているように、2つの方法のいずれかで動作します。または、セクション6.2で説明されているように、グリースエック拡張機能を送信します。後者のタイプのクライアントは、ECHを交渉しません。代わりに、サーバーによって無視されるダミーECH拡張機能を生成します。（説明については、セクション10.9.4を参照してください。）互換性のあるECH構成を所有している場合、クライアントはECHを提供し、それ以外の場合はグリースECHを送信します。
To offer ECH, the client first chooses a suitable ECHConfig from the server's ECHConfigList. To determine if a given ECHConfig is suitable, it checks that it supports the KEM algorithm identified by ECHConfig.contents.kem_id, at least one KDF/AEAD algorithm identified by ECHConfig.contents.cipher_suites, and the version of ECH indicated by ECHConfig.contents.version. Once a suitable configuration is found, the client selects the cipher suite it will use for encryption. It MUST NOT choose a cipher suite or version not advertised by the configuration. If no compatible configuration is found, then the client SHOULD proceed as described in Section 6.2.
ECHを提供するために、クライアントは最初にサーバーのeChConfiglistから適切なECHCONFIGを選択します。特定のeChconfigが適切かどうかを判断するために、echconfig.contents.kem_id、echconfig.config.contents.ciphe_suitesによって識別された少なくとも1つのkdf/aeadアルゴリズムによって識別されたKEMアルゴリズムをサポートすることをチェックします。。バージョン。適切な構成が見つかったら、クライアントは暗号化に使用する暗号スイートを選択します。構成によって宣伝されていない暗号スイートまたはバージョンを選択してはなりません。互換性のある構成が見つからない場合、セクション6.2で説明されているように、クライアントは続行する必要があります。
Next, the client constructs the ClientHelloInner message just as it does a standard ClientHello, with the exception of the following rules:
次に、クライアントは、次のルールを除き、標準のclienthelloを実行するのと同じように、clienthelloinnerメッセージを構築します。
1. It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH.
1. TLS 1.2以下を交渉することを申し出てはなりません。これは、バックエンドサーバーがECHと互換性のないTLSバージョンをネゴシエートしないようにするために必要です。
2. It MUST NOT offer to resume any session for TLS 1.2 and below.
2. TLS 1.2以下のセッションを再開することを申し出てはなりません。
3. If it intends to compress any extensions (see Section 5.1), it MUST order those extensions consecutively.
3. 拡張機能を圧縮するつもりの場合（セクション5.1を参照）、それらの拡張機能を連続して注文する必要があります。
4. It MUST include the "encrypted_client_hello" extension of type inner as described in Section 5. (This requirement is not applicable when the "encrypted_client_hello" extension is generated as described in Section 6.2.)
4. セクション5で説明されているように、「necrypted_client_hello」内側の「necrypted_client_hello」拡張を含める必要があります（この要件は、セクション6.2で説明されているように「necrypted_client_hello」拡張機能を生成する場合に適用されません。）
The client then constructs EncodedClientHelloInner as described in Section 5.1. It also computes an HPKE encryption context and enc value as:
次に、セクション5.1で説明されているように、クライアントはEncodedClientHelloinnerを構築します。また、HPKE暗号化コンテキストを計算し、次のようにenc値を計算します。
pkR = DeserializePublicKey(ECHConfig.contents.public_key) enc, context = SetupBaseS(pkR, "tls ech" || 0x00 || ECHConfig)
pkr = deserializepublickey（echconfig.contents.public_key）enc、context = setupbases（pkr、 "tls ech" || 0x00 || echconfig）
Next, it constructs a partial ClientHelloOuterAAD as it does a standard ClientHello, with the exception of the following rules:
次に、次のルールを除き、標準のクライアントヘロを実行するように、部分的なclienthelloouteraadを構築します。
1. It MUST offer to negotiate TLS 1.3 or above.
1. TLS 1.3以上を交渉する必要があります。
2. If it compressed any extensions in EncodedClientHelloInner, it MUST copy the corresponding extensions from ClientHelloInner. The copied extensions additionally MUST be in the same relative order as in ClientHelloInner.
2. EncodedClientHelloinnerの拡張機能を圧縮した場合、ClientHelloinnerから対応する拡張機能をコピーする必要があります。さらに、コピーされた拡張機能は、clienthelloinnerと同じ相対順序である必要があります。
3. It MUST copy the legacy_session_id field from ClientHelloInner. This allows the server to echo the correct session ID for TLS 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH is negotiated.
3. clienthelloinnerからLegacy_session_idフィールドをコピーする必要があります。これにより、ECHが交渉されたときに、TLS 1.3の互換性モード（[RFC8446]の付録D.4を参照）の正しいセッションIDをエコーできます。
4. It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random. Instead, It MUST generate a fresh ClientHelloOuter.random using a secure random number generator. (See Section 10.11.1.)
4. clienthelloinner.randomを除く他のフィールドをclienthelloinnerからコピーする場合があります。代わりに、安全な乱数ジェネレーターを使用して、新鮮なclienthelloouter.randomを生成する必要があります。（セクション10.11.1を参照してください。）
5. The value of ECHConfig.contents.public_name MUST be placed in the "server_name" extension.
5. echconfig.contents.public_nameの値は、「server_name」拡張子に配置する必要があります。
6. When the client offers the "pre_shared_key" extension in ClientHelloInner, it SHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter, generated in the manner described in Section 6.1.2. The client MUST NOT use this extension to advertise a PSK to the client-facing server. (See Section 10.11.3.) When the client includes a GREASE "pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes" from the ClientHelloInner into the ClientHelloOuter.
6. クライアントがClientHelloinnerで「pre_shared_key」拡張機能を提供する場合、セクション6.1.2で説明されている方法で生成されたクライアントHelloouterのグリース「pre_shared_key」拡張機能も含める必要があります。クライアントは、この拡張機能を使用してPSKをクライアント向けサーバーに宣伝してはなりません。（セクション10.11.3を参照してください。）クライアントがグリース「pre_shared_key」拡張機能を含める場合、clienthelloinnerからclienthelloouterに「psk_key_exchange_modes」をコピーする必要があります。
7. When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter. This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per [RFC8446], Section 4.2.10.
7. クライアントがClientHelloinnerで「初期_DATA」拡張機能を提供する場合、ClientHelloouterに「Early_Data」拡張機能も含める必要があります。これにより、ECHを拒否し、ClientHellOouterを使用して、[RFC8446]、セクション4.2.10ごとにクライアントが送信した初期データを安全に無視するサーバーが可能になります。
Note that these rules may change in the presence of an application profile specifying otherwise.
これらのルールは、別の方法で指定するアプリケーションプロファイルの存在下で変更される可能性があることに注意してください。
The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive extensions are not offered in the ClientHelloOuter. See Section 10.5 for additional guidance.
クライアントは、両方のメッセージで非感受性拡張機能を複製する場合があります。ただし、実装は、clienthelloouterで機密性の高い拡張機能が提供されないように注意する必要があります。追加のガイダンスについては、セクション10.5を参照してください。
Finally, the client encrypts the EncodedClientHelloInner with the above values, as described in Section 6.1.1, to construct a ClientHelloOuter. It sends this to the server, and processes the response as described in Section 6.1.4.
最後に、クライアントは、セクション6.1.1で説明されているように、上記の値でエンコードされたClientHelloinnerを暗号化して、クライアントヘロウターを構築します。これをサーバーに送信し、セクション6.1.4で説明したように応答を処理します。
Given an EncodedClientHelloInner, an HPKE encryption context and enc value, and a partial ClientHelloOuterAAD, the client constructs a ClientHelloOuter as follows.
EncodedClientHelloinner、HPKE暗号化コンテキストとEnc値、および部分的なClientHelloouteraadを考えると、クライアントは次のようにクライアントヘロウターを構築します。
First, the client determines the length L of encrypting EncodedClientHelloInner with the selected HPKE AEAD. This is typically the sum of the plaintext length and the AEAD tag length. The client then completes the ClientHelloOuterAAD with an "encrypted_client_hello" extension. This extension value contains the outer variant of ECHClientHello with the following fields:
最初に、クライアントは、選択されたHPKE AEADを使用してエンコードされたClientHelloinnerを暗号化する長さlを決定します。これは通常、プレーンテキストの長さとAEADタグの長さの合計です。次に、クライアントは「encrypted_client_hello」拡張子でclienthelloouteraadを完了します。この拡張値には、次のフィールドを持つechclienthelloの外側のバリアントが含まれています。
* config_id, the identifier corresponding to the chosen ECHConfig structure;
* CONFIG_ID、選択したECHCONFIG構造に対応する識別子。
* cipher_suite, the client's chosen cipher suite;
* Cipher_suite、クライアントが選択した暗号スイート。
* enc, as given above; and
* 上記のように、enc。そして
* payload, a placeholder byte string containing L zeros.
* ペイロード、L Zerosを含むプレースホルダーバイト文字列。
If configuration identifiers (see Section 10.4) are to be ignored, config_id SHOULD be set to a randomly generated byte in the first ClientHelloOuter and, in the event of HRR, MUST be left unchanged for the second ClientHelloOuter.
構成識別子（セクション10.4を参照）を無視する場合、config_idは最初のclienthelloouterでランダムに生成されたバイトに設定する必要があり、HRRの場合は、2番目のclienthelloouterで変更されておく必要があります。
The client serializes this structure to construct the ClientHelloOuterAAD. It then computes the final payload as:
クライアントは、この構造をシリアル化して、clienthelloouteraadを構築します。次に、次のように最終的なペイロードを計算します。
final_payload = context.Seal(ClientHelloOuterAAD, EncodedClientHelloInner)
final_payload = context.seal（clienthelloouteraad、encodedclienthelloinner）
Finally, the client replaces payload with final_payload to obtain ClientHelloOuter. The two values have the same length, so it is not necessary to recompute length prefixes in the serialized structure.
最後に、クライアントはペイロードをfinal_payloadに置き換えて、clienthelloouterを取得します。2つの値は同じ長さであるため、シリアル化された構造で長さのプレフィックスを再計算する必要はありません。
Note this construction requires the "encrypted_client_hello" be computed after all other extensions. This is possible because the ClientHelloOuter's "pre_shared_key" extension is either omitted, or uses a random binder (Section 6.1.2).
この構造には、他のすべての拡張機能の後に「encrypted_client_hello」を計算する必要があります。これは、clienthelloouterの「pre_shared_key」拡張機能が省略されるか、ランダムバインダーを使用しているために可能です（セクション6.1.2）。
When offering ECH, the client is not permitted to advertise PSK identities in the ClientHelloOuter. However, the client can send a "pre_shared_key" extension in the ClientHelloInner. In this case, when resuming a session with the client, the backend server sends a "pre_shared_key" extension in its ServerHello. This would appear to a network observer as if the the server were sending this extension without solicitation, which would violate the extension rules described in [RFC8446]. Sending a GREASE "pre_shared_key" extension in the ClientHelloOuter makes it appear to the network as if the extension were negotiated properly.
ECHを提供する場合、クライアントはClientHelloouterでPSK IDを宣伝することは許可されていません。ただし、クライアントはclienthelloinnerで「pre_shared_key」拡張機能を送信できます。この場合、クライアントとのセッションを再開すると、バックエンドサーバーはserverhelloで「pre_shared_key」拡張子を送信します。これは、ネットワークオブザーバーには、サーバーが勧誘なしにこの拡張機能を送信しているかのように見え、[RFC8446]で説明されている拡張ルールに違反します。clienthelloouterでグリース「pre_shared_key」拡張機能を送信すると、拡張機能が適切に交渉されたかのようにネットワークに表示されます。
The client generates the extension payload by constructing an OfferedPsks structure (see [RFC8446], Section 4.2.11) as follows. For each PSK identity advertised in the ClientHelloInner, the client generates a random PSK identity with the same length. It also generates a random, 32-bit, unsigned integer to use as the obfuscated_ticket_age. Likewise, for each inner PSK binder, the client generates a random string of the same length.
クライアントは、次のように、提供されたPSKS構造（[RFC8446]、セクション4.2.11を参照）を構築することにより、拡張ペイロードを生成します。clienthelloinnerで宣伝されている各PSKアイデンティティについて、クライアントは同じ長さのランダムなPSKアイデンティティを生成します。また、obfuscated_ticket_ageとして使用するために、ランダムな32ビットの符号なし整数も生成します。同様に、各内側のPSKバインダーについて、クライアントは同じ長さのランダムな文字列を生成します。
Per the rules of Section 6.1, the server is not permitted to resume a connection in the outer handshake. If ECH is rejected and the client-facing server replies with a "pre_shared_key" extension in its ServerHello, then the client MUST abort the handshake with an "illegal_parameter" alert.
セクション6.1の規則に従って、サーバーは外側の握手の接続を再開することは許可されていません。ECHが拒否され、クライアントに向いたサーバーがServerHelloの「pre_shared_key」拡張機能で返信する場合、クライアントは「Illegal_parameter」アラートで握手を中止する必要があります。
This section describes a deterministic padding mechanism based on the following observation: individual extensions can reveal sensitive information through their length. Thus, each extension in the inner ClientHello may require different amounts of padding. This padding may be fully determined by the client's configuration or may require server input.
このセクションでは、次の観察に基づいた決定論的なパディングメカニズムについて説明します。個々の拡張は、その長さを通じて機密情報を明らかにすることができます。したがって、内側のclienthelloの各拡張機能は、異なる量のパディングを必要とする場合があります。このパディングは、クライアントの構成によって完全に決定される場合がある場合や、サーバー入力が必要になる場合があります。
By way of example, clients typically support a small number of application profiles. For instance, a browser might support HTTP with ALPN values ["http/1.1", "h2"] and WebRTC media with ALPNs ["webrtc", "c-webrtc"]. Clients SHOULD pad this extension by rounding up to the total size of the longest ALPN extension across all application profiles. The target padding length of most ClientHello extensions can be computed in this way.
例として、クライアントは通常、少数のアプリケーションプロファイルをサポートします。たとえば、ブラウザは、ALPN値["HTTP/1.1"、 "H2"]でHTTPをサポートし、ALPNS ["webrtc"、 "c-webrtc"]を使用したwebrtcメディアをサポートする場合があります。クライアントは、すべてのアプリケーションプロファイルで最も長いALPN拡張機能の合計サイズにまとめて、この拡張機能をパッドする必要があります。この方法で、ほとんどのClientHello拡張機能のターゲットパディングの長さを計算できます。
In contrast, clients do not know the longest SNI value in the client-facing server's anonymity set without server input. Clients SHOULD use the ECHConfig's maximum_name_length field as follows, where L is the maximum_name_length value.
対照的に、クライアントは、サーバー入力なしでクライアント向けサーバーの匿名セットで最長のSNI値を知りません。クライアントは、次のようにECHCONFIGのMaximum_Name_Lengthフィールドを使用する必要があります。ここで、LはMaximine_Name_Length値です。
1. If the ClientHelloInner contained a "server_name" extension with a name of length D, add max(0, L - D) bytes of padding.
1. clienthelloinnerに長さdという名前の「server_name」拡張子が含まれていた場合、パディングの最大バイト（0、l -d）を追加します。
2. If the ClientHelloInner did not contain a "server_name" extension (e.g., if the client is connecting to an IP address), add L + 9 bytes of padding. This is the length of a "server_name" extension with an L-byte name.
2. clienthelloinnerに「server_name」拡張子（たとえば、クライアントがIPアドレスに接続している場合）が含まれていない場合は、l 9バイトのパディングを追加します。これは、Lバイト名を持つ「server_name」拡張子の長さです。
Finally, the client SHOULD pad the entire message as follows:
最後に、クライアントは次のようにメッセージ全体をパッドする必要があります。
1. Let L be the length of the EncodedClientHelloInner with all the padding computed so far.
1. Lを、これまでに計算されたすべてのパディングを使用して、エンコードされたClientHelloinnerの長さとします。
2. Let N = 31 - ((L - 1) % 32) and add N bytes of padding.
2. n = 31-（（l -1）％32）とし、パディングのnバイトを追加します。
This rounds the length of EncodedClientHelloInner up to a multiple of 32 bytes, reducing the set of possible lengths across all clients.
これにより、EncodedClientHelloinnerの長さが32バイトの倍数まで丸められ、すべてのクライアントで可能な長さのセットが削減されます。
In addition to padding ClientHelloInner, clients and servers will also need to pad all other handshake messages that have sensitive-length fields. For example, if a client proposes ALPN values in ClientHelloInner, the server-selected value will be returned in an EncryptedExtension, so that handshake message also needs to be padded using TLS record layer padding.
ClientHelloinnerをパディングすることに加えて、クライアントとサーバーは、敏感な長さのフィールドを持つ他のすべてのハンドシェイクメッセージをパッドする必要があります。たとえば、クライアントがclienthelloinnerでALPN値を提案する場合、サーバー選択の値は暗号化されたテクステンションで返されるため、TLSレコードレイヤーパディングを使用してハンドシェイクメッセージもパッドで供給する必要があります。
As described in Section 7, the server may either accept ECH and use ClientHelloInner or reject it and use ClientHelloOuter. This is determined by the server's initial message.
セクション7で説明したように、サーバーはECHを受け入れ、ClientHelloinnerを使用するか、それを拒否してClientHelloouterを使用できます。これは、サーバーの最初のメッセージによって決定されます。
If the message does not negotiate TLS 1.3 or higher, the server has rejected ECH. Otherwise, it is either a ServerHello or HelloRetryRequest.
メッセージがTLS 1.3以上を交渉しない場合、サーバーはECHを拒否しました。それ以外の場合、それはserverhelloまたはhelloretryrequestのいずれかです。
If the message is a ServerHello, the client computes accept_confirmation as described in Section 7.2. If this value matches the last 8 bytes of ServerHello.random, the server has accepted ECH. Otherwise, it has rejected ECH.
メッセージがServerHelloの場合、クライアントはセクション7.2で説明されているようにAccept_Confiremationを計算します。この値がserverhello.randomの最後の8バイトと一致する場合、サーバーはECHを受け入れました。そうでなければ、eChを拒否しました。
If the message is a HelloRetryRequest, the client checks for the "encrypted_client_hello" extension. If none is found, the server has rejected ECH. Otherwise, if it has a length other than 8, the client aborts the handshake with a "decode_error" alert. Otherwise, the client computes hrr_accept_confirmation as described in Section 7.2.1. If this value matches the extension payload, the server has accepted ECH. Otherwise, it has rejected ECH.
メッセージがhelloretryRequestの場合、クライアントは「necrypted_client_hello」拡張子をチェックします。何も見つからない場合、サーバーはECHを拒否しました。それ以外の場合、8以外の長さがある場合、クライアントは「decode_error」アラートで握手を中止します。それ以外の場合、クライアントは、セクション7.2.1で説明されているように、HRR_ACCEPT_CONFIRMATIONを計算します。この値が拡張ペイロードと一致する場合、サーバーはECHを受け入れました。そうでなければ、eChを拒否しました。
[[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present but with the wrong value.]]
[[Open Issue：問題＃450に対して私たちが何をするかによって、HRR拡張が存在するが間違った値がある場合はクライアントの動作を変更することが適切かもしれません。]]]
If the server accepts ECH, the client handshakes with ClientHelloInner as described in Section 6.1.5. Otherwise, the client handshakes with ClientHelloOuter as described in Section 6.1.6.
サーバーがECHを受け入れると、セクション6.1.5で説明されているように、クライアントHelloinnerとのクライアントの握手があります。それ以外の場合は、セクション6.1.6で説明されているように、クライアントヘロウターでクライアントの握手があります。
If the server accepts ECH, the client proceeds with the connection as in [RFC8446], with the following modifications:
サーバーがECHを受け入れると、クライアントは[RFC8446]のように接続を進めます。
The client behaves as if it had sent ClientHelloInner as the ClientHello. That is, it evaluates the handshake using the ClientHelloInner's preferences, and, when computing the transcript hash (Section 4.4.1 of [RFC8446]), it uses ClientHelloInner as the first ClientHello.
クライアントは、clienthelloinnerをclienthelloとして送信したかのように動作します。つまり、ClientHelloinnerの好みを使用して握手を評価し、転写産物ハッシュ（[RFC8446]のセクション4.4.1）を計算すると、ClientHelloinnerを最初のClientHelloとして使用します。
If the server responds with a HelloRetryRequest, the client computes the updated ClientHello message as follows: 1. It computes a second ClientHelloInner based on the first ClientHelloInner, as in Section 4.1.4 of [RFC8446]. The ClientHelloInner's "encrypted_client_hello" extension is left unmodified.
サーバーがHelloretryRequestで応答した場合、クライアントは次のように更新されたClientHelloメッセージを計算します。1。[RFC8446]のセクション4.1.4のように、最初のClientHelloinnerに基づいて2番目のClientHelloinnerを計算します。clienthelloinnerの「encrypted_client_hello」拡張機能は、修正されていないままです。
2. It constructs EncodedClientHelloInner as described in Section 5.1.
2. セクション5.1で説明されているように、EncodedClientHelloinnerを構築します。
3. It constructs a second partial ClientHelloOuterAAD message. This message MUST be syntactically valid. The extensions MAY be copied from the original ClientHelloOuter unmodified, or omitted. If not sensitive, the client MAY copy updated extensions from the second ClientHelloInner for compression.
3. 2番目の部分的なclienthelloouteraadメッセージを構築します。このメッセージは構文的に有効でなければなりません。拡張機能は、元のclienthelloouterからコピーされるか、省略されている場合があります。敏感でない場合、クライアントは、圧縮のために2番目のclienthelloinnerから更新された拡張機能をコピーできます。
4. It encrypts EncodedClientHelloInner as described in Section 6.1.1, using the second partial ClientHelloOuterAAD, to obtain a second ClientHelloOuter. It reuses the original HPKE encryption context computed in Section 6.1 and uses the empty string for enc.
4. セクション6.1.1で説明されているようにエンコードされたClientHelloInnerを暗号化し、2番目のPartial ClientHelloouteraadを使用して、2番目のClientHelloouterを取得します。セクション6.1で計算された元のHPKE暗号化コンテキストを再利用し、空の文字列をENCに使用します。
The HPKE context maintains a sequence number, so this operation internally uses a fresh nonce for each AEAD operation. Reusing the HPKE context avoids an attack described in Section 10.11.2.
HPKEコンテキストはシーケンス番号を維持するため、この操作は、AEAD操作ごとに新たな非CEを内部的に使用します。HPKEコンテキストを再利用すると、セクション10.11.2に記載されている攻撃が回避されます。
The client then sends the second ClientHelloOuter to the server. However, as above, it uses the second ClientHelloInner for preferences, and both the ClientHelloInner messages for the transcript hash. Additionally, it checks the resulting ServerHello for ECH acceptance as in Section 6.1.4. If the ServerHello does not also indicate ECH acceptance, the client MUST terminate the connection with an "illegal_parameter" alert.
次に、クライアントは2番目のclienthelloouterをサーバーに送信します。ただし、上記のように、2番目のclienthelloinnerを設定に使用し、トランスクリプトハッシュにはclienthelloinnerメッセージの両方を使用します。さらに、セクション6.1.4のように、結果のServerHelloがECH受け入れをチェックします。ServerHelloがECHの受け入れも示していない場合、クライアントは「Illegal_Parameter」アラートとの接続を終了する必要があります。
If the server rejects ECH, the client proceeds with the handshake, authenticating for ECHConfig.contents.public_name as described in Section 6.1.7. If authentication or the handshake fails, the client MUST return a failure to the calling application. It MUST NOT use the retry configurations. It MUST NOT treat this as a secure signal to disable ECH.
サーバーがECHを拒否した場合、クライアントは握手で進行し、セクション6.1.7で説明されているように、echconfig.contents.public_nameを認証します。認証またはハンドシェイクが失敗した場合、クライアントは呼び出しアプリケーションに障害を返す必要があります。再試行構成を使用しないでください。これをECHを無効にする安全な信号として扱ってはなりません。
If the server supplied an "encrypted_client_hello" extension in its EncryptedExtensions message, the client MUST check that it is syntactically valid and the client MUST abort the connection with a "decode_error" alert otherwise. If an earlier TLS version was negotiated, the client MUST NOT enable the False Start optimization [RFC7918] for this handshake. If both authentication and the handshake complete successfully, the client MUST perform the processing described below then abort the connection with an "ech_required" alert before sending any application data to the server.
サーバーが暗号化されたExtensionメッセージに「ancrypted_client_hello」拡張子を提供した場合、クライアントは構文的に有効であることを確認する必要があり、クライアントは「decode_error」アラートに接続を中止する必要があります。以前のTLSバージョンがネゴシエートされた場合、クライアントはこの握手のために誤った開始最適化[RFC7918]を有効にしてはなりません。認証とハンドシェイクの両方が正常に完了した場合、クライアントは以下に説明する処理を実行する必要があります。アプリケーションデータをサーバーに送信する前に、「ech_required」アラートとの接続を中止する必要があります。
If the server provided "retry_configs" and if at least one of the values contains a version supported by the client, the client can regard the ECH keys as securely replaced by the server. It SHOULD retry the handshake with a new transport connection, using the retry configurations supplied by the server. The retry configurations may only be applied to the retry connection. The client MUST NOT use retry configurations for connections beyond the retry. This avoids introducing pinning concerns or a tracking vector, should a malicious server present client-specific retry configurations in order to identify the client in a subsequent ECH handshake.
サーバーが「retry_configs」を提供し、少なくとも1つの値にクライアントがサポートするバージョンが含まれている場合、クライアントはECHキーをサーバーに安全に置き換えたものと見なすことができます。サーバーが提供する再試行構成を使用して、新しいトランスポート接続で握手を再試行する必要があります。再試行構成は、再試行接続にのみ適用できます。クライアントは、再試行を超えて接続に再試行構成を使用してはなりません。これにより、悪意のあるサーバーがクライアント固有の再試行構成を提示して、後続のECHハンドシェイクでクライアントを識別する場合に、ピン留めの懸念や追跡ベクターの導入を避けます。
If none of the values provided in "retry_configs" contains a supported version, or an earlier TLS version was negotiated, the client can regard ECH as securely disabled by the server, and it SHOULD retry the handshake with a new transport connection and ECH disabled.
「retry_configs」で提供されている値にサポートされているバージョンが含まれていない場合、または以前のTLSバージョンがネゴシエートされていない場合、クライアントはサーバーによってECHを安全に無効にしていると見なすことができ、新しいトランスポート接続とECHが無効にして握手を再試行する必要があります。
Clients SHOULD implement a limit on retries caused by receipt of "retry_configs" or servers which do not acknowledge the "encrypted_client_hello" extension. If the client does not retry in either scenario, it MUST report an error to the calling application.
クライアントは、「retry_configs」または「necrypted_client_hello」拡張子を認めないサーバーの受領によって引き起こされるレトリの制限を実装する必要があります。どちらのシナリオでもクライアントが再試行しない場合、呼び出しアプリケーションにエラーを報告する必要があります。
When the server rejects ECH, it continues with the handshake using the plaintext "server_name" extension instead (see Section 7). Clients that offer ECH then authenticate the connection with the public name, as follows:
サーバーがeCHを拒否すると、代わりにプレーンテキスト「server_name」拡張機能を使用して握手を続けます（セクション7を参照）。ECHを提供するクライアントは、次のように公開名との接続を認証します。
* The client MUST verify that the certificate is valid for ECHConfig.contents.public_name. If invalid, it MUST abort the connection with the appropriate alert.
* クライアントは、証明書がechconfig.contents.public_nameに対して有効であることを確認する必要があります。無効な場合は、適切なアラートとの接続を中止する必要があります。
* If the server requests a client certificate, the client MUST respond with an empty Certificate message, denoting no client certificate.
* サーバーがクライアント証明書を要求した場合、クライアントはクライアント証明書を示す空の証明書メッセージで応答する必要があります。
In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. [RFC3986], Section 7.4 and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses. Clients that enforce this by checking and rejecting encoded IPv4 addresses in ECHConfig.contents.public_name do not need to repeat the check at this layer.
クライアント向けサーバー証明書を確認する際、クライアントは公開名をDNSベースの参照IDとして解釈する必要があります。DNS名とIPアドレスを同じ構文に組み込むクライアント（例：[RFC3986]、セクション7.4、[WhatWG-IPV4]）は、IPv4アドレスとして解釈される名前を拒否する必要があります。ECHCONFIG.CONTENTS.PUBLIC_NAMEでエンコードされたIPv4アドレスをチェックおよび拒否してこれを実施するクライアントは、このレイヤーでチェックを繰り返す必要はありません。
Note that authenticating a connection for the public name does not authenticate it for the origin. The TLS implementation MUST NOT report such connections as successful to the application. It additionally MUST ignore all session tickets and session IDs presented by the server. These connections are only used to trigger retries, as described in Section 6.1.6. This may be implemented, for instance, by reporting a failed connection with a dedicated error code.
公開名の接続を認証しても、原点に対して認証されないことに注意してください。TLS実装は、アプリケーションに成功したような接続を報告してはなりません。さらに、サーバーが提示するすべてのセッションチケットとセッションIDを無視する必要があります。これらの接続は、セクション6.1.6で説明されているように、再試行をトリガーするためにのみ使用されます。これは、たとえば、専用のエラーコードとの接続の失敗を報告することにより、実装できます。
If the client attempts to connect to a server and does not have an ECHConfig structure available for the server, it SHOULD send a GREASE [RFC8701] "encrypted_client_hello" extension in the first ClientHello as follows:
クライアントがサーバーに接続しようとし、サーバーで使用可能なeChConfig構造がない場合、次のように最初のClienthelloでグリース[RFC8701]「encrypted_client_hello "拡張機能を送信する必要があります。
* Set the config_id field to a random byte.
* config_idフィールドをランダムバイトに設定します。
* Set the cipher_suite field to a supported HpkeSymmetricCipherSuite. The selection SHOULD vary to exercise all supported configurations, but MAY be held constant for successive connections to the same server in the same session.
* cipher_suiteフィールドをサポートされているhpkesymmetricciphersuiteに設定します。選択は、すべてのサポートされた構成を行使するために異なる必要がありますが、同じセッションで同じサーバーへの連続した接続のために一定に保持される場合があります。
* Set the enc field to a randomly-generated valid encapsulated public key output by the HPKE KEM.
* ENCフィールドを、HPKE KEMによってランダムに生成された有効な有効なカプセル化された公開キー出力に設定します。
* Set the payload field to a randomly-generated string of L+C bytes, where C is the ciphertext expansion of the selected AEAD scheme and L is the size of the EncodedClientHelloInner the client would compute when offering ECH, padded according to Section 6.1.3.
* ペイロードフィールドをランダムに生成されたL Cバイトの文字列に設定します。Cは、選択されたAEADスキームの暗号文の拡張であり、Lはセクション6.1.3に従ってパディングされたECHを提供するときにクライアントが計算するエンコードされたClientHelloinnerのサイズです。
If sending a second ClientHello in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from the first ClientHello. The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only occurs if there is a HelloRetryRequest.
HelloretryRequestに応じて2番目のClientHelloを送信する場合、クライアントは最初のClientHelloから「necrypted_client_hello」拡張機能全体をコピーします。同一の値は、「encrypted_client_hello」の値が偽物であることをオブザーバーに明らかにしますが、これはhelloretryrequestがある場合にのみ発生します。
If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is invalid. It otherwise ignores the extension. It MUST NOT save the "retry_configs" value in EncryptedExtensions.
サーバーがHelloretryRequestまたは暗号化されたExtensionまたは暗号化されたExtensionを送信する場合、クライアントは、拡張機能を構文的にチェックし、無効な場合は「decode_error」アラートに接続を中止する必要があります。それ以外の場合は、拡張機能を無視します。暗号化されたEndextensionsで「Retry_Configs」値を保存してはなりません。
Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in Section 6.1. In particular, the client MAY offer to resume sessions established without ECH.
セクション6.1の要件を目的として、グリース拡張機能を提供することは、暗号化されたClientHelloを提供することとは見なされません。特に、クライアントは、ECHなしで確立されたセッションを再開することを申し出ることができます。
Servers that support ECH play one of two roles, depending on the payload of the "encrypted_client_hello" extension in the initial ClientHello:
ECHをサポートするサーバーは、最初のclienthelloの「encrypted_client_hello」拡張機能のペイロードに応じて、2つの役割のいずれかを再生します。
* If ECHClientHello.type is outer, then the server acts as a client-facing server and proceeds as described in Section 7.1 to extract a ClientHelloInner, if available.
* echclienthello.typeが外側の場合、サーバーはクライアント向けサーバーとして機能し、セクション7.1で説明されているように進行して、利用可能な場合はclienthelloinnerを抽出します。
* If ECHClientHello.type is inner, then the server acts as a backend server and proceeds as described in Section 7.2.
* echclienthello.typeが内側の場合、サーバーはバックエンドサーバーとして機能し、セクション7.2で説明されているように進行します。
* Otherwise, if ECHClientHello.type is not a valid ECHClientHelloType, then the server MUST abort with an "illegal_parameter" alert.
* それ以外の場合、echclienthello.typeが有効なechclienthellotypeではない場合、サーバーは「Illegal_parameter」アラートで中止する必要があります。
If the "encrypted_client_hello" is not present, then the server completes the handshake normally, as described in [RFC8446].
[rfc8446]に記載されているように、「cnecrypted_client_hello」が存在しない場合、サーバーは正常に握手を完了します。
Upon receiving an "encrypted_client_hello" extension in an initial ClientHello, the client-facing server determines if it will accept ECH, prior to negotiating any other TLS parameters. Note that successfully decrypting the extension will result in a new ClientHello to process, so even the client's TLS version preferences may have changed.
最初のClientHelloで「necrypted_client_hello」拡張機能を受信すると、クライアント向けサーバーは、他のTLSパラメーターを交渉する前に、ECHを受け入れるかどうかを決定します。拡張機能を正常に復号化すると、新しいClientHelloが処理されるため、クライアントのTLSバージョンの好みが変更された可能性があることに注意してください。
First, the server collects a set of candidate ECHConfig values. This list is determined by one of the two following methods:
まず、サーバーは候補のeChConfig値のセットを収集します。このリストは、次の2つの方法のいずれかによって決定されます。
1. Compare ECHClientHello.config_id against identifiers of each known ECHConfig and select the ones that match, if any, as candidates.
1. echclienthello.config_idを既知の各echconfigの識別子と比較し、候補者として一致するものを選択します。
2. Collect all known ECHConfig values as candidates, with trial decryption below determining the final selection.
2. すべての既知のeChConfig値を候補として収集し、最終選択を決定する以下の試験復号化を行います。
Some uses of ECH, such as local discovery mode, may randomize the ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig. See Section 10.4. Unless specified by the application profile or otherwise externally configured, implementations MUST use the first method.
ローカルディスカバリーモードなどのECHの使用は、追跡ベクターとして使用できるため、eChclienthello.config_idをランダム化する場合があります。このような場合、2番目の方法は、eChclienthelloを既知のeChConfigと一致させるために使用する必要があります。セクション10.4を参照してください。アプリケーションプロファイルによって指定されている場合、またはその他の外部で構成されている場合を除き、実装は最初の方法を使用する必要があります。
The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:
その後、サーバーは候補のeChConfig値を反復し、「necrypted_client_hello」拡張機能を復号化しようとします。
The server verifies that the ECHConfig supports the cipher suite indicated by the ECHClientHello.cipher_suite and that the version of ECH indicated by the client matches the ECHConfig.version. If not, the server continues to the next candidate ECHConfig.
サーバーは、eChClienthello.cipher_suiteで示された暗号スイートをサポートしていること、およびクライアントが示すECHのバージョンがeChconfig.versionと一致することを確認します。そうでない場合、サーバーは次の候補Echconfigに続きます。
Next, the server decrypts ECHClientHello.payload, using the private key skR corresponding to ECHConfig, as follows:
次に、サーバーはECHCLIENTHELLO.PAYLOADを復号化し、ECHCONFIGに対応する秘密キーSKRを使用して、次のように次のように復号化します。
context = SetupBaseR(ECHClientHello.enc, skR, "tls ech" || 0x00 || ECHConfig) EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, ECHClientHello.payload)
Context = setupbaser（echclienthello.enc、skr、 "tls ech" || 0x00 || echconfig）encodedclienthelloinner = context.open（clienthelloouteraad、echclienthello.payload）
ClientHelloOuterAAD is computed from ClientHelloOuter as described in Section 5.2. The info parameter to SetupBaseR is the concatenation "tls ech", a zero byte, and the serialized ECHConfig. If decryption fails, the server continues to the next candidate ECHConfig. Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in Section 5.1. It then stops iterating over the candidate ECHConfig values.
clienthelloouteraadは、セクション5.2で説明されているように、clienthelloouterから計算されます。SetupBaserの情報パラメーターは、「TLS ECH」、ゼロバイト、およびシリアル化されたECHCONFIGです。復号化が失敗した場合、サーバーは次の候補Echconfigに続きます。それ以外の場合、サーバーは、セクション5.1で説明されているように、ecodedClientHelloinnerからClientHelloinnerを再構築します。次に、候補のeChConfig値を繰り返し停止します。
Upon determining the ClientHelloInner, the client-facing server checks that the message includes a well-formed "encrypted_client_hello" extension of type inner and that it does not offer TLS 1.2 or below. If either of these checks fails, the client-facing server MUST abort with an "illegal_parameter" alert.
ClientHelloInnerを決定すると、クライアント向けサーバーは、メッセージに型の「encrypted_client_hello」型インナーの拡張機能が含まれていること、およびTLS 1.2以下を提供しないことを確認します。これらのチェックのいずれかが失敗した場合、クライアント向けサーバーは「Illegal_Parameter」アラートで中止する必要があります。
If these checks succeed, the client-facing server then forwards the ClientHelloInner to the appropriate backend server, which proceeds as in Section 7.2. If the backend server responds with a HelloRetryRequest, the client-facing server forwards it, decrypts the client's second ClientHelloOuter using the procedure in Section 7.1.1, and forwards the resulting second ClientHelloInner. The client-facing server forwards all other TLS messages between the client and backend server unmodified.
これらのチェックが成功した場合、クライアント向けサーバーは、クライアントヘロインナーを適切なバックエンドサーバーに転送します。これはセクション7.2のように進行します。BackEndサーバーがHelloretryRequestで応答した場合、クライアント向けサーバーはそれを転送し、セクション7.1.1の手順を使用してクライアントの2番目のクライアントヘロウターを復号化し、結果の2番目のClientHelloinnerを転送します。クライアント向けサーバーは、クライアントとバックエンドサーバーの間に他のすべてのTLSメッセージを変更していないことを転送します。
Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter, with the following modifications:
それ以外の場合、すべての候補EechConfig値が拡張機能を復号化できない場合、クライアント向けサーバーは拡張機能を無視し、次の変更を使用してClientHelloouterを使用して接続を続行する必要があります。
* If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see Section 10.9.4 for details.
* HelloretryRequestを送信する場合、サーバーには、8つのランダムバイトのペイロードを備えた「encrypted_client_hello」拡張子を含めることができます。詳細については、セクション10.9.4を参照してください。
* If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once.
* サーバーがECHCONFIGSで構成されている場合、「RETRY_CONFIGS」フィールドが最新のキーを持つ1つ以上のECHCONFIG構造に設定された「RETRY_CONFIGS」フィールドを使用して、暗号化されたテレンスに「暗号化された_CLIENT_HELLO」拡張機能を含める必要があります。サーバーは、異なるバージョンの複数のeChConfig値を提供する場合があります。これにより、サーバーは一度に複数のバージョンをサポートできます。
Note that decryption failure could indicate a GREASE ECH extension (see Section 6.2), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required. In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (Section 8.1). Instead, servers can measure occurrences of the "ech_required" alert to detect this case.
復号化の障害はグリースECH拡張を示す可能性があるため（セクション6.2を参照）、サーバーが接続を進め、ECHが必要な場合にクライアントに頼るためにクライアントに依存する必要があることに注意してください。特に、認識されていない価値だけでは、誤解されたECH広告を示していません（セクション8.1）。代わりに、サーバーは「ECH_Required」アラートの発生を測定して、このケースを検出できます。
After sending or forwarding a HelloRetryRequest, the client-facing server does not repeat the steps in Section 7.1 with the second ClientHelloOuter. Instead, it continues with the ECHConfig selection from the first ClientHelloOuter as follows:
HelloretryRequestを送信または転送した後、クライアント向けサーバーは、2番目のClientHelloouterでセクション7.1の手順を繰り返しません。代わりに、次のように、最初のclienthelloouterからのechconfigの選択を続行します。
If the client-facing server accepted ECH, it checks the second ClientHelloOuter also contains the "encrypted_client_hello" extension. If not, it MUST abort the handshake with a "missing_extension" alert. Otherwise, it checks that ECHClientHello.cipher_suite and ECHClientHello.config_id are unchanged, and that ECHClientHello.enc is empty. If not, it MUST abort the handshake with an "illegal_parameter" alert.
クライアント向けサーバーがECHを受け入れた場合、2番目のclienthelloouterに「encrypted_client_hello」拡張機能も含まれています。そうでない場合は、「Missing_Extension」アラートで握手を中止する必要があります。それ以外の場合は、echclienthello.ciphel_suiteとechclienthello.config_idが変更されておらず、echclienthello.encが空であることをチェックします。そうでない場合は、「Illegal_Parameter」アラートで握手を中止する必要があります。
Finally, it decrypts the new ECHClientHello.payload as a second message with the previous HPKE context:
最後に、以前のHPKEコンテキストで2番目のメッセージとして、新しいechclienthello.payloadを復号化します。
EncodedClientHelloInner = context.Open(ClientHelloOuterAAD, ECHClientHello.payload)
EncodedClientHelloinner = Context.open（clienthelloouteraad、echclienthello.payload）
ClientHelloOuterAAD is computed as described in Section 5.2, but using the second ClientHelloOuter. If decryption fails, the client-facing server MUST abort the handshake with a "decrypt_error" alert. Otherwise, it reconstructs the second ClientHelloInner from the new EncodedClientHelloInner as described in Section 5.1, using the second ClientHelloOuter for any referenced extensions.
clienthelloouteraadは、セクション5.2で説明されているように計算されますが、2番目のclienthelloouterを使用します。復号化が失敗した場合、クライアント向けサーバーは、「decrypt_error」アラートでハンドシェイクを中止する必要があります。それ以外の場合は、参照された拡張機能に2番目のClientHelloouterを使用して、セクション5.1で説明されているように、新しいエンコードClientHelloinnerから2番目のClientHelloinnerを再構築します。
The client-facing server then forwards the resulting ClientHelloInner to the backend server. It forwards all subsequent TLS messages between the client and backend server unmodified.
クライアント向けサーバーは、結果のClientHelloinnerをバックエンドサーバーに転送します。クライアントサーバーとバックエンドサーバーの間で、後続のすべてのTLSメッセージを変更しません。
If the client-facing server rejected ECH, or if the first ClientHello did not include an "encrypted_client_hello" extension, the client-facing server proceeds with the connection as usual. The server does not decrypt the second ClientHello's ECHClientHello.payload value, if there is one. Moreover, if the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys, as described in Section 7.1.
クライアント向けサーバーがECHを拒否した場合、または最初のClientHelloに「necrypted_client_hello」拡張機能を含めなかった場合、クライアント向けサーバーは通常どおり接続を進めます。サーバーは、2番目のclienthelloのechclienthello.payload値がある場合は、2番目のclienthelloのechclienthello.payload値を復号化しません。さらに、サーバーがECHCONFIGSで構成されている場合、セクション7.1で説明されているように、「retry_configs」フィールドが1つ以上の最新キーを持つ「retry_configs」フィールドに設定された「retry_configs」フィールドを使用して、暗号化されたテクステンションに「encrypted_client_hello」拡張子を含める必要があります。
Note that a client-facing server that forwards the first ClientHello cannot include its own "cookie" extension if the backend server sends a HelloRetryRequest. This means that the client-facing server either needs to maintain state for such a connection or it needs to coordinate with the backend server to include any information it requires to process the second ClientHello.
最初のClientHelloを転送するクライアント向けサーバーは、バックエンドサーバーがHelloretryRequestを送信した場合、独自の「Cookie」拡張機能を含めることができないことに注意してください。つまり、クライアント向けサーバーは、そのような接続のために状態を維持する必要があるか、2番目のClientHelloを処理するために必要な情報を含めるためにバックエンドサーバーと調整する必要があることを意味します。
Upon receipt of an "encrypted_client_hello" extension of type inner in a ClientHello, if the backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH acceptance to the client by computing its ServerHello as described here.
ClientHelloで「necrypted_client_hello」innerの拡張を受信すると、バックエンドサーバーがTLS 1.3以上を交渉する場合、ここで説明するようにサーバーヘロを計算してクライアントへのECHの受け入れを確認する必要があります。
The backend server embeds in ServerHello.random a string derived from the inner handshake. It begins by computing its ServerHello as usual, except the last 8 bytes of ServerHello.random are set to zero. It then computes the transcript hash for ClientHelloInner up to and including the modified ServerHello, as described in [RFC8446], Section 4.4.1. Let transcript_ech_conf denote the output. Finally, the backend server overwrites the last 8 bytes of the ServerHello.random with the following string:
バックエンドサーバーは、serverhello.randomに内側の握手から派生した文字列を埋め込みます。ServerHello.randomの最後の8バイトがゼロに設定されていることを除いて、通常どおりServerHelloを計算することから始めます。次に、[RFC8446]、セクション4.4.1に記載されているように、ClientHelloinnerのトランスクリプトハッシュを変更し、修正されたServerHelloまで計算します。transcript_ech_confが出力を示します。最後に、バックエンドサーバーは、次の文字列でserverhello.randomの最後の8バイトを上書きします。
accept_confirmation = HKDF-Expand-Label( HKDF-Extract(0, ClientHelloInner.random), "ech accept confirmation", transcript_ech_conf, 8)
Accept_Confirmation = HKDF-Expand-Label（HKDF-Extract（0、clienthelloinner.random）、 "ECH Accept Confismation"、transcript_ech_conf、8）
where HKDF-Expand-Label is defined in [RFC8446], Section 7.1, "0" indicates a string of Hash.length bytes set to zero, and Hash is the hash function used to compute the transcript hash.
HKDF-EXPAND-LABELが[RFC8446]で定義されている場合、セクション7.1、「0」はゼロに設定されたハッシュ長バイトの文字列を示し、ハッシュはトランスクリプトハッシュを計算するために使用されるハッシュ関数です。
The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below. Note that doing so would overwrite the downgrade signal for TLS 1.3 (see [RFC8446], Section 4.1.3).
バックエンドサーバーは、TLS 1.2以下を交渉した場合、この操作を実行してはなりません。そうすることで、TLS 1.3のダウングレード信号が上書きされることに注意してください（[RFC8446]、セクション4.1.3を参照）。
When the backend server sends HelloRetryRequest in response to the ClientHello, it similarly confirms ECH acceptance by adding a confirmation signal to its HelloRetryRequest. But instead of embedding the signal in the HelloRetryRequest.random (the value of which is specified by [RFC8446]), it sends the signal in an extension.
BackEndサーバーがClientHelloに応じてHelloretryRequestを送信すると、HelloretryRequestに確認信号を追加することにより、同様にECHの受け入れを確認します。しかし、HelloretryRequest.random（その値は[RFC8446]によって指定されている）に信号を埋め込む代わりに、拡張に信号を送信します。
The backend server begins by computing HelloRetryRequest as usual, except that it also contains an "encrypted_client_hello" extension with a payload of 8 zero bytes. It then computes the transcript hash for the first ClientHelloInner, denoted ClientHelloInner1, up to and including the modified HelloRetryRequest. Let transcript_hrr_ech_conf denote the output. Finally, the backend server overwrites the payload of the "encrypted_client_hello" extension with the following string:
バックエンドサーバーは、通常どおりHelloretryRequestを計算することから始まりますが、8ゼロバートのペイロードを備えた「necrypted_client_hello」拡張機能も含まれています。次に、修正されたHelloretryRequestまでのClientHelloInner1を示し、最初のclientHelloinnerの転写ハッシュを計算します。transcript_hrr_ech_confが出力を示します。最後に、バックエンドサーバーは、次の文字列を使用して、「encrypted_client_hello」拡張子のペイロードを上書きします。
hrr_accept_confirmation = HKDF-Expand-Label( HKDF-Extract(0, ClientHelloInner1.random), "hrr ech accept confirmation", transcript_hrr_ech_conf, 8)
HRR_ACCEPT_CONFIRMATION = HKDF-EXPAND-LABEL（HKDF-Extract（0、clienthelloinner1.random）、「HRR echは確認を受け入れる」、transcript_hrr_ech_conf、8）
In the subsequent ServerHello message, the backend server sends the accept_confirmation value as described in Section 7.2.
後続のServerHelloメッセージでは、BackEndサーバーはセクション7.2で説明されているようにAccect_Confirmation値を送信します。
Unlike most TLS extensions, placing the SNI value in an ECH extension is not interoperable with existing servers, which expect the value in the existing plaintext extension. Thus server operators SHOULD ensure servers understand a given set of ECH keys before advertising them. Additionally, servers SHOULD retain support for any previously-advertised keys for the duration of their validity.
ほとんどのTLS拡張機能とは異なり、ECH拡張機能にSNI値を配置すると、既存のサーバーと相互運用できません。これは、既存のプレーンテキスト拡張機能の値を期待しています。したがって、サーバーオペレーターは、広告する前に、サーバーが特定のECHキーのセットを理解できるようにする必要があります。さらに、サーバーは、有効性の期間中、以前に広告されたキーのサポートを保持する必要があります。
However, in more complex deployment scenarios, this may be difficult to fully guarantee. Thus this protocol was designed to be robust in case of inconsistencies between systems that advertise ECH keys and servers, at the cost of extra round-trips due to a retry. Two specific scenarios are detailed below.
ただし、より複雑な展開シナリオでは、これを完全に保証するのは難しい場合があります。したがって、このプロトコルは、再試行のために余分な往復を犠牲にして、ECHキーとサーバーを宣伝するシステム間で矛盾がある場合に堅牢になるように設計されました。2つの特定のシナリオを以下に詳しく説明します。
It is possible for ECH advertisements and servers to become inconsistent. This may occur, for instance, from DNS misconfiguration, caching issues, or an incomplete rollout in a multi-server deployment. This may also occur if a server loses its ECH keys, or if a deployment of ECH must be rolled back on the server.
ECH広告とサーバーが一貫性のないものになる可能性があります。これは、たとえば、DNSの誤解、キャッシングの問題、またはマルチサーバーの展開での不完全なロールアウトから発生する可能性があります。これは、サーバーがECHキーを失った場合、またはECHの展開をサーバー上にロールバックする必要がある場合にも発生する可能性があります。
The retry mechanism repairs inconsistencies, provided the server is authoritative for the public name. If server and advertised keys mismatch, the server will reject ECH and respond with "retry_configs". If the server does not understand the "encrypted_client_hello" extension at all, it will ignore it as required by Section 4.1.2 of [RFC8446]. Provided the server can present a certificate valid for the public name, the client can safely retry with updated settings, as described in Section 6.1.6.
サーバーが公開名に対して権威ある場合、再試行メカニズムは矛盾を修理します。サーバーと宣伝されたキーの不一致の場合、サーバーはECHを拒否し、「RETRY_CONFIGS」で応答します。サーバーが「encrypted_client_hello」拡張機能をまったく理解していない場合、[RFC8446]のセクション4.1.2で要求されているように無視します。サーバーが公開名に有効な証明書を提示できる場合、セクション6.1.6で説明されているように、クライアントは更新された設定で安全に再試行できます。
Unless ECH is disabled as a result of successfully establishing a connection to the public name, the client MUST NOT fall back to using unencrypted ClientHellos, as this allows a network attacker to disclose the contents of this ClientHello, including the SNI. It MAY attempt to use another server from the DNS results, if one is provided.
公開名への接続を正常に確立した結果としてECHが無効になっていない限り、クライアントは、ネットワーク攻撃者がSNIを含むこのクライアントヘロの内容を開示できるため、暗号化されていないClienthellosの使用に戻ってはいけません。DNSの結果から別のサーバーを使用しようとする場合があります。
When connecting through a TLS-terminating proxy that does not support this extension, [RFC8446], Section 9.3 requires the proxy still act as a conforming TLS client and server. The proxy must ignore unknown parameters, and generate its own ClientHello containing only parameters it understands. Thus, when presenting a certificate to the client or sending a ClientHello to the server, the proxy will act as if connecting to the public name, without echoing the "encrypted_client_hello" extension.
この拡張機能[RFC8446]をサポートしないTLS終了プロキシを介して接続する場合、セクション9.3では、プロキシが適合するTLSクライアントとサーバーとして機能する必要があります。プロキシは、不明なパラメーターを無視し、理解しているパラメーターのみを含む独自のClientHelloを生成する必要があります。したがって、クライアントに証明書を提示したり、クライアントHelloをサーバーに送信する場合、プロキシは、「encrypted_client_hello」拡張子をエコーせずに、公開名に接続するかのように機能します。
Depending on whether the client is configured to accept the proxy's certificate as authoritative for the public name, this may trigger the retry logic described in Section 6.1.6 or result in a connection failure. A proxy which is not authoritative for the public name cannot forge a signal to disable ECH.
クライアントが公開名の権威としてプロキシの証明書を受け入れるように構成されているかどうかに応じて、これにより、セクション6.1.6で説明されている再試行ロジックがトリガーされるか、接続障害になります。公開名に対して権威がないプロキシは、ECHを無効にする信号を偽造できません。
In the absence of an application profile standard specifying otherwise, a compliant ECH application MUST implement the following HPKE cipher suite:
それ以外の場合は、アプリケーションプロファイル標準がない場合、準拠したECHアプリケーションは、次のHPKE暗号スイートを実装する必要があります。
* KEM: DHKEM(X25519, HKDF-SHA256) (see Section 7.1 of [HPKE])
* KEM：DHKEM（X25519、HKDF-SHA256）（[HPKE]のセクション7.1を参照）
* KDF: HKDF-SHA256 (see Section 7.2 of [HPKE])
* KDF：HKDF-SHA256（[HPKE]のセクション7.2を参照）
* AEAD: AES-128-GCM (see Section 7.3 of [HPKE])
* AEAD：AES-128-GCM（[HPKE]のセクション7.3を参照）
ECH considers two types of attackers: passive and active. Passive attackers can read packets from the network, but they cannot perform any sort of active behavior such as probing servers or querying DNS. A middlebox that filters based on plaintext packet contents is one example of a passive attacker. In contrast, active attackers can also write packets into the network for malicious purposes, such as interfering with existing connections, probing servers, and querying DNS. In short, an active attacker corresponds to the conventional threat model for TLS 1.3 [RFC8446].
ECHは、受動的でアクティブな2種類の攻撃者を考慮します。パッシブ攻撃者はネットワークからパケットを読み取ることができますが、サーバーの調査やDNSのクエリなど、いかなる種類のアクティブな動作を実行することはできません。Plantextパケットコンテンツに基づいてフィルターを使用するミドルボックスは、受動的な攻撃者の一例です。対照的に、アクティブな攻撃者は、既存の接続、調査サーバーの調査、DNSのクエリなど、悪意のある目的のためにネットワークにパケットを書き込むこともできます。要するに、アクティブな攻撃者は、TLS 1.3 [RFC8446]の従来の脅威モデルに対応します。
Given these types of attackers, the primary goals of ECH are as follows.
これらのタイプの攻撃者を考えると、ECHの主な目標は次のとおりです。
1. Security preservation. Use of ECH does not weaken the security properties of TLS without ECH.
1. セキュリティ保存。ECHの使用は、ECHなしでTLSのセキュリティプロパティを弱めません。
2. Handshake privacy. TLS connection establishment to a host with a specific ECHConfig and TLS configuration is indistinguishable from a connection to any other host with the same ECHConfig and TLS configuration. (The set of hosts which share the same ECHConfig and TLS configuration is referred to as the anonymity set.)
2. ハンドシェイクプライバシー。特定のECHCONFIGおよびTLS構成を持つホストへのTLS接続確立は、同じECHCONFIGおよびTLS構成を持つ他のホストへの接続と区別できません。（同じECHCONFIGおよびTLS構成を共有するホストのセットは、匿名セットと呼ばれます。）
3. Downgrade resistance. An attacker cannot downgrade a connection that attempts to use ECH to one that does not use ECH.
3. 抵抗のダウングレード。攻撃者は、ECHを使用しようとする接続をECHに使用しようとする接続をダウングレードできません。
These properties were formally proven in [ECH-Analysis].
これらの特性は、[ech分析]で正式に証明されていました。
With regards to handshake privacy, client-facing server configuration determines the size of the anonymity set. For example, if a client-facing server uses distinct ECHConfig values for each host, then each anonymity set has size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible. This means client-facing servers should use the same ECHConfig for as many hosts as possible. An attacker can distinguish two hosts that have different ECHConfig values based on the ECHClientHello.config_id value. This also means public information in a TLS handshake should be consistent across hosts. For example, if a client-facing server services many backend origin hosts, only one of which supports some cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages.
ハンドシェイクのプライバシーに関しては、クライアント向けのサーバー構成により、匿名セットのサイズが決まります。たとえば、クライアント向けサーバーが各ホストに個別のeChConfig値を使用する場合、各匿名セットにはサイズk = 1の場合は、クライアント向けサーバーが匿名セットのサイズを最大化するためにECHをそのように展開する必要があります。。これは、クライアント向けサーバーができるだけ多くのホストに同じeChConfigを使用する必要があることを意味します。攻撃者は、echclienthello.config_id値に基づいて異なるeChConfig値を持つ2つのホストを区別できます。これはまた、TLSの握手における公開情報がホスト間で一貫している必要があることを意味します。たとえば、クライアント向けサーバーが多くのバックエンドオリジンホストにサービスを提供する場合、そのうちの1つのみが暗号スイートをサポートする場合、暗号化されていないハンドシェイクメッセージの内容に基づいてそのホストを識別することができる場合があります。
Beyond these primary security and privacy goals, ECH also aims to hide, to some extent, the fact that it is being used at all. Specifically, the GREASE ECH extension described in Section 6.2 does not change the security properties of the TLS handshake at all. Its goal is to provide "cover" for the real ECH protocol (Section 6.1), as a means of addressing the "do not stick out" requirements of [RFC8744]. See Section 10.9.4 for details.
これらの主要なセキュリティとプライバシーの目標を超えて、ECHは、ある程度、それがまったく使用されているという事実を隠すことも目指しています。具体的には、セクション6.2で説明されているグリースエック拡張は、TLSハンドシェイクのセキュリティプロパティをまったく変更しません。その目標は、[RFC8744]の「耐えられない」要件に対処する手段として、実際のECHプロトコル（セクション6.1）に「カバー」を提供することです。詳細については、セクション10.9.4を参照してください。
In comparison to [I-D.kazuho-protected-sni], wherein DNS Resource Records are signed via a server private key, ECH records have no authenticity or provenance information. This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ECH records (so that the client encrypts data to them) or strip the ECH record from the response. However, in the face of an attacker that controls DNS, no encryption scheme can work because the attacker can replace the IP address, thus blocking client connections, or substitute a unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards). Thus, allowing the ECH records in the clear does not make the situation significantly worse.
DNSリソースレコードがサーバーの秘密キーを介して署名されている[i-d.kazuho保護-Sni]と比較して、ECHレコードには信頼性または出所情報がありません。これは、クライアントアクセスネットワークの一般的なシナリオであるDNS応答または毒DNSキャッシュを挿入できる攻撃者は、クライアントに偽のECHレコード（クライアントにデータを暗号化するように）を提供するか、応答からECHレコードを削除できることを意味します。。ただし、DNSを制御する攻撃者に直面しても、攻撃者がIPアドレスを交換してクライアント接続をブロックすることができるため、暗号化スキームは機能しません。（Modulo DNSワイルドカード）。したがって、ClearのECHレコードを許可しても、状況が大幅に悪化しません。
Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by attackers on the local network, which is a common case where ClientHello and SNI encryption are desired. Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms.
明らかに、DNSSEC（クライアントが検証し、ハードが失敗した場合）はこの形式の攻撃に対する防御ですが、DOH/DPRIVEはローカルネットワークでの攻撃者によるDNS攻撃に対する防御でもあります。。さらに、導入部で述べたように、SNI暗号化は、DOHまたはDPRIVEメカニズムを介した輸送中のDNSクエリの暗号化なしではあまり有用ではありません。
A malicious client-facing server could distribute unique, per-client ECHConfig structures as a way of tracking clients across subsequent connections. On-path adversaries which know about these unique keys could also track clients in this way by observing TLS connection attempts.
悪意のあるクライアント向けサーバーは、その後の接続全体でクライアントを追跡する方法として、ユニークでクライアントのECHCONFIG構造を配布できます。これらのユニークなキーについて知っているパス上の敵は、TLS接続の試みを観察することにより、この方法でクライアントを追跡することもできます。
The cost of this type of attack scales linearly with the desired number of target clients. Moreover, DNS caching behavior makes targeting individual users for extended periods of time, e.g., using per-client ECHConfig structures delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate this problem by flushing any DNS or ECHConfig state upon changing networks.
このタイプの攻撃のコストは、目的の数のターゲットクライアントと直線的にスケーリングします。さらに、DNSキャッシング動作により、個々のユーザーを長期間ターゲットにします。たとえば、高TTLを持つHTTPS RRSを介して配信されるクライアントごとのeChConfig構造を使用して、挑戦的です。クライアントは、ネットワークを変更すると、DNSまたはECHCONFIG状態をフラッシュすることにより、この問題を軽減するのに役立ちます。
Ignoring configuration identifiers may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension. In such settings, clients send a randomly generated config_id in the ECHClientHello. Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key using the config_id value. As a result, ignoring configuration identifiers may exacerbate DoS attacks. Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption. Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the potential damage caused by such attacks.
構成識別子を無視することは、クライアントとクライアント向けのサーバーが「encrypted_client_hello」拡張子のクライアント向けサーバーに関する情報を表示したくないシナリオで役立つ場合があります。このような設定では、クライアントはechclienthelloでランダムに生成されたconfig_idを送信します。これらの設定のサーバーは、config_id値を使用してクライアントが選択したECHキーを識別できないため、トライアル復号化を実行する必要があります。その結果、構成識別子を無視すると、DOS攻撃が悪化する可能性があります。具体的には、敵は悪意のあるClientHelloメッセージ、つまり、無駄な復号化を強制するために、既知のECHキーで復号化されないメッセージを送信する場合があります。この機能をサポートするサーバーは、たとえば、そのような攻撃によって引き起こされる潜在的な損傷を制限するために、何らかの形のレート制限メカニズムを実装する必要があります。
Unless specified by the application using (D)TLS or externally configured, implementations MUST NOT use this mode.
（d）TLSまたは外部構成を使用してアプリケーションで指定されていない限り、実装はこのモードを使用してはなりません。
Any information that the client includes in the ClientHelloOuter is visible to passive observers. The client SHOULD NOT send values in the ClientHelloOuter which would reveal a sensitive ClientHelloInner property, such as the true server name. It MAY send values associated with the public name in the ClientHelloOuter.
クライアントがClientHelloouterに含める情報は、パッシブオブザーバーに表示されます。クライアントは、True Server名などの機密性の高いClientHelloInnerプロパティを明らかにするクライアントHelloouterに値を送信してはなりません。clienthelloouterの公開名に関連付けられた値を送信する場合があります。
In particular, some extensions require the client send a server-name-specific value in the ClientHello. These values may reveal information about the true server name. For example, the "cached_info" ClientHello extension [RFC7924] can contain the hash of a previously observed server certificate. The client SHOULD NOT send values associated with the true server name in the ClientHelloOuter. It MAY send such values in the ClientHelloInner.
特に、一部の拡張機能では、クライアントがclienthelloでサーバー名固有の値を送信する必要があります。これらの値は、真のサーバー名に関する情報を明らかにする場合があります。たとえば、「cached_info」clienthello拡張子[RFC7924]には、以前に観察されたサーバー証明書のハッシュを含めることができます。クライアントは、clienthelloouterの真のサーバー名に関連付けられた値を送信しないでください。ClientHelloinnerでそのような値を送信する場合があります。
A client may also use different preferences in different contexts. For example, it may send a different ALPN lists to different servers or in different application contexts. A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter.
クライアントは、さまざまなコンテキストで異なる設定を使用する場合もあります。たとえば、異なるサーバーまたは異なるアプリケーションコンテキストで、異なるALPNリストを送信する場合があります。このコンテキストを敏感であると扱うクライアントは、ClientHelloouterでコンテキスト固有の値を送信してはなりません。
Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter. If they match the corresponding ClientHelloInner, they MAY be compressed as described in Section 5.1. However, note the payload length reveals information about which extensions are compressed, so inner extensions which only sometimes match the corresponding outer extension SHOULD NOT be compressed.
真のサーバー名、またはクライアントが保護したい他の情報に依存しない値は、clienthelloouterに含まれる場合があります。対応するClientHelloinnerと一致する場合、セクション5.1で説明されているように圧縮される可能性があります。ただし、ペイロードの長さは、どの拡張機能が圧縮されているかについての情報を明らかにしているため、対応する外部拡張機能と一致することがある内部拡張機能を圧縮してはならないことに注意してください。
Clients MAY include additional extensions in ClientHelloOuter to avoid signaling unusual behavior to passive observers, provided the choice of value and value itself are not sensitive. See Section 10.9.4.
クライアントには、価値と価値の選択自体が敏感ではない場合、パッシブオブザーバーに異常な動作を信号することを避けるために、ClientHelloouterに追加の拡張機能を含めることができます。セクション10.9.4を参照してください。
ECH requires encrypted DNS to be an effective privacy protection mechanism. However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity. Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as part of verification.
ECHでは、暗号化されたDNSが効果的なプライバシー保護メカニズムになる必要があります。ただし、特にX509証明書を使用する場合、証明書メッセージからサーバーのIDを確認すると、サーバーのIDが表示される可能性のある追加のネットワークトラフィックが発生する可能性があります。このトラフィックの例には、OCSPやCRLトラフィックなどの取り消し情報のリクエスト、またはAuthorityInformationAccessなどのリポジトリ情報のリクエストが含まれます。また、検証の一環として、追加情報源のための実装固有のトラフィックを含めることもできます。
Implementations SHOULD avoid leaking information that may identify the server. Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used. To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation.
実装は、サーバーを識別する可能性のある情報の漏れを避ける必要があります。暗号化されたトランスポートに送信された場合でも、そのような要求は、特定のCAまたは使用が使用されていることを示すなど、サーバーのIDの間接的な露出につながる可能性があります。このリスクを緩和するために、サーバーは、OCSPステープリングの使用など、可能な場合はそのような情報を可能な場合はバンド内で配信する必要があり、クライアントは証明書の検証中にそのような要求を最小限に抑えるか保護するための措置を講じる必要があります。
Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document. For example, a client that connects to a particular host prior to ECH deployment may later resume a connection to that same host after ECH deployment. An adversary that observes this can deduce that the ECH-enabled connection was made to a host that the client previously connected to and which is within the same anonymity set.
ECH接続でサーバーのアイデンティティを推測するために非ECHトラフィックに依存している攻撃は、このドキュメントの範囲外です。たとえば、ECH展開前に特定のホストに接続するクライアントは、後でECH展開後に同じホストへの接続を再開する場合があります。これを観察する敵は、クライアントが以前に接続し、同じ匿名セット内にあるホストにECH対応の接続が行われたと推測できます。
Section 4.2.2 of [RFC8446] defines a cookie value that servers may send in HelloRetryRequest for clients to echo in the second ClientHello. While ECH encrypts the cookie in the second ClientHelloInner, the backend server's HelloRetryRequest is unencrypted.This means differences in cookies between backend servers, such as lengths or cleartext components, may leak information about the server identity.
[RFC8446]のセクション4.2.2では、2番目のClientHelloでエコーをエコーするために、サーバーがHelloretryRequestで送信する可能性のあるCookie値を定義しています。ECHは2番目のClientHelloinnerでCookieを暗号化しますが、バックエンドサーバーのHelloretryRequestは暗号化されていません。これは、長さやクリアテキストコンポーネントなどのバックエンドサーバー間のCookieの違いを意味しますが、サーバーのアイデンティティに関する情報を漏らすことができます。
Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server. This may be done by handling HelloRetryRequest statefully, thus not sending cookies, or by using the same cookie construction for all backend servers.
匿名セットのバックエンドサーバーは、サーバーを識別するCookieに情報を表示しないでください。これは、HelloretryRequestを状態で扱うことで、Cookieを送信することも、すべてのバックエンドサーバーに同じCookie構造を使用することもできます。
Note that, if the cookie includes a key name, analogous to Section 4 of [RFC5077], this may leak information if different backend servers issue cookies with different key names at the time of the connection. In particular, if the deployment operates in Split Mode, the backend servers may not share cookie encryption keys. Backend servers may mitigate this by either handling key rotation with trial decryption, or coordinating to match key names.
[RFC5077]のセクション4に類似したCookieにキー名が含まれている場合、接続時に異なるバックエンドサーバーが異なるキー名でCookieを発行する場合、これは情報をリークする可能性があることに注意してください。特に、展開がスプリットモードで動作する場合、バックエンドサーバーはCookie暗号化キーを共有できない場合があります。バックエンドサーバーは、トライアルの復号化でキーローテーションを処理するか、キー名と一致するように調整することにより、これを軽減する場合があります。
To signal acceptance, the backend server overwrites 8 bytes of its ServerHello.random with a value derived from the ClientHelloInner.random. (See Section 7.2 for details.) This behavior increases the likelihood of the ServerHello.random colliding with the ServerHello.random of a previous session, potentially reducing the overall security of the protocol. However, the remaining 24 bytes provide enough entropy to ensure this is not a practical avenue of attack.
受け入れを信号するために、バックエンドサーバーは、clienthelloinner.randomから派生した値でserverhello.randomの8バイトを上書きします。（詳細については、セクション7.2を参照してください。）この動作により、serverhello.randomが以前のセッションのserverhello.randomと衝突する可能性が高まり、プロトコルの全体的なセキュリティが減少する可能性があります。ただし、残りの24バイトは、これが攻撃の実用的な道ではないことを保証するのに十分なエントロピーを提供します。
On the other hand, the probability that two 8-byte strings are the same is non-negligible. This poses a modest operational risk. Suppose the client-facing server terminates the connection (i.e., ECH is rejected or bypassed): if the last 8 bytes of its ServerHello.random coincide with the confirmation signal, then the client will incorrectly presume acceptance and proceed as if the backend server terminated the connection. However, the probability of a false positive occurring for a given connection is only 1 in 2^64. This value is smaller than the probability of network connection failures in practice.
一方、2つの8バイトの文字列が同じであるという確率は、交渉できません。これは、ささやかな運用リスクをもたらします。クライアント向けサーバーが接続を終了するとします（つまり、ECHが拒否またはバイパスされます）：ServerHello.Randomの最後の8バイトが確認信号と一致する場合、クライアントは誤って受け入れを想定し、バックエンドサーバーが終了したかのように進行します接続。ただし、特定の接続で誤検出が発生する確率は、2^64に1つしかありません。この値は、実際のネットワーク接続障害の確率よりも小さくなっています。
Note that the same bytes of the ServerHello.random are used to implement downgrade protection for TLS 1.3 (see [RFC8446], Section 4.1.3). These mechanisms do not interfere because the backend server only signals ECH acceptance in TLS 1.3 or higher.
ServerHello.randomの同じバイトがTLS 1.3のダウングレード保護を実装するために使用されることに注意してください（[RFC8446]、セクション4.1.3を参照）。これらのメカニズムは、バックエンドサーバーのみがTLS 1.3以降で受け入れを繰り返すことを示すため、干渉しません。
[RFC8744] lists several requirements for SNI encryption. In this section, we re-iterate these requirements and assess the ECH design against them.
[RFC8744]は、SNI暗号化のいくつかの要件をリストしています。このセクションでは、これらの要件を繰り返し、それらに対するECH設計を評価します。
Since servers process either ClientHelloInner or ClientHelloOuter, and because ClientHelloInner.random is encrypted, it is not possible for an attacker to "cut and paste" the ECH value in a different Client Hello and learn information from ClientHelloInner.
サーバーはClientHelloinnerまたはclienthelloouterを処理し、Clienthelloinner.randomが暗号化されているため、攻撃者が別のクライアントのhelloのech値を「カットして貼り付けて貼り付ける」ことはできません。
This design depends upon DNS as a vehicle for semi-static public key distribution. Server operators may partition their private keys however they see fit provided each server behind an IP address has the corresponding private key to decrypt a key. Thus, when one ECH key is provided, sharing is optimally bound by the number of hosts that share an IP address. Server operators may further limit sharing by publishing different DNS records containing ECHConfig values with different keys using a short TTL.
この設計は、半静的な公開鍵分布の手段としてのDNSに依存しています。サーバーオペレーターは、IPアドレスの背後にある各サーバーがキーを復号化するための対応するプライベートキーを持っている場合、自分のプライベートキーをパーティション化する場合があります。したがって、1つのECHキーが提供されると、共有はIPアドレスを共有するホストの数に最適に結合されます。サーバーオペレーターは、短いTTLを使用して異なるキーを持つECHCONFIG値を含むさまざまなDNSレコードを公開することにより、さらに共有を制限する場合があります。
This design requires servers to decrypt ClientHello messages with ECHClientHello extensions carrying valid digests. Thus, it is possible for an attacker to force decryption operations on the server. This attack is bound by the number of valid TCP connections an attacker can open.
この設計では、有効なダイジェストを運ぶEchclientHello拡張機能を使用して、サーバーをclienthelloメッセージを復号化する必要があります。したがって、攻撃者がサーバー上の復号化操作を強制することが可能です。この攻撃は、攻撃者が開くことができる有効なTCP接続の数に拘束されます。
As a means of reducing the impact of network ossification, [RFC8744] recommends SNI-protection mechanisms be designed in such a way that network operators do not differentiate connections using the mechanism from connections not using the mechanism. To that end, ECH is designed to resemble a standard TLS handshake as much as possible. The most obvious difference is the extension itself: as long as middleboxes ignore it, as required by [RFC8446], the rest of the handshake is designed to look very much as usual.
ネットワークの骨化の影響を減らす手段として、[RFC8744]は、ネットワークオペレーターがメカニズムを使用しない接続とメカニズムを使用して接続を区別しないように設計されることを推奨しています。そのために、ECHは標準のTLSハンドシェイクに可能な限り似ているように設計されています。最も明白な違いは拡張自体です。[RFC8446]で要求されるように、ミドルボックスがそれを無視する限り、残りの握手は通常どおりに見えるように設計されています。
The GREASE ECH protocol described in Section 6.2 provides a low-risk way to evaluate the deployability of ECH. It is designed to mimic the real ECH protocol (Section 6.1) without changing the security properties of the handshake. The underlying theory is that if GREASE ECH is deployable without triggering middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH should be deployable as well. Thus, our strategy for mitigating network ossification is to deploy GREASE ECH widely enough to disincentivize differential treatment of the real ECH protocol by the network.
セクション6.2で説明したグリースECHプロトコルは、ECHの展開性を評価するための低リスクの方法を提供します。ハンドシェイクのセキュリティプロパティを変更せずに、実際のECHプロトコル（セクション6.1）を模倣するように設計されています。根本的な理論は、グリースエックがミドルボックスの不正行為をトリガーせずに展開できる場合、実際のeCHがグリースECHのように十分に見える場合、ECHも展開できる必要があるということです。したがって、ネットワークの骨化を緩和するための戦略は、ネットワークによる実際のECHプロトコルの微分扱いを除去するのに十分なほどグリースECHを展開することです。
Ensuring that networks do not differentiate between real ECH and GREASE ECH may not be feasible for all implementations. While most middleboxes will not treat them differently, some operators may wish to block real ECH usage but allow GREASE ECH. This specification aims to provide a baseline security level that most deployments can achieve easily, while providing implementations enough flexibility to achieve stronger security where possible. Minimally, real ECH is designed to be indifferentiable from GREASE ECH for passive adversaries with following capabilities:
ネットワークが実際のECHとグリースECHを区別しないようにすることは、すべての実装では実行不可能な場合があります。ほとんどのミドルボックスはそれらを異なって扱いませんが、一部のオペレーターは実際のECH使用量をブロックしたいが、グリースエックを許可する場合があります。この仕様の目的は、ほとんどの展開が簡単に達成できるベースラインセキュリティレベルを提供することを目的としていますが、可能な限りより強力なセキュリティを実現するのに十分な柔軟性を実装することを目的としています。最終的に、実際のECHは、次の能力を備えた受動的な敵のグリースECHから無関心になるように設計されています。
1. The attacker does not know the ECHConfigList used by the server.
1. 攻撃者は、サーバーで使用されているeChConfiglistを知りません。
2. The attacker keeps per-connection state only. In particular, it does not track endpoints across connections.
2. 攻撃者は、接続ごとの状態のみを保持します。特に、接続全体でエンドポイントを追跡しません。
3. ECH and GREASE ECH are designed so that the following features do not vary: the code points of extensions negotiated in the clear; the length of messages; and the values of plaintext alert messages.
3. ECHとグリースECHは、次の機能が変化しないように設計されています。メッセージの長さ;そして、プレーンテキストアラートメッセージの値。
This leaves a variety of practical differentiators out-of-scope. including, though not limited to, the following:
これにより、さまざまな実用的な差別化要因がスコープ外になります。以下に限定されませんが、
1. the value of the configuration identifier;
1. 構成識別子の値。
2. the value of the outer SNI;
2. 外側のSNIの値。
3. the TLS version negotiated, which may depend on ECH acceptance;
3. TLSバージョンは交渉されましたが、これはECHの受け入れに依存する可能性があります。
4. client authentication, which may depend on ECH acceptance; and
4. クライアント認証。これは、ECHの受け入れに依存する可能性があります。そして
5. HRR issuance, which may depend on ECH acceptance.
5. HRR発行。これは、ECHの受け入れに依存する可能性があります。
These can be addressed with more sophisticated implementations, but some mitigations require coordination between the client and server. These mitigations are out-of-scope for this specification.
これらは、より洗練された実装で対処できますが、一部の緩和はクライアントとサーバー間の調整が必要です。これらの緩和は、この仕様のスコープ外です。
This design is not forward secret because the server's ECH key is static. However, the window of exposure is bound by the key lifetime. It is RECOMMENDED that servers rotate keys frequently.
サーバーのECHキーは静的であるため、この設計は前向きな秘密ではありません。ただし、露出の窓は重要な寿命に縛られています。サーバーは頻繁にキーを回転させることをお勧めします。
This design permits servers operating in Split Mode to forward connections directly to backend origin servers. The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks.
この設計では、スプリットモードで動作するサーバーを使用して、接続を直接バックエンドオリジンサーバーに転送できます。クライアントは、バックエンドOrigin ServerのIDを認証するため、不要なMITM攻撃を回避します。
Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible. See Section 10.2 for more details regarding plaintext DNS.
逆に、DNSから取得されたECHレコードが認証されていると仮定します。たとえば、DNSSECを介して、または信頼できる再帰リゾルバーから取得され、スプリットモードで動作するクライアント向けサーバーをスプーフィングすることは不可能です。プレーンテキストDNSに関する詳細については、セクション10.2を参照してください。
Authenticating the ECHConfig structure naturally authenticates the included public name. This also authenticates any retry signals from the client-facing server because the client validates the server certificate against the public name before retrying.
ECHCONFIG構造を認証することは、付属の公開名を自然に認証します。また、クライアントが再試行する前にサーバー証明書を公開名に対して検証するため、クライアント向けサーバーからの再試行信号も認証されます。
This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification. Thus, it is compatible with multiple application and transport protocols. By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension.
この設計は、アプリケーション層プロトコルの交渉に影響を与えません。接続ルーティング、サーバー証明書の選択、およびクライアント証明書の確認に影響を与える可能性があります。したがって、複数のアプリケーションおよび輸送プロトコルと互換性があります。ClientHello全体を暗号化することにより、このデザインはALPN拡張機能の暗号化をさらにサポートします。
Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. Section 6.1.3 describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage.
clienthelloinnerの長さのバリエーションは、対応するプレーンテキストに関する情報を漏らす可能性があります。セクション6.1.3では、潜在的な情報漏れを減らすことを目的としたクライアントに推奨されるパディングメカニズムについて説明します。
This section describes the rationale for ECH properties and mechanics as defenses against active attacks. In all the attacks below, the attacker is on-path between the target client and server. The goal of the attacker is to learn private information about the inner ClientHello, such as the true SNI value.
このセクションでは、積極的な攻撃に対する防御としてのECH特性とメカニズムの理論的根拠について説明します。以下のすべての攻撃で、攻撃者はターゲットクライアントとサーバーの間のパス上にあります。攻撃者の目標は、真のSNI値など、内部クライアントヘロに関する個人情報を学ぶことです。
This attack uses the client's reaction to an incorrect certificate as an oracle. The attacker intercepts a legitimate ClientHello and replies with a ServerHello, Certificate, CertificateVerify, and Finished messages, wherein the Certificate message contains a "test" certificate for the domain name it wishes to query. If the client decrypted the Certificate and failed verification (or leaked information about its verification process by a timing side channel), the attacker learns that its test certificate name was incorrect. As an example, suppose the client's SNI value in its inner ClientHello is "example.com," and the attacker replied with a Certificate for "test.com". If the client produces a verification failure alert because of the mismatch faster than it would due to the Certificate signature validation, information about the name leaks. Note that the attacker can also withhold the CertificateVerify message. In that scenario, a client which first verifies the Certificate would then respond similarly and leak the same information.
この攻撃は、クライアントの反応を使用して、誤った証明書をOracleとして使用します。攻撃者は正当なClientHelloをインターセプトし、ServerHello、証明書、CertificateVerify、および完成したメッセージで返信します。これには、証明書メッセージには、クエリを希望するドメイン名の「テスト」証明書が含まれています。クライアントが証明書を復号化し、検証に失敗した場合（またはタイミングサイドチャネルによる検証プロセスに関する情報が漏れた）、攻撃者はそのテスト証明書名が正しくないことを知ります。例として、クライアントの内側のclienthelloのクライアントのSNI値が「Example.com」であると仮定し、攻撃者は「test.com」の証明書で返信しました。クライアントが、証明書の署名検証のために不一致が速いため、名前が漏れに関する情報のために、検証障害アラートを生成する場合。攻撃者は、CertimateVerifyメッセージを差し控えることもできることに注意してください。そのシナリオでは、最初に証明書を検証するクライアントが同様に応答し、同じ情報をリークします。
Client Attacker Server
ClientHello
+ key_share
+ ech ------> (intercept) -----> X (drop)
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
<------
Alert
------>
Figure 3: Client reaction attack
図3：クライアント反応攻撃
ClientHelloInner.random prevents this attack. In particular, since the attacker does not have access to this value, it cannot produce the right transcript and handshake keys needed for encrypting the Certificate message. Thus, the client will fail to decrypt the Certificate and abort the connection.
clienthelloinner.randomはこの攻撃を防ぎます。特に、攻撃者はこの値にアクセスできないため、証明書メッセージの暗号化に必要な適切なトランスクリプトと握手キーを生成することはできません。したがって、クライアントは証明書を復号化し、接続を中止することに失敗します。
This attack aims to exploit server HRR state management to recover information about a legitimate ClientHello using its own attacker-controlled ClientHello. To begin, the attacker intercepts and forwards a legitimate ClientHello with an "encrypted_client_hello" (ech) extension to the server, which triggers a legitimate HelloRetryRequest in return. Rather than forward the retry to the client, the attacker attempts to generate its own ClientHello in response based on the contents of the first ClientHello and HelloRetryRequest exchange with the result that the server encrypts the Certificate to the attacker. If the server used the SNI from the first ClientHello and the key share from the second (attacker-controlled) ClientHello, the Certificate produced would leak the client's chosen SNI to the attacker.
この攻撃の目的は、サーバーHRR状態管理を活用して、独自の攻撃者制御されたClientHelloを使用して正当なClientHelloに関する情報を回復することを目的としています。まず、攻撃者は正当なclienthelloを傍受して転送し、サーバーへの「necrypted_client_hello」（ECH）拡張機能を使用します。攻撃者は、クライアントに再試行を転送するのではなく、最初のclienthelloとhelloretryrequest交換の内容に基づいて自社のClienthelloを生成しようとします。サーバーが最初のClientHelloからSNIを使用し、2番目の（攻撃者制御）ClientHelloのキー共有を使用した場合、作成された証明書はクライアントの選択したSNIを攻撃者にリークします。
Client Attacker Server
ClientHello
+ key_share
+ ech ------> (forward) ------->
HelloRetryRequest
+ key_share
(intercept) <-------
ClientHello
+ key_share'
+ ech' ------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------
(process server flight)
Figure 4: HelloRetryRequest hijack attack
図4：HelloretryRequestハイジャック攻撃
This attack is mitigated by using the same HPKE context for both ClientHello messages. The attacker does not possess the context's keys, so it cannot generate a valid encryption of the second inner ClientHello.
この攻撃は、両方のClientHelloメッセージに対して同じHPKEコンテキストを使用することにより緩和されます。攻撃者はコンテキストのキーを所有していないため、2番目の内側クライアントヘロの有効な暗号化を生成することはできません。
If the attacker could manipulate the second ClientHello, it might be possible for the server to act as an oracle if it required parameters from the first ClientHello to match that of the second ClientHello. For example, imagine the client's original SNI value in the inner ClientHello is "example.com", and the attacker's hijacked SNI value in its inner ClientHello is "test.com". A server which checks these for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI.
攻撃者が2番目のClientHelloを操作できる場合、最初のClientHelloのパラメーターが2番目のClientHelloのパラメーターを必要とする場合、サーバーがOracleとして機能する可能性があります。たとえば、内側のクライアントヘロにおけるクライアントの元のSNI値が「example.com」であると想像してください。攻撃者のハイジャックされたSNI値は、内側のclienthelloで「test.com」です。これらを等間性をチェックし、結果に基づいて動作を変更するサーバーは、クライアントのSNIを学習するためにオラクルとして使用できます。
This attack aims to leak information about secret parts of the encrypted ClientHello by adding attacker-controlled parameters and observing the server's response. In particular, the compression mechanism described in Section 5.1 references parts of a potentially attacker-controlled ClientHelloOuter to construct ClientHelloInner, or a buggy server may incorrectly apply parameters from ClientHelloOuter to the handshake.
この攻撃の目的は、攻撃者が制御するパラメーターを追加し、サーバーの応答を観察することにより、暗号化されたClienthelloの秘密部分に関する情報をリークすることです。特に、セクション5.1で説明されている圧縮メカニズムは、攻撃者が制御する可能性のあるクライアントヘロウターの一部を参照して、クライアントヘロインナーを構築するか、バギーサーバーがclienthelloouterからハンドシェイクにパラメーターを誤って適用する場合があります。
To begin, the attacker first interacts with a server to obtain a resumption ticket for a given test domain, such as "example.com". Later, upon receipt of a ClientHelloOuter, it modifies it such that the server will process the resumption ticket with ClientHelloInner. If the server only accepts resumption PSKs that match the server name, it will fail the PSK binder check with an alert when ClientHelloInner is for "example.com" but silently ignore the PSK and continue when ClientHelloInner is for any other name. This introduces an oracle for testing encrypted SNI values.
まず、攻撃者は最初にサーバーと対話して、「Example.com」などの特定のテストドメインの再開チケットを取得します。その後、ClientHelloouterを受信すると、サーバーがClientHelloinnerで再開チケットを処理できるように変更します。サーバーがサーバー名に一致する再開PSKのみを受け入れる場合、clienthelloinnerが「example.com」の場合、PSKバインダーチェックがアラートで失敗しますが、PSKを静かに無視し、clienthelloinnerが他の名前の場合は続行します。これにより、暗号化されたSNI値をテストするためのOracleが導入されます。
Client Attacker Server
handshake and ticket
for "example.com"
<-------->
ClientHello
+ key_share
+ ech
+ ech_outer_extensions(pre_shared_key)
+ pre_shared_key
-------->
(intercept)
ClientHello
+ key_share
+ ech
+ ech_outer_extensions(pre_shared_key)
+ pre_shared_key'
-------->
Alert
-or-
ServerHello
...
Finished
<--------
Figure 5: Message flow for malleable ClientHello
図5：順応性のあるClientHelloのメッセージフロー
This attack may be generalized to any parameter which the server varies by server name, such as ALPN preferences.
この攻撃は、ALPN設定など、サーバー名によって変化する任意のパラメーターに一般化される場合があります。
ECH mitigates this attack by only negotiating TLS parameters from ClientHelloInner and authenticating all inputs to the ClientHelloInner (EncodedClientHelloInner and ClientHelloOuter) with the HPKE AEAD. See Section 5.2. An earlier iteration of this specification only encrypted and authenticated the "server_name" extension, which left the overall ClientHello vulnerable to an analogue of this attack.
ECHは、ClientHelloinnerからTLSパラメーターを交渉し、すべての入力をClientHelloinner（EncodedClientHelloinnerおよびClientHelloouter）にHPKE AEADと認証することにより、この攻撃を軽減します。セクション5.2を参照してください。この仕様の以前の反復は、「Server_Name」拡張機能を暗号化および認証しただけで、この攻撃のアナログに対してclienthello全体を脆弱にしました。
Client-facing servers must decompress EncodedClientHelloInners. A malicious attacker may craft a packet which takes excessive resources to decompress or may be much larger than the incoming packet:
クライアント向けサーバーは、EncodedClientHelloInnersを解凍する必要があります。悪意のある攻撃者は、減圧するために過度のリソースを必要とするパケットを作成したり、着信パケットよりもはるかに大きい場合があります。
* If looking up a ClientHelloOuter extension takes time linear in the number of extensions, the overall decoding process would take O(M*N) time, where M is the number of extensions in ClientHelloOuter and N is the size of OuterExtensions.
* clienthelloouter拡張機能を検索すると、拡張機能の数が時間がかかる場合、全体的なデコードプロセスにはO（m*n）時間がかかります。ここで、mはclienthelloouterの拡張数、nはoutourestensionsのサイズです。
* If the same ClientHelloOuter extension can be copied multiple times, an attacker could cause the client-facing server to construct a large ClientHelloInner by including a large extension in ClientHelloOuter, of length L, and an OuterExtensions list referencing N copies of that extension. The client-facing server would then use O(N*L) memory in response to O(N+L) bandwidth from the client. In split-mode, an O(N*L) sized packet would then be transmitted to the backend server.
* 同じClientHelloouter拡張機能を複数回コピーできる場合、攻撃者は、クライアントハロオーターにLENGTH Lの大規模な拡張機能を含めることにより、クライアント向けサーバーが大規模なClientHelloInnerを構築する可能性があります。クライアント向けサーバーは、クライアントからのO（n L）帯域幅に応じてO（n*l）メモリを使用します。スプリットモードでは、O（n*l）サイズのパケットがバックエンドサーバーに送信されます。
ECH mitigates this attack by requiring that OuterExtensions be referenced in order, that duplicate references be rejected, and by recommending that client-facing servers use a linear scan to perform decompression. These requirements are detailed in Section 5.1.
ECHは、この攻撃を緩和し、外部拡張を順番に参照すること、重複する参照を拒否し、クライアント向けサーバーが線形スキャンを使用して減圧を実行することを推奨することにより、この攻撃を軽減します。これらの要件については、セクション5.1で詳しく説明しています。
IANA is requested to create the following entries in the existing registry for ExtensionType (defined in [RFC8446]):
IANAは、extensionTypeの既存のレジストリに次のエントリを作成するように要求されています（[RFC8446]で定義）：
1. encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set to "CH, HRR, EE", and "Recommended" column set to "Yes".
1. 「CH、HRR、EE」に設定された「TLS 1.3」の列値、および「はい」に設定された「推奨」列を備えた、暗号化された_CLIENT_HELLO（0xfe0D）。
2. ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set to "", and "Recommended" column set to "Yes".
2. ech_outer_extensions（0xfd00）、「tls 1.3」列値が「 "に設定され、「はい」に設定された「推奨」列があります。
IANA is requested to create an entry, ech_required(121) in the existing registry for Alerts (defined in [RFC8446]), with the "DTLS-OK" column set to "Y".
IANAは、「y」に設定された「dtls-ok」列を備えたアラートの既存のレジストリ（[rfc8446]で定義）の既存のレジストリにech_required（121）を作成するように要求されます。
Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. This is primarily because the outer ClientHello exists only in support of ECH. Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see Section 7). In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation.
clienthelloouterに影響を与える将来の情報またはヒントは、eChconfig拡張機能として指定する必要があります。これは、主に外側のクライアントヘロがECHをサポートするためにのみ存在するためです。つまり、それは暗号化された内側のクライアントヘロの封筒と、認証されたキーミスマッチ信号のイネーブラーの両方です（セクション7を参照）。対照的に、内側のClientHelloは、ECH交渉時に使用される真のClientHelloです。
[HPKE] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.
[Hpke] Barnes、R.、Bhargavan、K.、Lipp、B。、およびC. Wood、「ハイブリッド公開キー暗号化」、RFC 9180、DOI 10.17487/RFC9180、2022年2月、<https：//www.rfc-editor.org/rfc/rfc9180>。
[HTTPS-RR] Schwartz, B. M., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-dnsop-svcb-https-12, 11 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12>.
[HTTPS-RR] Schwartz、B。M.、Bishop、M.、およびE. Nygren、「DNS（DNS SVCBおよびHTTPS RRS）を介したサービスバインディングとパラメーター仕様」、作業中、インターネットドラフト、ドラフト-IITF-DNSOP-SVCB-HTTPS-12、2023年3月11日、<https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-12>。
[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/rfc/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/rfc/RFC2119>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.
[RFC5890] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク」、RFC 5890、DOI 10.17487/RFC5890、2010年8月、<https://www.rfc-editor.org/rfc/RFC5890>。
[RFC7918] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/rfc/rfc7918>.
[RFC7918] Langley、A.、Modadugu、N.、およびB. Moeller、「Transport Layer Security（TLS）False Start」、RFC 7918、DOI 10.17487/RFC7918、2016年8月、<https：//www.rfc-editor.org/rfc/rfc7918>。
[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/rfc/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの小文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/rfc/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/rfc/rfc8446>.
[RFC8446] Rescorla、E。、「輸送層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487/RFC8446、2018年8月、<https://www.rfc-editor.org/rfc/RFC846>
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/rfc/rfc9147>。
[ECH-Analysis] "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022.
[ech-analysis]「暗号化されたクライアントHelloを使用したTLS 1.3のプライバシーの象徴的な分析」、2022年11月。
[EXPORTED-AUTHENTICATORS] Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, July 2022, <https://www.rfc-editor.org/rfc/rfc9261>.
[エクスポート - アッテンティケーター]サリバン、N。、「TLSのエクスポートされた認証者」、RFC 9261、DOI 10.17487/RFC9261、2022年7月、<https://www.rfc-editor.org/rfc/RFC9261>。
[I-D.kazuho-protected-sni] Oku, K., "TLS Extensions for Protecting SNI", Work in Progress, Internet-Draft, draft-kazuho-protected-sni-00, 18 July 2017, <https://datatracker.ietf.org/doc/html/ draft-kazuho-protected-sni-00>.
[i-d.kazuho保護-Sni] oku、K。、「SNIを保護するためのTLS拡張機能」、進行中の作業、インターネットドラフト、ドラフトカズホ保護-SNI-00、2017年7月18日、<https：// datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/rfc/rfc3986>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/rfc/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P。、およびH. Tschofenig、「サーバー側の状態なしの輸送層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487/RFC5077、2008年1月<https://www.rfc-editor.org/rfc/rfc5077>。
[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/rfc/rfc7301>.
[RFC7301] Friedl、S.、Popov、A.、Langley、A。、およびE. Stephan、「輸送層セキュリティ（TLS）アプリケーション層プロトコル交渉拡張」、RFC 7301、DOI 10.17487/RFC7301、2014年7月、<https://www.rfc-editor.org/rfc/rfc7301>。
[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/rfc/rfc7858>.
[RFC7858] Hu、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D。、およびP. Hoffman、「輸送層のセキュリティ上のDNSの仕様」、RFC 7858、doi10.17487/rfc7858、2016年5月、<https://www.rfc-editor.org/rfc/rfc7858>。
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/rfc/rfc7924>.
[RFC7924] Santesson、S。and H. Tschofenig、「輸送層のセキュリティ（TLS）キャッシュ情報拡張」、RFC 7924、DOI 10.17487/RFC7924、2016年7月、<https：//www.rfc-editor.org/rfc/RFC7924>。
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/rfc/rfc8094>.
[RFC8094] Reddy、T.、Wing、D。、およびP. Patil、「DNS over Datagram Transport Layer Security（DTLS）」、RFC 8094、DOI 10.17487/RFC8094、2017年2月、<https：//www.rfc-editor.org/rfc/rfc8094>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.
[RFC8484] Hoffman、P。and P. McManus、「dns queries over https（doh）（doh）（doh）（doh）（doh）」、RFC 8484、doi 10.17487/rfc8484、2018年10月、<https://www.rfc-editor.org/rfc/rfc8484>。
[RFC8701] Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, January 2020, <https://www.rfc-editor.org/rfc/rfc8701>.
[RFC8701]ベンジャミン、D。、「ランダム拡張を生成し、TLS拡張性（グリース）をTLS拡張性に維持する」、RFC 8701、DOI 10.17487/RFC8701、2020年1月、<https：//www.rfc-editor.org/rfc/RFC8701>。
[RFC8744] Huitema, C., "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS", RFC 8744, DOI 10.17487/RFC8744, July 2020, <https://www.rfc-editor.org/rfc/rfc8744>.
[RFC8744] Huitema、C。、「TLSのサーバー名識別（SNI）暗号化の問題と要件」、RFC 8744、DOI 10.17487/RFC8744、2020年7月、<https://www.rfc-editor.org/rfc/RFC8744>。
[WHATWG-IPV4] "URL Living Standard - IPv4 Parser", May 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.
[whatwg-ipv4] "url living Standard-ipv4 parser"、2021年5月、<https://url.spec.whatwg.org/#concept-ipv4-parser>。
Alternative approaches to encrypted SNI may be implemented at the TLS or application layer. In this section we describe several alternatives and discuss drawbacks in comparison to the design in this document.
暗号化されたSNIへの代替アプローチは、TLSまたはアプリケーションレイヤーで実装できます。このセクションでは、いくつかの選択肢について説明し、このドキュメントの設計と比較して欠点について説明します。
In this variant, TLS Client Hellos are tunneled within early data payloads belonging to outer TLS connections established with the client-facing server. This requires clients to have established a previous session - and obtained PSKs - with the server. The client-facing server decrypts early data payloads to uncover Client Hellos destined for the backend server, and forwards them onwards as necessary. Afterwards, all records to and from backend servers are forwarded by the client-facing server -- unmodified. This avoids double encryption of TLS records.
このバリアントでは、TLSクライアントHellosは、クライアント向けサーバーに確立された外部TLS接続に属する初期のデータペイロード内でトンネル化されています。これにより、クライアントはサーバーを使用して以前のセッションを確立し、PSKを取得した必要があります。クライアント向けのサーバーは、バックエンドサーバーに向けられたクライアントHellosを発見するために初期のデータペイロードを復号化し、必要に応じてそれらを前進させます。その後、バックエンドサーバーとのすべてのレコードは、クライアント向けサーバーによって転送されます - 変更されていません。これにより、TLSレコードの二重暗号化が回避されます。
Problems with this approach are: (1) servers may not always be able to distinguish inner Client Hellos from legitimate application data, (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may not be supported -- especially under DoS -- leading to availability concerns, and (4) clients must bootstrap tunnels (sessions), costing an additional round trip and potentially revealing the SNI during the initial connection. In contrast, encrypted SNI protects the SNI in a distinct Client Hello extension and neither abuses early data nor requires a bootstrapping connection.
このアプローチの問題は次のとおりです。（1）サーバーが常に正当なアプリケーションデータと正当なアプリケーションデータを区別できるとは限らない場合があります。（2）ネストされた0-RTTデータは正しく機能しない可能性があります。 - 特にDOSの下で - 利用可能性の懸念につながり、（4）クライアントはトンネル（セッション）をブートストラップし、追加の往復をコストし、最初の接続中にSNIを潜在的に明らかにする必要があります。対照的に、暗号化されたSNIは、明確なクライアントのHello ExtensionでSNIを保護し、早期データを乱用したり、ブートストラップ接続を必要としません。
In this variant, client-facing and backend servers coordinate to produce "combined tickets" that are consumable by both. Clients offer combined tickets to client-facing servers. The latter parse them to determine the correct backend server to which the Client Hello should be forwarded. This approach is problematic due to non-trivial coordination between client-facing and backend servers for ticket construction and consumption. Moreover, it requires a bootstrapping step similar to that of the previous variant. In contrast, encrypted SNI requires no such coordination.
このバリアントでは、クライアント向けサーバーとバックエンドサーバーが調整され、両方が消耗する「合計チケット」を生成します。クライアントは、クライアント向けサーバーに合わせたチケットを提供します。後者はそれらを解析して、クライアントのhelloを転送する必要がある正しいバックエンドサーバーを決定します。このアプローチは、チケットの構築と消費のためのクライアント向けサーバーとバックエンドサーバーの間の非重要な調整のために問題があります。さらに、以前のバリアントと同様のブートストラップステップが必要です。対照的に、暗号化されたSNIはそのような調整を必要としません。
In this variant, clients request secondary certificates with CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. In response, servers supply certificates via TLS exported authenticators [EXPORTED-AUTHENTICATORS] in CERTIFICATE frames. Clients use a generic SNI for the underlying client-facing server TLS connection. Problems with this approach include: (1) one additional round trip before peer authentication, (2) non-trivial application-layer dependencies and interaction, and (3) obtaining the generic SNI to bootstrap the connection. In contrast, encrypted SNI induces no additional round trip and operates below the application layer.
このバリアントでは、TLS接続の完了後にCertificate_Request HTTP/2フレームを使用して、クライアントがセカンダリ証明書を要求します。これに応じて、サーバーは、証明書フレームでTLSエクスポートされた認証機[エクスポートされたaututhenticators]を介して証明書を供給します。クライアントは、基礎となるクライアント向けサーバーTLS接続に一般的なSNIを使用します。このアプローチの問題には、（1）ピア認証の前の1つの追加の往復、（2）非自明のアプリケーション層依存関係と相互作用、（3）汎用SNIを取得して接続をブートストラップする。対照的に、暗号化されたSNIは追加の往復を誘導せず、アプリケーション層の下に動作します。
The following procedure processes the "ech_outer_extensions" extension (see Section 5.1) in linear time, ensuring that each referenced extension in the ClientHelloOuter is included at most once:
次の手順では、線形時間に「ech_outer_extensions」拡張（セクション5.1を参照）を処理し、クライアントヘロウターの各参照拡張機能がせいぜい1回含まれるようにします。
1. Let I be zero and N be the number of extensions in ClientHelloOuter.
1. 私をゼロにし、nをclienthelloouterの拡張機能の数とします。
2. For each extension type, E, in OuterExtensions:
2. 各拡張タイプ、e、outourextensions：
* If E is "encrypted_client_hello", abort the connection with an "illegal_parameter" alert and terminate this procedure.
* eが「cnecrypted_client_hello」の場合、「Illegal_parameter」アラートとの接続を中止し、この手順を終了します。
* While I is less than N and the I-th extension of ClientHelloOuter does not have type E, increment I.
* 私はn未満であり、clienthelloouterのi番目の拡張にはタイプE、インクリメントIがありません。
* If I is equal to N, abort the connection with an "illegal_parameter" alert and terminate this procedure.
* 私がnに等しい場合、「違法な_parameter」アラートとの接続を中止し、この手順を終了します。
* Otherwise, the I-th extension of ClientHelloOuter has type E. Copy it to the EncodedClientHelloInner and increment I.
* それ以外の場合、clienthelloouterのi番目の拡張機能にはタイプEがあります。エンコードClienthelloinnerとIncrement Iにコピーします。
This document draws extensively from ideas in [I-D.kazuho-protected-sni], but is a much more limited mechanism because it depends on the DNS for the protection of the ECH key. Richard Barnes, Christian Huitema, Patrick McManus, Matthew Prince, Nick Sullivan, Martin Thomson, and David Benjamin also provided important ideas and contributions.
このドキュメントは、[i-d.kazuho保護-Sni]のアイデアから広範囲に描かれていますが、ECHキーの保護のためのDNSに依存するため、はるかに限られたメカニズムです。リチャード・バーンズ、クリスチャン・フイテマ、パトリック・マクマナス、マシュー・プリンス、ニック・サリバン、マーティン・トムソン、デビッド・ベンジャミンも重要なアイデアと貢献を提供しました。
*RFC Editor's Note:* Please remove this section prior to publication of a final version of this document.
* RFCエディターズ注：*このドキュメントの最終バージョンを公開する前に、このセクションを削除してください。
Issue and pull request numbers are listed with a leading octothorp.
発行およびプル要求番号は、主要なOctothorpにリストされています。
* Keep-alive
* 生き続ける
* Add CCS2022 reference and summary (#539)
* CCS2022の参照と要約を追加（＃539）
* Keep-alive
* 生き続ける
* Editorial improvements
* 編集の改善
* Abort on duplicate OuterExtensions (#514)
* 重複したoutourestensions（＃514）を中止する
* Improve EncodedClientHelloInner definition (#503)
* EncodedClientHelloinnerの定義を改善する（＃503）
* Clarify retry configuration usage (#498)
* 再生構成の使用法を明確にする（＃498）
* Expand on config_id generation implications (#491)
* config_id生成の影響を展開する（＃491）
* Server-side acceptance signal extension GREASE (#481)
* サーバー側の受け入れ信号拡張グリース（＃481）
* Refactor overview, client implementation, and middlebox sections (#480, #478, #475, #508)
* リファクタリングの概要、クライアントの実装、およびミドルボックスセクション（＃480、＃478、＃475、＃508）
* Editorial iprovements (#485, #488, #490, #495, #496, #499, #500, #501, #504, #505, #507, #510, #511)
* 編集iProvements（＃485、＃488、＃490、＃495、＃496、＃499、＃500、＃501、＃504、＃505、＃507、＃510、＃511）
* Move ClientHello padding to the encoding (#443)
* clienthelloのパディングをエンコードに移動する（＃443）
* Align codepoints (#464)
* CodePointsを調整する（＃464）
* Relax OuterExtensions checks for alignment with RFC8446 (#467)
* rfc8446（＃467）とのアラインメントをチェックするoutourtextensionsをリラックス
* Clarify HRR acceptance and rejection logic (#470)
* HRRの受け入れと拒否の論理を明確にする（＃470）
* Editorial improvements (#468, #465, #462, #461)
* 編集の改善（＃468、＃465、＃462、＃461）
* Make HRR confirmation and ECH acceptance explicit (#422, #423)
* HRRの確認とECHの受け入れを明示する（＃422、＃423）
* Relax computation of the acceptance signal (#420, #449)
* 受け入れ信号のリラックス計算（＃420、＃449）
* Simplify ClientHelloOuterAAD generation (#438, #442)
* clienthelloouteraad生成を簡素化する（＃438、＃442）
* Allow empty enc in ECHClientHello (#444)
* echclienthello（＃444）で空のcを許可する
* Authenticate ECHClientHello extensions position in ClientHelloOuterAAD (#410)
* clienthelloouteraad（＃410）のechclienthello拡張機能を認証する
* Allow clients to send a dummy PSK and early_data in ClientHelloOuter when applicable (#414, #415)
* 該当する場合は、クライアントがクライアントヘロウターでダミーPSKとearly_Dataを送信できるようにします（＃414、＃415）
* Compress ECHConfigContents (#409)
* ECHCONFIGCONTENTSを圧縮する（＃409）
* Validate ECHConfig.contents.public_name (#413, #456)
* echconfig.contents.public_name（＃413、＃456を検証する
* Validate ClientHelloInner contents (#411)
* clienthelloinnerコンテンツを検証する（＃411）
* Note split-mode challenges for HRR (#418)
* HRRのスプリットモードの課題に注意（＃418）
* Editorial improvements (#428, #432, #439, #445, #458, #455)
* 編集の改善（＃428、＃432、＃439、＃445、＃458、＃455）
* Finalize HPKE dependency (#390)
* HPKE依存関係を完成させる（＃390）
* Move from client-computed to server-chosen, one-byte config identifier (#376, #381)
* クライアントコンピューターからサーバーの選択、1バイトの構成識別子（＃376、＃381）に移行する
* Rename ECHConfigs to ECHConfigList (#391)
* echconfigsをechconfiglistに変更する（＃391）
* Clarify some security and privacy properties (#385, #383)
* いくつかのセキュリティとプライバシーのプロパティを明確にする（＃385、＃383）
Authors' Addresses
著者のアドレス
Eric Rescorla RTFM, Inc. Email: ekr@rtfm.com
Eric Rescorla RTFM、Inc。電子メール：ekr@rtfm.com
Kazuho Oku Fastly Email: kazuhooku@gmail.com
Kazuho oku早く電子メール：kazuooku@gmail.com
Nick Sullivan Cloudflare Email: nick@cloudflare.com
Nick Sullivan Cloudflareメール：nick@cloudflare.com
Christopher A. Wood Cloudflare Email: caw@heapingbits.net
Christopher A. Wood Cloudflareメール：caw@heapingbits.net
Rescorla, et al. Expires 11 April 2024 [Page 48]
Rescorla、et al。2024年4月11日の有効期限[48ページ]