[要約] TLSのClientHelloメッセージをサーバーの公開鍵で暗号化し、SNIやALPNなどの機密情報を保護するECH（Encrypted Client Hello）メカニズムを規定しています。共有モードと分割モードのトポロジーを定義し、HPKEを用いて暗号化したClientHelloInnerをClientHelloOuterに格納して送信する仕組みを導入しています。サーバーがECHを拒否した際の再試行手順や、接続の匿名性を高めるためのパディング方式、ダウングレード攻撃への対策などのセキュリティ要件を詳述しています。
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 9849 Independent
Category: Standards Track 奥 一穂 (K. Oku)
ISSN: 2070-1721 Fastly
N. Sullivan
Cryptography Consulting LLC
C. A. Wood
Apple
March 2026
This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.
このドキュメントでは、サーバー公開キーで ClientHello メッセージを暗号化するための Transport Layer Security (TLS) のメカニズムについて説明します。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9849.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9849 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 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 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Conventions and Definitions
3. Overview
3.1. Topologies
3.2. Encrypted ClientHello (ECH)
4. Encrypted ClientHello Configuration
4.1. Configuration Identifiers
4.2. Configuration Extensions
5. The "encrypted_client_hello" Extension
5.1. Encoding the ClientHelloInner
5.2. Authenticating the ClientHelloOuter
6. Client Behavior
6.1. Offering ECH
6.1.1. Encrypting the ClientHello
6.1.2. GREASE PSK
6.1.3. Recommended Padding Scheme
6.1.4. Determining ECH Acceptance
6.1.5. Handshaking with ClientHelloInner
6.1.6. Handshaking with ClientHelloOuter
6.1.7. Authenticating for the Public Name
6.1.8. Impact of Retry on Future Connections
6.2. GREASE ECH
6.2.1. Client Greasing
6.2.2. Server Greasing
7. Server Behavior
7.1. Client-Facing Server
7.1.1. Processing ClientHello after HelloRetryRequest
7.2. Backend Server
7.2.1. Sending HelloRetryRequest
8. Deployment Considerations
8.1. Compatibility Issues
8.1.1. Misconfiguration and Deployment Concerns
8.1.2. Middleboxes
8.2. Deployment Impact
9. Compliance Requirements
10. Security Considerations
10.1. Security and Privacy Goals
10.2. Unauthenticated and Plaintext DNS
10.3. Client Tracking
10.4. Ignored Configuration Identifiers and Trial Decryption
10.5. Outer ClientHello
10.6. Inner ClientHello
10.7. Related Privacy Leaks
10.8. Cookies
10.9. Attacks Exploiting Acceptance Confirmation
10.10. Comparison Against Criteria
10.10.1. Mitigate Cut-and-Paste Attacks
10.10.2. Avoid Widely Shared Secrets
10.10.3. SNI-Based Denial-of-Service Attacks
10.10.4. Do Not Stick Out
10.10.5. Maintain Forward Secrecy
10.10.6. Enable Multi-party Security Contexts
10.10.7. Support Multiple Protocols
10.11. Padding Policy
10.12. Active Attack Mitigations
10.12.1. Client Reaction Attack Mitigation
10.12.2. HelloRetryRequest Hijack Mitigation
10.12.3. ClientHello Malleability Mitigation
10.12.4. ClientHelloInner Packet Amplification Mitigation
11. IANA Considerations
11.1. Update of the TLS ExtensionType Registry
11.2. Update of the TLS Alert Registry
11.3. ECH Configuration Extension Registry
12. References
12.1. Normative References
12.2. Informative References
Appendix A. Linear-Time Outer Extension Processing
Acknowledgements
Authors' Addresses
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 information left unencrypted in TLS 1.3.
TLS 1.3 [RFC8446] はサーバー証明書を含むハンドシェイクのほとんどを暗号化しますが、パス上の攻撃者が接続に関する個人情報を知る方法はいくつかあります。ClientHello メッセージ内の平文の Server Name Indication (SNI) 拡張子は、特定の接続のターゲット ドメインを漏洩しますが、おそらく TLS 1.3 で暗号化されずに残されている最も機密情報です。
This document specifies a new TLS extension called Encrypted Client Hello (ECH) that allows clients to encrypt their ClientHello to the TLS server. This protects the SNI and other potentially sensitive fields, such as the Application-Layer Protocol Negotiation (ALPN) list [RFC7301]. Co-located servers with consistent externally visible TLS configurations and behavior, including supported versions and cipher suites and how they respond to incoming client connections, form an anonymity set. (Note that implementation-specific choices, such as extension ordering within TLS messages or division of data into record-layer boundaries, can result in different externally visible behavior, even for servers with consistent TLS configurations.) 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. Deployment implications of this feature are discussed in Section 8.
この文書では、クライアントが ClientHello を TLS サーバーに対して暗号化できるようにする、Encrypted Client Hello (ECH) と呼ばれる新しい TLS 拡張機能を指定します。これにより、SNI や、アプリケーション層プロトコル ネゴシエーション (ALPN) リスト [RFC7301] などのその他の潜在的に機密性の高いフィールドが保護されます。サポートされているバージョンや暗号スイート、受信クライアント接続への応答方法など、外部から見える一貫した TLS 構成と動作を備えた同じ場所に配置されたサーバーは、匿名性セットを形成します。(TLS メッセージ内での拡張子の順序付けやレコード層境界へのデータの分割など、実装固有の選択により、一貫した TLS 構成を持つサーバーであっても、外部から見える動作が異なる場合があることに注意してください。) このメカニズムを使用すると、クライアントが特定のサービス プロバイダーに接続していることが明らかになりますが、匿名性セットのどのサーバーが接続を終了するかは明らかにされません。この機能の展開への影響については、セクション 8 で説明します。
ECH is not in itself sufficient to protect the identity of the server. The target domain may also be visible through other channels, such as plaintext client DNS queries or visible server IP addresses. However, encrypted DNS mechanisms such as DNS over HTTPS [RFC8484], DNS over TLS/DTLS [RFC7858] [RFC8094], and DNS over QUIC [RFC9250] 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 available to observers to determine the server's identity.
ECH だけではサーバーの ID を保護するのに十分ではありません。ターゲット ドメインは、平文のクライアント DNS クエリや可視のサーバー IP アドレスなど、他のチャネルを通じて可視になる場合もあります。ただし、DNS over HTTPS [RFC8484]、DNS over TLS/DTLS [RFC7858] [RFC8094]、DNS over QUIC [RFC9250] などの暗号化 DNS メカニズムは、クライアントがネットワーク検査から DNS ルックアップを隠すメカニズムを提供しており、多くの TLS サーバーは同じ IP アドレスで複数のドメインをホストしています。プライベート オリジンは、リバース プロキシなどの共通プロバイダーの背後に展開することもできます。このような環境では、SNI は、サーバーの ID を判断するためにオブザーバーが利用できる主要な明示的な信号のままです。
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.
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「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". These modes are described in the following section.
このプロトコルは、以下に示す 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 レコードがそれを指すすべてのドメインのオリジン サーバーになります。このモードでは、TLS 接続はプロバイダーによって終了されます。
+--------------------+ +---------------------+
| | | |
| 2001:DB8::1111 | | 2001:DB8::EEEE |
Client <----------------------------->| |
| public.example.com | | private.example.org |
| | | |
+--------------------+ +---------------------+
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.
分割モードでは、プロバイダーはプライベート ドメインのオリジン サーバーではありません。むしろ、プライベート ドメインの DNS レコードはプロバイダーを指し、プロバイダーのサーバーは接続を元のサーバーに中継し、オリジン サーバーがクライアントとの TLS 接続を終了します。重要なのは、サービス プロバイダーは、ハンドシェイクの暗号化されていない部分を超える接続の平文にはアクセスできないことです。
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 ターミネーターを「バックエンド サーバー」と呼びます。これらは共有モードでは同じエンティティですが、分割モードでは、クライアント側サーバーとバックエンド サーバーは物理的に分離されます。
See Section 10 for more discussion about the ECH threat model and how it relates to the client, client-facing server, and backend server.
ECH 脅威モデルと、それがクライアント、クライアント側サーバー、およびバックエンド サーバーにどのように関連するかについての詳細は、セクション 10 を参照してください。
A client-facing server enables ECH by publishing an ECH configuration, which is an encryption public key and associated metadata. Domains which wish to use ECH must publish this configuration, using the key associated with the client-facing server. This document defines the ECH configuration's format, but delegates DNS publication details to [RFC9460]. See [RFC9848] for specifics about how ECH configurations are advertised in SVCB and HTTPS records. Other delivery mechanisms are also possible. For example, the client may have the ECH configuration preconfigured.
クライアント側サーバーは、暗号化公開キーと関連するメタデータである ECH 構成を公開することで ECH を有効にします。ECH を使用したいドメインは、クライアント側サーバーに関連付けられたキーを使用して、この構成を公開する必要があります。この文書は ECH 設定の形式を定義しますが、DNS 公開の詳細は [RFC9460] に委任されます。ECH 設定が SVCB および HTTPS レコードでどのようにアドバタイズされるかについての詳細は、[RFC9848] を参照してください。Other delivery mechanisms are also possible.たとえば、クライアントには 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 と呼ばれるプライベート ClientHello を構築します。次に、クライアントは、ClientHelloOuter と呼ばれるパブリック 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 Hybrid Public Key Encryption (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 RFC 9180
uint16 HpkeKdfId; // Defined in RFC 9180
uint16 HpkeAeadId; // Defined in RFC 9180
uint16 ECHConfigExtensionType; // Defined in Section 11.3
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 {
ECHConfigExtensionType type;
opaque data<0..2^16-1>;
} ECHConfigExtension;
struct {
HpkeKeyConfig key_config;
uint8 maximum_name_length;
opaque public_name<1..255>;
ECHConfigExtension 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. 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 のバージョン。バージョンは、「encrypted_client_hello」拡張機能のコード ポイントと同じです。クライアントは、サポートしていないバージョンの ECHConfig 構造を無視しなければなりません (MUST)。
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:
key_config:
A HpkeKeyConfig structure carrying the configuration information associated with the HPKE public key (an "ECH key"). Note that this structure contains the config_id field, which applies to the entire ECHConfigContents.
HPKE 公開キー (「ECH キー」) に関連付けられた構成情報を保持する HpkeKeyConfig 構造体。この構造には config_id フィールドが含まれており、これは ECHConfigContents 全体に適用されることに注意してください。
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.
バックエンド サーバーの最長の名前 (既知の場合)。不明な場合は、この値をゼロに設定できます。これはパディング (セクション 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.
クライアント側サーバー、つまり ECH 構成を更新することが信頼されているエンティティの DNS 名。これは、セクション 6.1.6 で説明されているように、誤って設定されたクライアントを修正するために使用されます。
See Section 6.1.7 for how the client interprets and validates the public_name.
クライアントが public_name を解釈および検証する方法については、セクション 6.1.7 を参照してください。
extensions:
拡張子:
A list of ECHConfigExtension values that the client must take into consideration when generating a ClientHello message. Each ECHConfigExtension has a 2-octet type and opaque data value, where the data value is encoded with a 2-octet integer representing the length of the data, in network byte order. ECHConfigExtension values are described below (Section 4.2).
ClientHello メッセージを生成するときにクライアントが考慮する必要がある ECHConfigExtension 値のリスト。各 ECHConfigExtension には 2 オクテットのタイプと不透明なデータ値があり、データ値はネットワーク バイト オーダーでデータの長さを表す 2 オクテットの整数でエンコードされます。ECHConfigExtension の値については以下で説明します (セクション 4.2)。
The HpkeKeyConfig structure contains the following fields:
HpkeKeyConfig 構造には次のフィールドが含まれます。
config_id:
構成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.
指定された HPKE キー構成の 1 バイトの識別子。これは、ClientHello 暗号化に使用されるキーを示すためにクライアントによって使用されます。セクション 4.1 では、クライアント側サーバーがこの値を割り当てる方法について説明します。
kem_id:
kem_id:
The HPKE Key Encapsulation Mechanism (KEM) identifier corresponding to public_key. Clients MUST ignore any ECHConfig structure with a key using a KEM they do not support.
public_key に対応する HPKE キー カプセル化メカニズム (KEM) 識別子。クライアントは、サポートしていない KEM を使用するキーを持つ ECHConfig 構造を無視しなければなりません (MUST)。
public_key:
公開キー:
The HPKE public key used by the client to encrypt ClientHelloInner.
ClientHelloInner を暗号化するためにクライアントによって使用される HPKE 公開キー。
cipher_suites:
暗号スイート:
The list of HPKE Key Derivation Function (KDF) and Authenticated Encryption with Associated Data (AEAD) identifier pairs clients can use for encrypting ClientHelloInner. See Section 6.1 for how clients choose from this list.
クライアントが ClientHelloInner の暗号化に使用できる HPKE Key Derivation Function (KDF) および Authenticated Encryption with Associated Data (AEAD) 識別子のペアのリスト。クライアントがこのリストから選択する方法については、セクション 6.1 を参照してください。
The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.
クライアント側サーバーは、次のようにシリアル化された一連の ECH 構成をクライアントにアドバタイズします。
ECHConfig ECHConfigList<4..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 以上キャッシュする可能性があるため、このセットには現在公開されている値だけでなく、まだ使用されている可能性のある以前の値も含めるべきです(SHOULD)。
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 値を割り当てる必要があります (SHOULD)。推奨される戦略は、拒否サンプリングによるものです。つまり、既知の 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. The format is as defined in Section 4 and mirrors Section 4.2 of [RFC8446]. However, ECH configuration extension types are maintained by IANA as described in Section 11.3. ECH configuration extensions follow the same interpretation rules as TLS extensions: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block. Unlike TLS extensions, an extension can be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.
ECH 構成拡張機能は、必要に応じて追加機能のための余地を提供するために使用されます。この形式はセクション 4 で定義されており、[RFC8446] のセクション 4.2 を反映しています。ただし、ECH 構成拡張タイプは、セクション 11.3 で説明されているように IANA によって維持されます。ECH 設定拡張は、TLS 拡張と同じ解釈規則に従います。拡張は任意の順序で出現しても構いませんが、拡張ブロック内に同じタイプの拡張が複数存在してはなりません。TLS 拡張機能とは異なり、上位ビットを 1 に設定した拡張タイプ コードポイントを使用することで、拡張機能に必須のタグを付けることができます。
Clients MUST parse the extension list and check for unsupported mandatory extensions. If an unsupported mandatory extension is present, clients MUST ignore the ECHConfig.
クライアントは拡張子リストを解析し、サポートされていない必須拡張子がないかチェックしなければなりません (MUST)。サポートされていない必須拡張機能が存在する場合、クライアントは ECHConfig を無視しなければなりません (MUST)。
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 an enabler for authenticated key mismatch signals (see Section 7). In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation.
ClientHelloOuter に影響を与える今後の情報やヒントは、ECHConfig 拡張機能として指定する必要があります (SHOULD)。これは主に、外側の ClientHello が ECH をサポートするためにのみ存在するためです。つまり、これは、暗号化された内部 ClientHello のエンベロープであり、認証されたキー不一致信号のイネーブラーでもあります (セクション 7 を参照)。対照的に、内部の ClientHello は、ECH ネゴシエーション時に使用される真の ClientHello です。
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, which is included because TLS servers are not allowed to provide extensions in ServerHello which were not included in ClientHello. The outer extension has the following fields:
外側の拡張機能は外側のバリアントを使用し、内側の拡張機能は内側のバリアントを使用します。内部拡張には空のペイロードがあります。これは、TLS サーバーが ClientHello に含まれていない拡張を ServerHello で提供することを許可されていないため、含まれています。The outer extension has the following fields:
config_id:
構成ID:
The ECHConfigContents.key_config.config_id for the chosen ECHConfig.
選択した 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.key_config.cipher_suites list.
ClientHelloInner の暗号化に使用される暗号スイート。これは、対応する ECHConfigContents.key_config.cipher_suites リストで提供される値と一致する必要があります。
enc:
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 カプセル化キー。HelloRetryRequest に応答して送信される ClientHelloOuter では、このフィールドは空です。
payload:
ペイロード：
The serialized and encrypted EncodedClientHelloInner structure, encrypted using HPKE as described in Section 6.1.
シリアル化および暗号化された EncodedClientHelloInner 構造。セクション 6.1 で説明されているように HPKE を使用して暗号化されます。
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 で説明されているように、EncryptedExtensions メッセージに次のペイロードを持つ「encrypted_client_hello」拡張機能を含めてもよい(MAY)。
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:
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".
セクション 6.1.6 で説明されているように、クライアントによって使用される 1 つ以上の ECHConfig 構造体を優先順位の降順で含む ECHConfigList 構造体。これらは、サーバーの「再試行構成」として知られています。
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.
ECHHelloRetryRequest.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」アラートも定義します。クライアントは、サーバーが受け入れなかった「encrypted_client_hello」拡張機能を提供したときに、このアラートを送信しなければなりません。(セクション11.2を参照してください。)
Before encrypting, the client pads and optionally compresses ClientHelloInner into an 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. In TLS, this field uses the ClientHello structure defined in Section 4.1.2 of [RFC8446]. In DTLS, it uses the ClientHello structure defined in Section 5.3 of [RFC9147]. This does not include the Handshake structure's four-byte header in TLS, nor the twelve-byte header in DTLS. The zeros field MUST be all zeros of length length_of_padding (see Section 6.1.3).
client_hello フィールドは、最初に ClientHelloInner のコピーを作成し、legacy_session_id フィールドを空の文字列に設定することによって計算されます。TLS では、このフィールドは [RFC8446] のセクション 4.1.2 で定義されている ClientHello 構造を使用します。DTLS では、[RFC9147] のセクション 5.3 で定義されている ClientHello 構造を使用します。これには、TLS のハンドシェイク構造の 4 バイトのヘッダーや、DTLS の 12 バイトのヘッダーは含まれません。ゼロフィールドは長さ length_of_padding のすべてがゼロでなければなりません (セクション 6.1.3 を参照)。
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:
ClientHelloInner と ClientHelloOuter の間でポスト量子アルゴリズムを使用した「key_share」などの大規模な拡張を繰り返すと、サイズが過剰になる可能性があります。サイズへの影響を軽減するために、クライアントは、ClientHelloOuter で重複することがわかっている拡張機能を置き換えてもよい (MAY)。これは、EncodedClientHelloInner から拡張機能を削除し、次のように定義された単一の「ech_outer_extensions」拡張機能に置き換えることによって行われます。
enum {
ech_outer_extensions(0xfd00), (65535)
} ExtensionType;
ExtensionType OuterExtensions<2..254>;
OuterExtensions contains a list of 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, and C, while ClientHelloOuter contains extensions A, D, B, C, E, and F.
OuterExtensions には、削除された 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」拡張子は EncodedClientHelloInner にのみ含めることができ、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 を計算します。まず、EncodedClientHelloInner を解析し、client_hello 以降のすべてのバイトをパディングとして解釈します。パディングバイトがゼロ以外の場合、サーバーは「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 から Legacy_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.
* すべての拡張機能は、OuterExtensions で複数回参照されます。
* "encrypted_client_hello" is referenced in OuterExtensions.
* 「encrypted_client_hello」は、OuterExtensions で参照されます。
* The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.
* OuterExtensions の拡張機能に対応する 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.12.4.
これらの要件により、攻撃者がはるかに大きな ClientHelloInner に解凍する ClientHelloOuter を作成してパケット増幅攻撃を実行することが防止されます。これについてはセクション 10.12.4 で詳しく説明します。
Receiving implementations SHOULD construct the ClientHelloInner in linear time. Quadratic time implementations (such as may happen via naive copying) create a denial-of-service risk. Appendix A describes a linear-time procedure that may be used for this purpose.
受信実装は、ClientHelloInner を線形時間で構築する必要があります (SHOULD)。二次時間の実装 (単純なコピーによって発生する可能性のあるものなど) は、サービス拒否のリスクを引き起こします。付録 A では、この目的に使用できる線形時間手順について説明します。
To prevent a network attacker from modifying the ClientHelloOuter while keeping the same encrypted ClientHelloInner (see Section 10.12.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] for TLS and Section 5.3 of [RFC9147] for DTLS, which matches the ClientHelloOuter except that 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 Handshake structure's four-byte header in TLS nor the twelve-byte header in DTLS.
ネットワーク攻撃者が同じ暗号化された ClientHelloInner (セクション 10.12.3 を参照) を保持したまま ClientHelloOuter を変更するのを防ぐために、ECH は HPKE シーリングおよびオープン操作の関連データとして ClientHelloOuterAAD を渡すことによって ClientHelloOuter を認証します。ClientHelloOuterAAD は、TLS については [RFC8446] のセクション 4.1.2、DTLS については [RFC9147] のセクション 5.3 で定義されているシリアル化された ClientHello 構造体であり、「encrypted_client_hello」のペイロード フィールドが同じ長さのバイト文字列で置き換えられる点を除いて ClientHelloOuter と一致しますが、その内容はゼロです。この値には、ハンドシェイク構造の TLS の 4 バイト ヘッダーや DTLS の 12 バイト ヘッダーは含まれません。
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 Generate Random Extensions And Sustain Extensibility (GREASE) [RFC8701] ECH extension, as described in Section 6.2. The client offers ECH if it is in possession of a compatible ECH configuration and sends GREASE ECH (see Section 6.2) otherwise. 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.10.4 for an explanation.) It is also possible for clients to always send GREASE ECH without implementing the remainder of this specification.
ECH 拡張を実装するクライアントは 2 つの方法のいずれかで動作します。セクション 6.1 で説明されているように実際の ECH 拡張を提供するか、セクション 6.2 で説明されているように Generate Random Extensions And Sustain Extensibility (GREASE) [RFC8701] ECH 拡張を送信します。クライアントは、互換性のある ECH 構成を所有している場合は ECH を提供し、そうでない場合は GREASE ECH (セクション 6.2 を参照) を送信します。後者のタイプのクライアントは ECH をネゴシエートしません。代わりに、サーバーによって無視されるダミーの ECH 拡張子が生成されます。(説明については、セクション 10.10.4 を参照してください。) クライアントが、この仕様の残りの部分を実装せずに、常に GREASE 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.key_config.kem_id, at least one KDF/AEAD algorithm identified by ECHConfig.contents.key_config.cipher_suites, and the version of ECH indicated by ECHConfig.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.key_config.kem_id で識別される KEM アルゴリズム、ECHConfig.contents.key_config.cipher_suites で識別される少なくとも 1 つの KDF/AEAD アルゴリズム、および ECHConfig.version で示される ECH のバージョンをサポートしているかどうかを確認します。適切な構成が見つかると、クライアントは暗号化に使用する暗号スイートを選択します。構成によってアドバタイズされていない暗号スイートまたはバージョンを選択してはなりません。互換性のある構成が見つからない場合、クライアントはセクション 6.2 で説明されているように続行する必要があります (SHOULD)。
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 を参照)、それらの拡張子を連続して順序付けしなければなりません (MUST)。
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 で説明されているように、タイプ inner の "encrypted_client_hello" 拡張子を含めなければなりません (この要件は、セクション 6.2 で説明しているように "encrypted_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.key_config.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:
次に、標準の ClientHello と同様に、部分的な 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 からコピーしなければなりません (MUST)。さらに、コピーされた拡張機能は、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. Note that compatibility mode is not used in DTLS 1.3, but following this rule will produce the correct results for both TLS 1.3 and DTLS 1.3.
3. ClientHelloInner から Legacy_session_id フィールドをコピーする必要があります。これにより、ECH がネゴシエートされるときに、サーバーは TLS 1.3 の互換モード ([RFC8446] の付録 D.4 を参照) の正しいセッション ID をエコーすることができます。互換モードは DTLS 1.3 では使用されませんが、このルールに従うと、TLS 1.3 と DTLS 1.3 の両方で正しい結果が生成されることに注意してください。
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.12.1.)
4. ClientHelloInner.random を除く、ClientHelloInner から他のフィールドをコピーしてもよい(MAY)。代わりに、安全な乱数ジェネレーターを使用して新しい ClientHelloOuter.random を生成しなければなりません。(セクション10.12.1を参照してください。)
5. It SHOULD place the value of ECHConfig.contents.public_name in the "server_name" extension. Clients that do not follow this step, or place a different value in the "server_name" extension, risk breaking the retry mechanism described in Section 6.1.6 or failing to interoperate with servers that require this step to be done; see Section 7.1.
5. ECHConfig.contents.public_name の値を「server_name」拡張子に配置すべきです (SHOULD)。クライアントがこの手順に従わない場合、または「server_name」拡張子に別の値を設定した場合、セクション 6.1.6 で説明されている再試行メカニズムが壊れるか、この手順の実行が必要なサーバーとの相互運用が失敗する危険があります。セクション 7.1 を参照してください。
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.12.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 で説明されている方法で生成された、ClientHelloOuter の GREASE「pre_shared_key」拡張機能も含めるべきです (SHOULD)。クライアントは、クライアント側サーバーに PSK をアドバタイズするためにこの拡張機能を使用してはなりません (MUST NOT)。(セクション 10.12.3 を参照。) クライアントに GREASE "pre_shared_key" 拡張機能が含まれている場合、"psk_key_exchange_modes" も ClientHelloInner から ClientHelloOuter にコピーしなければなりません。
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 で「early_data」拡張機能を提供する場合、ClientHelloOuter にも「early_data」拡張機能を含める必要があります。これにより、ECH を拒否し、ClientHelloOuter を使用するサーバーは、[RFC8446] セクション 4.2.10 に従ってクライアントによって送信された初期データを安全に無視できるようになります。
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 で説明されているように、上記の値を使用して EncodedClientHelloInner を暗号化し、ClientHelloOuter を構築します。これをサーバーに送信し、セクション 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 が与えられると、クライアントは次のように ClientHelloOuter を構築します。
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 を使用して EncodedClientHelloInner を暗号化する長さ 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 個のゼロを含むプレースホルダー バイト文字列。
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 a HelloRetryRequest (HRR), MUST be left unchanged for the second ClientHelloOuter.
設定識別子(セクション10.4を参照)が無視される場合、config_idは最初のClientHelloOuterでランダムに生成されたバイトに設定されるべきであり(SHOULD)、HelloRetryRequest(HRR)の場合には、2番目のClientHelloOuterでは変更されないままにしなければなりません(MUST)。
The client serializes this structure to construct the ClientHelloOuterAAD. It then computes the final payload as:
クライアントはこの構造体をシリアル化して ClientHelloOuterAAD を構築します。次に、最終的なペイロードを次のように計算します。
final_payload = context.Seal(ClientHelloOuterAAD,
EncodedClientHelloInner)
Including ClientHelloOuterAAD as the HPKE AAD binds the ClientHelloOuter to the ClientHelloInner, thus preventing attackers from modifying ClientHelloOuter while keeping the same ClientHelloInner, as described in Section 10.12.3.
ClientHelloOuterAAD を HPKE AAD として含めると、ClientHelloOuter が ClientHelloInner にバインドされ、セクション 10.12.3 で説明されているように、攻撃者が同じ ClientHelloInner を維持しながら ClientHelloOuter を変更するのを防ぎます。
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 server were sending this extension without solicitation, which would violate the extension rules described in [RFC8446]. When offering a PSK in ClientHelloInner, clients SHOULD send a GREASE "pre_shared_key" extension in the ClientHelloOuter to make 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] で説明されている拡張機能の規則に違反します。ClientHelloInner で PSK を提供する場合、クライアントは、ClientHelloOuter で GREASE "pre_shared_key" 拡張機能を送信し、拡張機能が適切にネゴシエートされたかのようにネットワークに見せる必要があります (SHOULD)。
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.
クライアントは、次のように OfferedPsks 構造体 ([RFC8446]、セクション 4.2.11 を参照) を構築することにより、拡張ペイロードを生成します。ClientHelloInner でアドバタイズされる PSK ID ごとに、クライアントは同じ長さのランダムな PSK ID を生成します。また、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" アラートでハンドシェイクを中止しなければなりません (MUST)。
If the ClientHelloInner is encrypted without padding, then the length of the ClientHelloOuter.payload can leak information about ClientHelloInner. In order to prevent this, the EncodedClientHelloInner structure has a padding field. This section describes a deterministic mechanism for computing the required amount of padding 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.
ClientHelloInner がパディングなしで暗号化されている場合、ClientHelloOuter.payload の長さによって ClientHelloInner に関する情報が漏洩する可能性があります。これを防ぐために、EncodedClientHelloInner 構造体にはパディング フィールドがあります。このセクションでは、次の観察に基づいて、必要なパディング量を計算するための決定論的なメカニズムについて説明します。個々の拡張機能は、その長さを通じて機密情報を明らかにする可能性があります。したがって、内部 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 と、ALPN 値 ["webrtc"、"c-webrtc"] の WebRTC メディアをサポートする場合があります。クライアントは、すべてのアプリケーション プロファイルにわたる最長の ALPN 拡張子の合計サイズに切り上げて、この拡張子をパディングする必要があります (SHOULD)。ほとんどの 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 M is the maximum_name_length value.
対照的に、クライアントは、サーバー入力がなければ、クライアント側サーバーの匿名性セット内の最長の SNI 値を知りません。クライアントは、ECHConfig の Maximum_name_length フィールドを次のように使用する必要があります (M は Maximum_name_length 値です)。
1. If the ClientHelloInner contained a "server_name" extension with a name of length D, add max(0, M - D) bytes of padding.
1. ClientHelloInner に長さ D の名前を持つ「server_name」拡張子が含まれている場合は、max(0, M - D) バイトのパディングを追加します。
2. If the ClientHelloInner did not contain a "server_name" extension (e.g., if the client is connecting to an IP address), add M + 9 bytes of padding. This is the length of a "server_name" extension with an M-byte name.
2. ClientHelloInner に「server_name」拡張子が含まれていない場合 (たとえば、クライアントが IP アドレスに接続している場合)、M + 9 バイトのパディングを追加します。これは、M バイトの名前を持つ「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 を、これまでに計算されたすべてのパディングを含む EncodedClientHelloInner の長さとします。
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 値を提案した場合、サーバーが選択した値が EncryptedExtension で返されるため、ハンドシェイク メッセージも 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 を使用することも、ECH を拒否して ClientHelloOuter を使用することもできます。これはサーバーの最初のメッセージによって決まります。
If the message does not negotiate TLS 1.3 or higher, the server has rejected ECH. Otherwise, the message will be either a ServerHello or a 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_confirmation を計算します。この値が 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 the extension has a length other than 8, the client MUST abort 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 の場合、クライアントは「encrypted_client_hello」拡張子をチェックします。何も見つからない場合、サーバーは ECH を拒否しました。それ以外の場合、拡張子の長さが 8 以外の場合、クライアントは「decode_error」アラートを出してハンドシェイクを中止しなければなりません (MUST)。それ以外の場合、クライアントはセクション 7.2.1 で説明されているように hrr_accept_confirmation を計算します。この値が拡張ペイロードと一致する場合、サーバーは ECH を受け入れています。それ以外の場合は、ECH が拒否されます。
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 で説明されているように ClientHelloInner とハンドシェイクします。それ以外の場合、クライアントはセクション 6.1.6 で説明されているように ClientHelloOuter とハンドシェイクします。
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:
サーバーが HelloRetryRequest で応答すると、クライアントは更新された ClientHello メッセージを次のように計算します。
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.
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 から変更せずにコピーするか、省略してもよい (MAY)。機密でない場合、クライアントは圧縮のために 2 番目の ClientHelloInner から更新された拡張子をコピーしてもよい(MAY)。
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 で説明されているように、2 番目の部分 ClientHelloOuterAAD を使用して EncodedClientHelloInner を暗号化し、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.12.2.
HPKE コンテキストはシーケンス番号を維持するため、この操作は各 AEAD 操作に対して内部で新しいノンスを使用します。HPKE コンテキストを再利用すると、セクション 10.12.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の認証を行います。認証またはハンドシェイクが失敗した場合、クライアントは呼び出し側アプリケーションに失敗を返さなければなりません(MUST)。再試行構成を使用してはなりません。これを 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 and then abort the connection with an "ech_required" alert before sending any application data to the server.
サーバーが EncryptedExtensions メッセージに "encrypted_client_hello" 拡張子を指定した場合、クライアントはそれが構文的に有効であることを確認しなければならず、そうでない場合は "decode_error" アラートを出して接続を中止しなければなりません。If an earlier TLS version was negotiated, the client MUST NOT enable the False Start optimization [RFC7918] for this handshake.認証とハンドシェイクの両方が正常に完了した場合、クライアントは、アプリケーション データをサーバーに送信する前に、以下で説明する処理を実行し、「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 configuration as securely replaced by the server. It SHOULD retry the handshake with a new transport connection using the retry configurations supplied by the server.
サーバーが「retry_configs」を提供し、値の少なくとも 1 つにクライアントがサポートするバージョンが含まれている場合、クライアントは ECH 構成がサーバーによって安全に置き換えられたとみなすことができます。サーバーが提供する再試行設定を使用して、新しいトランスポート接続でハンドシェイクを再試行する必要があります (SHOULD)。
Because the new ECH configuration replaces the old ECH configuration, clients can implement a new transport connection in any way that is consistent with the previous ECH configuration. For example, clients can reuse the same server IP address when establishing the new transport connection or they can choose to use a different IP address if DNS provided other IP addresses for the previous configuration. However, it is not safe to use IP addresses discovered with a new DNS query, as those may correspond to a different ECH server configuration, for instance associated with a different ECH server with a different public_name.
新しい ECH 構成は古い ECH 構成を置き換えるため、クライアントは以前の ECH 構成と一貫性のある方法で新しいトランスポート接続を実装できます。たとえば、クライアントは、新しいトランスポート接続を確立するときに同じサーバー IP アドレスを再利用できます。また、DNS が以前の構成に別の IP アドレスを提供していた場合は、別の IP アドレスを使用することを選択できます。ただし、新しい DNS クエリで検出された IP アドレスを使用することは安全ではありません。これらの IP アドレスは、異なる ECH サーバー構成に対応する可能性があるため (たとえば、異なる public_name を持つ別の ECH サーバーに関連付けられている場合など)。
The retry configurations are meant to be used for retried connections. Further use of retry configurations could yield a tracking vector. In settings where the client will otherwise already let the server track the client, e.g., because the client will send cookies to the server in parallel connections, using the retry configurations for these parallel connections does not introduce a new tracking vector.
再試行構成は、再試行される接続に使用することを目的としています。再試行構成をさらに使用すると、追跡ベクトルが生成される可能性があります。たとえば、クライアントが並列接続でサーバーに Cookie を送信するなど、クライアントがすでにサーバーにクライアントを追跡させる設定では、これらの並列接続の再試行構成を使用しても、新しい追跡ベクトルは導入されません。
If none of the values provided in "retry_configs" contains a supported version, the server did not supply an "encrypted_client_hello" extension in its EncryptedExtensions message, 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" で指定された値にサポートされているバージョンが含まれていない場合、サーバーが EncryptedExtensions メッセージで "encrypted_client_hello" 拡張機能を提供しなかった場合、または以前の TLS バージョンがネゴシエートされた場合、クライアントは ECH がサーバーによって安全に無効になっていると見なすことができ、新しいトランスポート接続と無効な ECH でハンドシェイクを再試行する必要があります (SHOULD)。
Clients SHOULD NOT accept "retry_config" in response to a connection initiated in response to a "retry_config". Sending a "retry_config" in this situation is a signal that the server is misconfigured, e.g., the server might have multiple inconsistent configurations so that the client reached a node with configuration A in the first connection and a node with configuration B in the second. Note that this guidance does not apply to the cases in the previous paragraph where the server has securely disabled ECH.
クライアントは、「retry_config」に応答して開始された接続に応答して「retry_config」を受け入れてはなりません (SHOULD NOT)。この状況で「retry_config」を送信することは、サーバーの構成が間違っていることを示す信号です。たとえば、サーバーに一貫性のない複数の構成があり、クライアントが最初の接続で構成 A のノードに到達し、2 番目の接続で構成 B のノードに到達した可能性があります。このガイダンスは、サーバーが ECH を安全に無効にしている前の段落のケースには適用されないことに注意してください。
If a client does not retry, it MUST report an error to the calling application.
クライアントが再試行しない場合は、呼び出し側アプリケーションにエラーを報告しなければなりません (MUST)。
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.
* サーバーがクライアント証明書を要求した場合、クライアントはクライアント証明書がないことを示す空の証明書メッセージで応答しなければなりません (MUST)。
In verifying the client-facing server certificate, the client MUST interpret the public name as a DNS-based reference identity [RFC9525]. Clients that incorporate DNS names and IP addresses into the same syntax (e.g. Section 7.4 of [RFC3986] and [WHATWG-IPV4]) MUST reject names that would be interpreted as IPv4 addresses. Clients that enforce this by checking ECHConfig.contents.public_name do not need to repeat the check when processing ECH rejection.
クライアント側のサーバー証明書を検証する際、クライアントはパブリック名を DNS ベースの参照 ID [RFC9525] として解釈しなければなりません (MUST)。DNS 名と IP アドレスを同じ構文に組み込むクライアント (例: [RFC3986] および [WHATWG-IPV4] のセクション 7.4) は、IPv4 アドレスとして解釈される名前を拒否しなければなりません (MUST)。ECHConfig.contents.public_name をチェックすることでこれを強制するクライアントは、ECH 拒否を処理するときにチェックを繰り返す必要はありません。
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 実装は、そのような接続が成功したことをアプリケーションに報告してはなりません (MUST NOT)。さらに、サーバーによって提示されたすべてのセッション チケットとセッション ID を無視しなければなりません (MUST)。これらの接続は、セクション 6.1.6 で説明されているように、再試行をトリガーするためにのみ使用されます。これは、たとえば、失敗した接続を専用のエラー コードで報告することによって実装できます。
Prior to attempting a connection, a client SHOULD validate the ECHConfig.contents.public_name. Clients SHOULD ignore any ECHConfig structure with a public_name that is not a valid host name in preferred name syntax (see Section 2 of [DNS-TERMS]). That is, to be valid, the public_name needs to be a dot-separated sequence of LDH labels, as defined in Section 2.3.1 of [RFC5890], where:
接続を試みる前に、クライアントは ECHConfig.contents.public_name を検証する必要があります (SHOULD)。クライアントは、優先名の構文で有効なホスト名ではない public_name を持つ ECHConfig 構造を無視すべきです ([DNS-TERMS] のセクション 2 を参照)。つまり、有効であるためには、[RFC5890] のセクション 2.3.1 で定義されているように、public_name がドットで区切られた LDH ラベルのシーケンスである必要があります。
* the sequence does not begin or end with an ASCII dot, and
* シーケンスが ASCII ドットで始まったり終わったりしていない、および
* all labels are at most 63 octets.
* すべてのラベルは最大 63 オクテットです。
Clients additionally SHOULD ignore the structure if the final LDH label either consists of all ASCII digits (i.e., '0' through '9') or is "0x" or "0X" followed by some, possibly empty, sequence of ASCII hexadecimal digits (i.e., '0' through '9', 'a' through 'f', and 'A' through 'F'). This avoids public_name values that may be interpreted as IPv4 literals.
さらに、クライアントは、最終的な LDH ラベルがすべての ASCII 数字 (つまり、「0」から「9」) で構成されているか、「0x」または「0X」の後に空の可能性がある一連の ASCII 16 進数字 (つまり、「0」から「9」、「a」から「f」、および「A」から「F」) が続く場合、その構造を無視すべきです(SHOULD)。これにより、IPv4 リテラルとして解釈される可能性のある public_name 値が回避されます。
Clients MAY use information learned from a rejected ECH for future connections to avoid repeatedly connecting to the same server and being forced to retry. However, they MUST handle ECH rejection for those connections as if it were a fresh connection, rather than enforcing the single retry limit from Section 6.1.6. The reason for this requirement is that if the server sends a "retry_config" and then immediately rejects the resulting connection, it is most likely misconfigured. However, if the server sends a "retry_config" and then the client tries to use that to connect some time later, it is possible that the server has changed its configuration again and is now trying to recover.
クライアントは、同じサーバーに繰り返し接続して再試行を強制されることを避けるために、拒否された ECH から学んだ情報を将来の接続に使用してもよい(MAY)。ただし、セクション 6.1.6 の 1 回の再試行制限を強制するのではなく、あたかも新しい接続であるかのように、それらの接続に対する ECH 拒否を処理しなければなりません (MUST)。この要件が必要な理由は、サーバーが「retry_config」を送信した後、結果として得られた接続をすぐに拒否する場合、接続が正しく構成されていない可能性が高いためです。ただし、サーバーが「retry_config」を送信し、しばらくしてクライアントがそれを使用して接続しようとした場合、サーバーが構成を再度変更し、回復しようとしている可能性があります。
Any persisted information MUST be associated with the ECHConfig source used to bootstrap the connection, such as a DNS SVCB ServiceMode record [RFC9848]. Clients MUST limit any sharing of persisted ECH-related state to connections that use the same ECHConfig source. Otherwise, it might become possible for the client to have the wrong public name for the server, making recovery impossible.
永続化された情報は、DNS SVCB ServiceMode レコード [RFC9848] など、接続のブートストラップに使用される ECHConfig ソースに関連付けられなければなりません (MUST)。クライアントは、永続的な ECH 関連状態の共有を、同じ ECHConfig ソースを使用する接続に制限しなければなりません (MUST)。そうしないと、クライアントがサーバーに対して間違ったパブリック名を持ち、回復が不可能になる可能性があります。
ECHConfigs learned from ECH rejection can be used as a tracking vector. Clients SHOULD impose the same lifetime and scope restrictions that they apply to other server-based tracking vectors such as PSKs.
ECH 拒否から学習した ECHConfig は、追跡ベクトルとして使用できます。クライアントは、PSK などの他のサーバーベースの追跡ベクトルに適用するのと同じ有効期間と範囲の制限を課すべきです (SHOULD)。
In general, the safest way for clients to minimize ECH retries is to comply with any freshness rules (e.g., DNS TTLs) imposed by the ECH configuration.
一般に、クライアントが ECH の再試行を最小限に抑える最も安全な方法は、ECH 設定によって課される鮮度ルール (DNS TTL など) に準拠することです。
The GREASE ECH mechanism allows a connection between an ECH-capable client and a non-ECH server to appear to use ECH, thus reducing the extent to which ECH connections stick out (see Section 10.10.4).
GREASE ECH メカニズムを使用すると、ECH 対応クライアントと非 ECH サーバー間の接続が ECH を使用しているように見えるため、ECH 接続のはみ出しの程度が軽減されます (セクション 10.10.4 を参照)。
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 で GREASE [RFC8701] "encrypted_client_hello" 拡張子を送信する必要があります (SHOULD)。
* Set the config_id field to a random byte.
* config_id フィールドをランダムなバイトに設定します。
* Set the cipher_suite field to a supported HpkeSymmetricCipherSuite. The selection SHOULD vary, so that all plausible configurations are exercised, but MAY be held constant for successive connections to the same server in the same session. Note: A "plausible" configuration is one that an observer might expect to see. A client that fully supports ECH will have a set of supported HPKE cipher suites to select from. A client that only supports GREASE ECH has no such list, so it should select from a set of values that are in common usage.
* cipher_suite フィールドをサポートされている HpkeSymmetricCipherSuite に設定します。選択は、すべての妥当な設定が実行されるように変化する必要があります (SHOULD) が、同じセッション内の同じサーバーへの連続した接続では一定に保たれてもよい (MAY)。注: 「もっともらしい」構成とは、観察者が期待する構成のことです。ECH を完全にサポートするクライアントには、サポートされている HPKE 暗号スイートのセットから選択できます。GREASE ECH のみをサポートするクライアントにはそのようなリストがないため、一般的に使用される値のセットから選択する必要があります。
* 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 を提供するときにクライアントが計算する EncodedClientHelloInner のサイズです。
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 から「encrypted_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 または EncryptedExtensions のいずれかで "encrypted_client_hello" 拡張子を送信する場合、クライアントは拡張子を構文的にチェックし、無効な場合は "decode_error" アラートで接続を中止しなければなりません (MUST)。それ以外の場合は拡張子は無視されます。「retry_configs」値を EncryptedExtensions に保存してはなりません。
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.
GREASE 拡張機能の提供は、セクション 6.1 の要件の目的上、暗号化された ClientHello の提供とはみなされません。特に、クライアントは、ECH なしで確立されたセッションの再開を提案してもよい(MAY)。
Section 11.3 describes a set of Reserved extensions which will never be registered. These can be used by servers to "grease" the contents of the ECH configuration, as inspired by [RFC8701]. This helps ensure clients process ECH extensions correctly. When constructing ECH configurations, servers SHOULD randomly select from reserved values with the high-order bit clear. Correctly implemented clients will ignore those extensions.
セクション 11.3 では、登録されることのない一連の予約済み拡張機能について説明します。これらは、[RFC8701] に触発されているように、ECH 設定の内容を「グリース」するためにサーバーで使用できます。これにより、クライアントが ECH 拡張機能を正しく処理できるようになります。ECH 構成を構築するとき、サーバーは上位ビットがクリアされた予約値からランダムに選択する必要があります (SHOULD)。正しく実装されたクライアントは、これらの拡張機能を無視します。
The reserved values with the high-order bit set are mandatory, as defined in Section 4.2. Servers SHOULD randomly select from these values and include them in extraneous ECH configurations. Correctly implemented clients will ignore these configurations because they do not recognize the mandatory extension. Servers SHOULD ensure that any client using these configurations encounters a warning or error message. This can be accomplished in several ways, including:
セクション 4.2 で定義されているように、上位ビットが設定された予約値は必須です。サーバーはこれらの値からランダムに選択し、無関係な ECH 設定に含めるべきです (SHOULD)。正しく実装されたクライアントは、必須の拡張機能を認識しないため、これらの設定を無視します。サーバーは、これらの構成を使用しているクライアントに警告またはエラー メッセージが表示されることを保証する必要があります。これは、次のようないくつかの方法で実現できます。
* By giving the extraneous configurations distinctive config IDs or public names, and rejecting the TLS connection or inserting an application-level warning message when these are observed.
* 無関係な構成に固有の構成 ID またはパブリック名を指定し、TLS 接続を拒否するか、これらが検出された場合にアプリケーション レベルの警告メッセージを挿入します。
* By giving the extraneous configurations an invalid public key and a public name not associated with the server so that the initial ClientHelloOuter will not be decryptable and the server cannot perform the recovery flow described in Section 6.1.6.
* 無関係な構成にサーバーに関連付けられていない無効な公開キーとパブリック名を与えることで、最初の ClientHelloOuter が復号化できなくなり、サーバーはセクション 6.1.6 で説明されている回復フローを実行できなくなります。
As described in Section 3.1, servers can play two roles, either as the client-facing server or as the backend server. Depending on the server role, the ECHClientHello will be different:
セクション 3.1 で説明したように、サーバーはクライアント側サーバーまたはバックエンド サーバーとして 2 つの役割を果たすことができます。サーバーの役割に応じて、ECHClientHello は異なります。
* A client-facing server expects an ECHClientHello.type of outer, and proceeds as described in Section 7.1 to extract a ClientHelloInner, if available.
* クライアント側サーバーは、outer の ECHClientHello.type を予期し、セクション 7.1 で説明されているように、利用可能な場合は ClientHelloInner を抽出します。
* A backend server expects an ECHClientHello.type of inner, and proceeds as described in Section 7.2.
* バックエンドサーバーは inner の ECHClientHello.type を予期し、セクション 7.2 で説明されているように処理を進めます。
If ECHClientHello.type is not a valid ECHClientHelloType, then the server MUST abort with an "illegal_parameter" alert.
ECHClientHello.type が有効な ECHClientHelloType でない場合、サーバーは「illegal_parameter」アラートを出して中止しなければなりません。
In split mode, a client-facing server which receives a ClientHello with ECHClientHello.type of inner MUST abort with an "illegal_parameter" alert. Similarly, in split mode, a backend server which receives a ClientHello with ECHClientHello.type of outer MUST abort with an "illegal_parameter" alert.
分割モードでは、内部の ECHClientHello.type を持つ ClientHello を受信したクライアント側サーバーは、「illegal_parameter」アラートで中止しなければなりません (MUST)。同様に、分割モードでは、外側の ECHClientHello.type を持つ ClientHello を受信したバックエンド サーバーは、「illegal_parameter」アラートで中止しなければなりません (MUST)。
In shared mode, a server plays both roles, first decrypting the ClientHelloOuter and then using the contents of the ClientHelloInner. A shared mode server which receives a ClientHello with ECHClientHello.type of inner MUST abort with an "illegal_parameter" alert, because such a ClientHello should never be received directly from the network.
共有モードでは、サーバーは両方の役割を果たし、最初に ClientHelloOuter を復号化し、次に ClientHelloInner のコンテンツを使用します。内部の ECHClientHello.type を持つ ClientHello を受信する共有モード サーバーは、「illegal_parameter」アラートで中止しなければなりません (MUST)。そのような ClientHello はネットワークから直接受信されるべきではないためです。
If the "encrypted_client_hello" is not present, then the server completes the handshake normally, as described in [RFC8446].
「encrypted_client_hello」が存在しない場合、[RFC8446] に記載されているように、サーバーはハンドシェイクを正常に完了します。
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 で「encrypted_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 が追跡ベクトルとして使用される可能性があるため、ECCHlientHello.config_id がランダム化される場合があります。このような場合、ECHClientHello を既知の ECHConfig と照合するために 2 番目の方法を使用する必要があります (SHOULD)。セクション10.4を参照してください。アプリケーション プロファイルで指定されていない限り、または外部で構成されている場合を除き、実装は最初の方法を使用しなければなりません (MUST)。
The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension as follows.
次に、サーバーは候補となる ECHConfig 値を反復処理し、次のように「encrypted_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.
サーバーは、ECHConfig が ECHClientHello.cipher_suite で示された暗号スイートをサポートしていること、およびクライアントによって示された ECH のバージョンが ECHConfig.version と一致することを検証します。そうでない場合、サーバーは次の候補 ECHConfig に進みます。
Next, the server decrypts ECHClientHello.payload, using the private key skR corresponding to ECHConfig, as follows:
次に、サーバーは次のように ECHConfig に対応する秘密キー skR を使用して 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 の info パラメーターは、連結「tls ech」、ゼロ バイト、およびシリアル化された ECHConfig です。復号化が失敗した場合、サーバーは次の候補 ECHConfig に進みます。それ以外の場合、サーバーはセクション 5.1 で説明されているように、EncodedClientHelloInner から ClientHelloInner を再構築します。その後、候補 ECHConfig 値の反復処理を停止します。
Once the server has chosen the correct ECHConfig, it MAY verify that the value in the ClientHelloOuter "server_name" extension matches the value of ECHConfig.contents.public_name and abort with an "illegal_parameter" alert if these do not match. This optional check allows the server to limit ECH connections to only use the public SNI values advertised in its ECHConfigs. The server MUST be careful not to unnecessarily reject connections if the same ECHConfig id or keypair is used in multiple ECHConfigs with distinct public names.
サーバーが正しい ECHConfig を選択すると、ClientHelloOuter の "server_name" 拡張子の値が ECHConfig.contents.public_name の値と一致することを検証し、一致しない場合は "illegal_parameter" アラートを出して中止してもよい(MAY)。このオプションのチェックにより、サーバーは ECHConfig でアドバタイズされたパブリック SNI 値のみを使用するように ECH 接続を制限できます。サーバーは、異なるパブリック名を持つ複数の ECHConfig で同じ ECHConfig ID またはキーペアが使用されている場合、不必要に接続を拒否しないように注意しなければなりません (MUST)。
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 を決定すると、クライアント側サーバーは、メッセージに inner 型の整形式の「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.
これらのチェックが成功すると、クライアント側サーバーは ClientHelloInner を適切なバックエンド サーバーに転送し、セクション 7.2 と同様に続行します。バックエンドサーバーが HelloRetryRequest で応答した場合、クライアント側サーバーはそれを転送し、セクション 7.1.1 の手順を使用してクライアントの 2 番目の ClientHelloOuter を復号化し、その結果として得られる 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:
それ以外の場合、候補となるすべての ECHConfig 値が拡張子の復号化に失敗した場合、クライアント側サーバーは拡張子を無視し、次の変更を加えた ClientHelloOuter を使用して接続を続行しなければなりません (MUST)。
* If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see Section 10.10.4 for details.
* HelloRetryRequest を送信する場合、サーバーはランダムな 8 バイトのペイロードを持つ「encrypted_client_hello」拡張子を含めてもよい(MAY)。詳細については、セクション10.10.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.
* サーバーが ECHConfig で構成されている場合は、最新のキーを持つ 1 つ以上の ECHConfig 構造に設定された「retry_configs」フィールドを持つ EncryptedExtensions に「encrypted_client_hello」拡張機能を含める必要があります。サーバーは、異なるバージョンの複数の ECHConfig 値を提供してもよい(MAY)。これにより、サーバーは複数のバージョンを同時にサポートできるようになります。
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.1). Instead, servers can measure occurrences of the "ech_required" alert to detect this case.
復号化の失敗は GREASE ECH 拡張 (セクション 6.2 を参照) を示している可能性があるので、サーバーは接続を続行し、ECH が必要な場合はクライアントの中止に依存する必要があることに注意してください。特に、認識されない値だけでは、ECH アドバタイズメントの設定が間違っていることを示しているわけではありません (セクション 8.1.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 that 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.cipher_suite と ECHClientHello.config_id が変更されていないこと、および ECHClientHello.enc が空であることをチェックします。そうでない場合は、「illegal_parameter」アラートを発行してハンドシェイクを中止しなければなりません。
Finally, it decrypts the new ECHClientHello.payload as a second message with the previous HPKE context:
最後に、新しい ECHClientHello.payload を前の HPKE コンテキストを使用した 2 番目のメッセージとして復号します。
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」アラートを出してハンドシェイクを中止しなければなりません(MUST)。それ以外の場合は、セクション 5.1 で説明されているように、参照される拡張機能に 2 番目の ClientHelloOuter を使用して、新しい EncodedClientHelloInner から 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 に「encrypted_client_hello」拡張子が含まれていなかった場合、クライアント側サーバーは通常どおり接続を続行します。サーバーは、2 番目の ClientHello の ECHClientHello.payload 値が存在する場合、それを復号化しません。さらに、サーバーが ECHConfig で構成されている場合は、セクション 7.1 で説明されているように、最新のキーを持つ 1 つ以上の ECHConfig 構造体に設定された「retry_configs」フィールドを持つ EncryptedExtensions に「encrypted_client_hello」拡張子を含めなければなりません (MUST)。
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.
バックエンド サーバーが HelloRetryRequest を送信する場合、最初の ClientHello を転送するクライアント側サーバーには、独自の「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 で inner 型の "encrypted_client_hello" 拡張を受信すると、バックエンド サーバーが TLS 1.3 以降をネゴシエートする場合、ここで説明されているように ServerHello を計算することによって、クライアントに対する ECH の受け入れを確認しなければなりません (MUST)。
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 で説明されているように、変更された ServerHello を含む ClientHelloInner のトランスクリプト ハッシュを計算します。出力をtranscript_ech_confとします。最後に、バックエンド サーバーは ServerHello.random の最後の 8 バイトを次の文字列で上書きします。
accept_confirmation = HKDF-Expand-Label(
HKDF-Extract(0, ClientHelloInner.random),
"ech accept confirmation",
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. In DTLS, the modified version of HKDF-Expand-Label defined in [RFC9147], Section 5.9 is used instead.
ここで、HKDF-Expand-Label は [RFC8446] のセクション 7.1 で定義されており、「0」はゼロに設定された Hash.length バイトの文字列を示し、Hash はトランスクリプト ハッシュの計算に使用されるハッシュ関数です。DTLS では、[RFC9147] セクション 5.9 で定義されている HKDF-Expand-Label の修正バージョンが代わりに使用されます。
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 以下をネゴシエートした場合、この操作を実行してはなりません (MUST NOT)。そうすることで、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.
バックエンド サーバーが 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 ゼロ バイトのペイロードを持つ "encrypted_client_hello" 拡張機能も含まれています。次に、変更された HelloRetryRequest までの最初の ClientHelloInner (ClientHelloInner1 と示される) のトランスクリプト ハッシュを計算します。出力を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)
In the subsequent ServerHello message, the backend server sends the accept_confirmation value as described in Section 7.2.
後続の ServerHello メッセージで、バックエンド サーバーはセクション 7.2 で説明されているように accept_confirmation 値を送信します。
The design of ECH as specified in this document necessarily requires changes to client, client-facing server, and backend server. Coordination between client-facing and backend server requires care, as deployment mistakes can lead to compatibility issues. These are discussed in Section 8.1.
このドキュメントで指定されている ECH の設計では、クライアント、クライアント側サーバー、およびバックエンド サーバーの変更が必ず必要になります。導入ミスが互換性の問題を引き起こす可能性があるため、クライアント側サーバーとバックエンド サーバー間の調整には注意が必要です。これらについてはセクション 8.1 で説明します。
Beyond coordination difficulties, ECH deployments may also create challenges for uses of information that ECH protects. In particular, use cases which depend on this unencrypted information may no longer work as desired. This is elaborated upon in Section 8.2.
ECH の展開では、調整の難しさだけでなく、ECH が保護する情報の使用に関しても課題が生じる可能性があります。特に、この暗号化されていない情報に依存するユースケースは、期待どおりに機能しなくなる可能性があります。これについてはセクション 8.2 で詳しく説明します。
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 キーのセットをアドバタイズする前に理解していることを確認する必要があります (SHOULD)。さらに、サーバーは、以前に公開されたキーの有効期間中、そのキーのサポートを保持すべきです(SHOULD)。
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 TLS server has a certificate 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.
TLS サーバーにパブリック名の証明書がある場合、再試行メカニズムによって不整合が修復されます。サーバーとアドバタイズされたキーが一致しない場合、サーバーは 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 が無効になっていない限り、クライアントは暗号化されていない ClientHello の使用にフォールバックしてはなりません。これにより、ネットワーク攻撃者が SNI を含むこの ClientHello の内容を開示することが可能になるからです。It MAY attempt to use another server from the DNS results, if one is provided.
In order to ensure that the retry mechanism works successfully, servers SHOULD ensure that every endpoint which might receive a TLS connection is provisioned with an appropriate certificate for the public name. This is especially important during periods of server reconfiguration when different endpoints might have different configurations.
再試行メカニズムが正常に機能することを保証するために、サーバーは、TLS 接続を受信する可能性のあるすべてのエンドポイントにパブリック名に対する適切な証明書がプロビジョニングされていることを確認する必要があります (SHOULD)。これは、異なるエンドポイントの構成が異なる可能性があるサーバーの再構成中に特に重要です。
The requirements in [RFC8446], Section 9.3 which require proxies to act as conforming TLS client and server provide interoperability with TLS-terminating proxies even in cases where the server supports ECH but the proxy does not, as detailed below.
プロキシが準拠する TLS クライアントおよびサーバーとして機能することを要求する [RFC8446] セクション 9.3 の要件は、以下で詳細に説明するように、サーバーが ECH をサポートしているがプロキシがサポートしていない場合でも、TLS 終端プロキシとの相互運用性を提供します。
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 ClientHelloOuter server_name, which SHOULD match the public name (see Section 6.1) without echoing the "encrypted_client_hello" extension.
プロキシは不明なパラメータを無視し、理解できるパラメータのみを含む独自の ClientHello を生成する必要があります。したがって、クライアントに証明書を提示するとき、または ClientHello をサーバーに送信するとき、プロキシは、「encrypted_client_hello」拡張子をエコーすることなく、パブリック名 (セクション 6.1 を参照) と一致する ClientHelloOuter サーバー名に接続しているかのように動作します。
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 を無効にする信号を偽造できません。
Some use cases which depend on information ECH encrypts may break with the deployment of ECH. The extent of breakage depends on a number of external factors, including, for example, whether ECH can be disabled, whether or not the party disabling ECH is trusted to do so, and whether or not client implementations will fall back to TLS without ECH in the event of disablement.
ECH が暗号化する情報に依存する一部のユースケースは、ECH の導入により機能しなくなる可能性があります。破損の程度は、ECH を無効にできるかどうか、ECH を無効にする当事者が信頼できるかどうか、無効になった場合にクライアント実装が ECH なしの TLS にフォールバックするかどうかなど、多くの外部要因によって異なります。
Depending on implementation details and deployment settings, use cases which depend on plaintext TLS information may require fundamentally different approaches to continue working. For example, in managed enterprise settings, one approach may be to disable ECH entirely via group policy and for client implementations to honor this action. Server deployments which depend on SNI -- e.g., for load balancing -- may no longer function properly without updates; the nature of those updates is out of scope of this specification.
実装の詳細と展開設定に応じて、平文の TLS 情報に依存するユースケースでは、動作を継続するために根本的に異なるアプローチが必要になる場合があります。たとえば、管理された企業設定では、グループ ポリシーを介して ECH を完全に無効にし、クライアント実装がこのアクションを受け入れることが 1 つのアプローチになる可能性があります。SNI に依存するサーバー展開 (負荷分散など) は、アップデートがないと適切に機能しなくなる可能性があります。これらの更新の性質は、この仕様の範囲外です。
In the context of Section 6.1.6, another approach may be to intercept and decrypt client TLS connections. The feasibility of alternative solutions is specific to individual deployments.
セクション 6.1.6 のコンテキストでは、別のアプローチとして、クライアントの TLS 接続を傍受して復号化することが考えられます。代替ソリューションの実現可能性は、個々の展開によって異なります。
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 を参照)
This section contains security considerations for ECH.
このセクションには、ECH のセキュリティに関する考慮事項が含まれています。
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 [RFC3552] for TLS 1.3 [RFC8446].
ECH は、パッシブとアクティブの 2 種類の攻撃者を考慮します。受動的な攻撃者はネットワークからパケットを読み取ることはできますが、サーバーの調査や DNS のクエリなどの能動的な動作を実行することはできません。平文パケットの内容に基づいてフィルタリングするミドルボックスは、受動的攻撃者の一例です。対照的に、積極的な攻撃者は、既存の接続の妨害、サーバーの調査、DNS のクエリなど、悪意のある目的でネットワークにパケットを書き込むこともできます。つまり、アクティブな攻撃者は、TLS 1.3 [RFC8446] の従来の脅威モデル [RFC3552] に相当します。
Passive and active attackers can exist anywhere in the network, including between the client and client-facing server, as well as between the client-facing and backend servers when running ECH in split mode. However, for split mode in particular, ECH makes two additional assumptions:
受動的攻撃者と能動的攻撃者は、クライアントとクライアント側サーバーの間、ECH を分割モードで実行している場合のクライアント側サーバーとバックエンド サーバーの間など、ネットワーク内のどこにでも存在する可能性があります。ただし、特に分割モードの場合、ECH は 2 つの追加の前提を設けます。
1. The channel between each client-facing and each backend server is authenticated such that the backend server only accepts messages from trusted client-facing servers. The exact mechanism for establishing this authenticated channel is out of scope for this document.
1. 各クライアント側サーバーと各バックエンド サーバー間のチャネルは、バックエンド サーバーが信頼できるクライアント側サーバーからのメッセージのみを受け入れるように認証されます。この認証されたチャネルを確立するための正確なメカニズムは、このドキュメントの範囲外です。
2. The attacker cannot correlate messages between a client and client-facing server with messages between client-facing and backend server. Such correlation could allow an attacker to link information unique to a backend server, such as their server name or IP address, with a client's encrypted ClientHelloInner. Correlation could occur through timing analysis of messages across the client-facing server, or via examining the contents of messages sent between client-facing and backend servers. The exact mechanism for preventing this sort of correlation is out of scope for this document.
2. 攻撃者は、クライアントとクライアント側サーバー間のメッセージを、クライアント側サーバーとバックエンド サーバー間のメッセージと関連付けることはできません。このような関連付けにより、攻撃者は、サーバー名や IP アドレスなどのバックエンド サーバーに固有の情報を、クライアントの暗号化された ClientHelloInner にリンクできる可能性があります。相関関係は、クライアント側サーバー全体にわたるメッセージのタイミング分析を通じて、またはクライアント側サーバーとバックエンド サーバー間で送信されるメッセージの内容を検査することによって発生する可能性があります。この種の相関関係を防止するための正確なメカニズムについては、このドキュメントの範囲外です。
Given this threat model, 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 server name within an anonymity set is indistinguishable from a connection to any other server name within the anonymity set. (The anonymity set is defined in Section 1.)
2. 握手のプライバシー。匿名性セット内のサーバー名への TLS 接続の確立は、匿名性セット内の他のサーバー名への接続と区別できません。(匿名性セットはセクション 1 で定義されています。)
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 server name, 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 server names as possible. An attacker can distinguish two server names that have different ECHConfig values based on the ECHClientHello.config_id value.
ハンドシェイクのプライバシーに関しては、クライアント側のサーバー構成によって匿名性セットのサイズが決まります。たとえば、クライアント側サーバーがサーバー名ごとに個別の ECHConfig 値を使用する場合、各匿名性セットのサイズは k = 1 になります。クライアント側サーバーは、可能な限り匿名性セットのサイズを最大化するような方法で ECH を展開する必要があります (SHOULD)。これは、クライアント側サーバーができるだけ多くのサーバー名に対して同じ ECHConfig を使用する必要があることを意味します。攻撃者は、ECHClientHello.config_id 値に基づいて、異なる ECHConfig 値を持つ 2 つのサーバー名を区別できます。
This also means public information in a TLS handshake should be consistent across server names. For example, if a client-facing server services many backend origin server names, only one of which supports some cipher suite, it may be possible to identify that server name based on the contents of the unencrypted handshake message. Similarly, if a backend origin reuses KeyShare values, then that provides a unique identifier for that server.
これは、TLS ハンドシェイクの公開情報がサーバー名全体で一貫している必要があることも意味します。たとえば、クライアント側サーバーが多数のバックエンド オリジン サーバー名にサービスを提供し、そのうちの 1 つだけが何らかの暗号スイートをサポートしている場合、暗号化されていないハンドシェイク メッセージの内容に基づいてそのサーバー名を識別できる可能性があります。同様に、バックエンドオリジンが KeyShare 値を再利用する場合、そのサーバーに一意の識別子が提供されます。
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.10.4 for details.
これらの主要なセキュリティとプライバシーの目標を超えて、ECH は、ECH が使用されているという事実をある程度隠すことも目的としています。具体的には、セクション 6.2 で説明されている GREASE ECH 拡張機能は、TLS ハンドシェイクのセキュリティ プロパティをまったく変更しません。その目標は、[RFC8744] の「はみ出さない」要件に対処する手段として、実際の ECH プロトコル (セクション 6.1) に「カバー」を提供することです。詳細については、セクション10.10.4を参照してください。
ECH supports delivery of configurations through the DNS using SVCB or HTTPS records without requiring any verifiable authenticity or provenance information [RFC9848]. 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 configurations (so that the client encrypts data to them) or strip the ECH configurations 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 for each DNS name that was looked up. Thus, using DNS records without additional authentication does not make the situation significantly worse.
ECH は、検証可能な信頼性や出所情報を必要とせずに、SVCB または HTTPS レコードを使用した DNS を介した構成の配信をサポートします [RFC9848]。これは、クライアント アクセス ネットワークで一般的なシナリオである、DNS 応答を挿入したり、DNS キャッシュを毒したりできる攻撃者は、クライアントに偽の ECH 構成を提供したり (クライアントがデータを暗号化できるように)、応答から ECH 構成を削除したりできることを意味します。ただし、DNS を制御する攻撃者の前では、攻撃者が IP アドレスを置き換えてクライアント接続をブロックしたり、検索された各 DNS 名を一意の IP アドレスに置き換えたりする可能性があるため、暗号化スキームは機能しません。したがって、追加の認証なしで DNS レコードを使用しても、状況が大幅に悪化することはありません。
Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but encrypted DNS transport is also a defense 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.
DNSSEC (クライアントが検証してハード失敗した場合) がこの形式の攻撃に対する防御であることは明らかですが、暗号化された DNS トランスポートは、ローカル ネットワーク上の攻撃者による DNS 攻撃に対する防御でもあります。これは、ClientHello および SNI 暗号化が必要な一般的なケースです。さらに、冒頭で述べたように、SNI 暗号化は、転送中の 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 (this may not be possible if clients use the operating system resolver rather than doing their own resolution).
このタイプの攻撃のコストは、ターゲットとなるクライアントの数に応じて直線的に増加します。さらに、DNS キャッシュ動作により、たとえば、高い TTL の HTTPS RR 経由で配信されるクライアントごとの ECHConfig 構造を使用するなど、個々のユーザーを長期間にわたってターゲットにすることが困難になります。クライアントは、ネットワークの変更時に DNS または ECHConfig の状態をフラッシュすることで、この問題を軽減できます (クライアントが独自の解決を行うのではなくオペレーティング システムのリゾルバーを使用する場合、これは不可能な場合があります)。
ECHConfig rotation rate is also an issue for non-malicious servers, which may want to rotate keys frequently to limit exposure if the key is compromised. Rotating too frequently limits the client anonymity set. In practice, servers which service many server names and thus have high loads are the best candidates to be client-facing servers and so anonymity sets will typically involve many connections even with fairly fast rotation intervals.
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」拡張機能内のクライアント側サーバーに関する情報を明らかにしたくないシナリオで役立つ場合があります。このような設定では、クライアントはランダムに生成された config_id を ECHClientHello で送信します。これらの設定のサーバーは、config_id 値を使用してクライアントが選択した ECH キーを識別できないため、試行的な復号化を実行する必要があります。その結果、構成識別子を無視すると、DoS 攻撃が悪化する可能性があります。具体的には、敵対者は、無駄な復号化を強制するために、悪意のある ClientHello メッセージ、つまり既知の ECH キーで復号化しないメッセージを送信する可能性があります。たとえば、この機能をサポートするサーバーは、そのような攻撃によって引き起こされる潜在的な損害を制限するために、何らかの形式のレート制限メカニズムを実装する必要があります。
Unless specified by the application using (D)TLS or externally configured, client implementations MUST NOT use this mode.
(D)TLS を使用してアプリケーションによって指定されている場合、または外部で構成されている場合を除き、クライアント実装はこのモードを使用してはなりません (MUST NOT)。
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 に含める情報はすべて、パッシブ オブザーバーに表示されます。クライアントは、実際のサーバー名など、機密の ClientHelloInner プロパティを明らかにする値を ClientHelloOuter で送信してはなりません (SHOULD NOT)。ClientHelloOuter のパブリック名に関連付けられた値を送信してもよい(MAY)。
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 内の真のサーバー名に関連付けられた値を送信してはなりません (SHOULD NOT)。そのような値を ClientHelloInner で送信してもよい(MAY)。
A client may also use different preferences in different contexts. For example, it may send 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 でコンテキスト固有の値を送信してはなりません (SHOULD NOT)。
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 that 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 に含めてもよい(MAY)。それらが対応する ClientHelloInner と一致する場合、セクション 5.1 で説明されているように圧縮されてもよい(MAY)。ただし、ペイロードの長さによって、どの拡張子が圧縮されているかに関する情報が明らかになるため、対応する外側の拡張子とたまにしか一致しない内側の拡張子は圧縮すべきではないことに注意してください。
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.10.4.
クライアントは、値の選択と値自体が機密でない場合に限り、受動的なオブザーバーに異常な動作を通知することを避けるために、ClientHelloOuter に追加の拡張機能を含めてもよい (MAY)。セクション10.10.4を参照してください。
Values which depend on the contents of ClientHelloInner, such as the true server name, can influence how client-facing servers process this message. In particular, timing side channels can reveal information about the contents of ClientHelloInner. Implementations should take such side channels into consideration when reasoning about the privacy properties that ECH provides.
実際のサーバー名など、ClientHelloInner の内容に依存する値は、クライアント側サーバーがこのメッセージを処理する方法に影響を与える可能性があります。特に、タイミング サイド チャネルは、ClientHelloInner のコンテンツに関する情報を明らかにする可能性があります。実装では、ECH が提供するプライバシー プロパティについて推論するときに、このようなサイド チャネルを考慮する必要があります。
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 Online Certificate Status Protocol (OCSP) or Certificate Revocation List (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 CertificateType を使用する場合、証明書メッセージからサーバーの ID を検証すると、追加のネットワーク トラフィックが発生し、サーバーの ID が明らかになる可能性があります。このトラフィックの例には、オンライン証明書ステータス プロトコル (OCSP) トラフィックや証明書失効リスト (CRL) トラフィックなどの失効情報の要求、または authorizationInformationAccess などのリポジトリ情報の要求が含まれる場合があります。検証の一環として、追加の情報ソースに対する実装固有のトラフィックも含まれる場合があります。
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 ステープリングの使用などを通じて、そのような情報を帯域内で配信する必要があり (SHOULD)、クライアントは、証明書の検証中にそのような要求を最小限に抑えるか保護するための措置を講じるべきです (SHOULD)。
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 接続内のサーバー ID を推測するために非 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 の違いにより、サーバーの ID に関する情報が漏洩する可能性があることを意味します。
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 内の情報を公開してはなりません (SHOULD NOT)。これは、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 either by handling key rotation with trial decryption or by 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.
受け入れを通知するために、バックエンド サーバーは ServerHello.random の 8 バイトを ClientHelloInner.random から派生した値で上書きします。(詳細については、セクション 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 以降でのみ ECH 受け入れを通知するため、これらのメカニズムは干渉しません。
[RFC8744] lists several requirements for SNI encryption. In this section, we reiterate 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 は暗号化されているため、攻撃者が別の Client Hello に ECH 値を「カット アンド ペースト」して ClientHelloInner から情報を取得することはできません。
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 of private keys by publishing different DNS records containing ECHConfig values with different public 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 transport connections an attacker can open.
この設計では、サーバーが有効なダイジェストを含む ECHClientHello 拡張子を使用して ClientHello メッセージを復号化する必要があります。したがって、攻撃者がサーバー上で復号化操作を強制する可能性があります。この攻撃は、攻撃者が開くことができる有効なトランスポート接続の数によって制限されます。
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] は、ネットワーク事業者がそのメカニズムを使用する接続とそのメカニズムを使用しない接続を区別しないように SNI 保護メカニズムを設計することを推奨しています。そのために、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, the 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 で説明されている GREASE ECH プロトコルは、ECH の展開可能性を評価する低リスクの方法を提供します。これは、ハンドシェイクのセキュリティ特性を変更せずに、実際の ECH プロトコル (セクション 6.1) を模倣するように設計されています。基礎となる理論は、GREASE ECH がミドルボックスの誤動作を引き起こすことなくデプロイ可能であり、実際の ECH が十分に GREASE ECH に見える場合、ECH も同様にデプロイ可能であるはずである、というものです。したがって、ネットワークの硬直化を緩和する戦略は、ネットワークによる実際の ECH プロトコルの差別的な扱いを妨げるのに十分な広さで GREASE 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 と GREASE ECH を区別しないようにすることは、すべての実装で実現可能であるとは限りません。ほとんどのミドルボックスはそれらを特別に扱いませんが、一部のオペレータは実際の ECH の使用をブロックし、GREASE ECH を許可したい場合があります。この仕様は、ほとんどの展開で簡単に達成できるベースラインのセキュリティ レベルを提供するとともに、可能な場合はより強力なセキュリティを実現するための十分な柔軟性を実装に提供することを目的としています。少なくとも、実際の ECH は、次の機能を備えた受動的敵対者にとって GREASE 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. 攻撃者は接続ごとの状態のみを保持します。特に、接続全体でエンドポイントを追跡しません。
Moreover, real ECH and GREASE ECH are designed so that the following features do not noticeably vary to the attacker, i.e., they are not distinguishers:
さらに、本物の ECH と GREASE ECH は、次の機能が攻撃者にとって顕著に変わらないように設計されています。つまり、これらは区別されません。
1. the code points of extensions negotiated in the clear, and their order;
1. 平文でネゴシエートされた拡張のコード ポイントとその順序。
2. the length of messages; and
2. メッセージの長さ。そして
3. the values of plaintext alert messages.
3. 平文の警告メッセージの値。
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, and even across different client and server implementations. These mitigations are out-of-scope for this specification.
これらは、より高度な実装で対処できますが、一部の緩和策では、クライアントとサーバー間、さらには異なるクライアントとサーバーの実装間での調整が必要になります。これらの緩和策は、この仕様の範囲外です。
This design does not provide forward secrecy for the inner ClientHello 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 regularly.
この設計では、サーバーの ECH キーが静的であるため、内部 ClientHello に前方機密性は提供されません。ただし、暴露の範囲はキーの有効期間によって制限されます。サーバーが鍵を定期的にローテーションすることが推奨されます。
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 allowing the backend origin server to hide behind the client-facing server without the client-facing server decrypting and reencrypting the connection.
この設計により、分割モードで動作するサーバーが接続をバックエンドのオリジン サーバーに直接転送できるようになります。クライアントはバックエンド オリジン サーバーの ID を認証するため、クライアント側サーバーが接続を復号化および再暗号化することなく、バックエンド オリジン サーバーをクライアント側サーバーの背後に隠すことができます。
Conversely, if the DNS records used for configuration are authenticated, e.g., via DNSSEC, spoofing a client-facing server operating in split mode is not possible. See Section 10.2 for more details regarding plaintext DNS.
逆に、構成に使用される DNS レコードが 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 値など、内部の ClientHello に関するプライベート情報を取得することです。
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.
この攻撃は、不正な証明書に対するクライアントの反応を神託として利用します。攻撃者は正規の ClientHello を傍受し、ServerHello、Certificate、CertificateVerify、および Finished メッセージで応答します。この Certificate メッセージには、クエリ対象のドメイン名の「テスト」証明書が含まれています。クライアントが証明書を復号化し、検証に失敗した場合（またはタイミング サイド チャネルによって検証プロセスに関する情報が漏洩した場合）、攻撃者はそのテスト証明書の名前が間違っていたことを知ります。例として、内部 ClientHello 内のクライアントの SNI 値が「example.com」であり、攻撃者が「test.com」の証明書で応答したとします。証明書の署名の検証よりも早く、クライアントが不一致により検証失敗のアラートを生成すると、名前に関する情報が漏洩します。攻撃者は CertificateVerify メッセージを保留することもできることに注意してください。そのシナリオでは、最初に証明書を検証したクライアントが同様に応答し、同じ情報が漏洩することになります。
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: because 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 に関する情報を回復することを目的としています。まず、攻撃者は「encrypted_client_hello」(ech) 拡張子を持つ正規の ClientHello を傍受してサーバーに転送し、これにより正規の HelloRetryRequest が返されます。攻撃者は、再試行をクライアントに転送するのではなく、最初の 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 番目の内部 ClientHello の有効な暗号化を生成できません。
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 のパラメーターと一致する必要がある場合、サーバーがオラクルとして機能する可能性があります。たとえば、内部 ClientHello 内のクライアントの元の SNI 値が「example.com」で、内部 ClientHello 内の攻撃者のハイジャックされた SNI 値が「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 の一部を参照して ClientHelloInner を構築するか、バグのあるサーバーが 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 バインダー チェックは失敗し、アラートが表示されますが、ClientHelloInner が他の名前に対するものである場合には、PSK はサイレントに無視され、続行されます。これにより、暗号化された 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. 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. 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 を参照してください。セクション 5.1 の解凍プロセスでは、OuterExtensions の "encrypted_client_hello" が禁止されています。これにより、ClientHelloOuter の未認証部分が ClientHelloInner に組み込まれないようになります。この仕様の以前の反復では、「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 はOuterExtensions のサイズです。
* 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 拡張機能を複数回コピーできる場合、攻撃者は、ClientHelloOuter に長さ L の大きな拡張機能と、その拡張機能の N 個のコピーを参照する OuterExtensions リストを含めることで、クライアント側サーバーに大きな 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 は、OuterExtensions が順番に参照されること、重複した参照が拒否されることを要求し、クライアント側サーバーがリニア スキャンを使用して解凍を実行することを推奨することによって、この攻撃を軽減します。これらの要件についてはセクション 5.1 で詳しく説明します。
IANA has created the following entries in the existing "TLS ExtensionType Values" registry (defined in [RFC8446]):
IANA は、既存の「TLS ExtensionType Values」レジストリ ([RFC8446] で定義) に次のエントリを作成しました。
1. encrypted_client_hello (0xfe0d), with "TLS 1.3" column values set to "CH, HRR, EE", "DTLS-Only" column set to "N", and "Recommended" column set to "Y".
1. encrypted_client_hello (0xfe0d)。「TLS 1.3」列の値が「CH、HRR、EE」に設定され、「DTLS-Only」列の値が「N」に設定され、「推奨」列の値が「Y」に設定されます。
2. ech_outer_extensions (0xfd00), with the "TLS 1.3" column values set to "CH", "DTLS-Only" column set to "N", "Recommended" column set to "Y", and the "Comment" column set to "Only appears in inner CH."
2. ech_outer_extensions (0xfd00)。「TLS 1.3」列の値が「CH」に設定され、「DTLS-Only」列の値が「N」に設定され、「推奨」列の値が「Y」に設定され、「Comment」列の値が「内部 CH にのみ表示される」に設定されます。
IANA has created an entry, ech_required (121) in the existing "TLS Alerts" registry (defined in [RFC8446]), with the "DTLS-OK" column set to "Y".
IANA は、既存の「TLS Alerts」レジストリ ([RFC8446] で定義) にエントリ ech_required (121) を作成し、「DTLS-OK」列を「Y」に設定しました。
IANA has created a new "TLS ECHConfig Extension" registry in a new "TLS Encrypted Client Hello (ECH) Configuration Extensions" registry group. New registrations will list the following attributes:
IANA は、新しい「TLS Encrypted Client Hello (ECH) Configuration Extensions」レジストリ グループ内に新しい「TLS ECHConfig Extension」レジストリを作成しました。新規登録には次の属性がリストされます。
Value:
値：
The two-byte identifier for the ECHConfigExtension, i.e., the ECHConfigExtensionType
ECHConfigExtension の 2 バイトの識別子、つまり ECHConfigExtensionType
Extension Name:
拡張機能名:
Name of the ECHConfigExtension
ECHConfigExtension の名前
Recommended:
推奨：
A "Y" or "N" value indicating if the TLS Working Group recommends that the extension be supported. This column is assigned a value of "N" unless explicitly requested. Adding a value of "Y" requires Standards Action [RFC8126].
TLS ワーキング グループが拡張機能のサポートを推奨しているかどうかを示す「Y」または「N」の値。明示的に要求されない限り、この列には値「N」が割り当てられます。「Y」の値を追加するには、Standards Action [RFC8126] が必要です。
Reference:
参照：
The specification where the ECHConfigExtension is defined
ECHConfigExtensionが定義されている仕様
Notes:
注:
Any notes associated with the entry
エントリに関連するメモ
New entries in the "TLS ECHConfig Extension" registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6), with the policies described in [RFC9847], Section 16. IANA has added the following note to the "TLS ECHConfig Extension" registry:
「TLS ECHConfig Extension」レジストリの新しいエントリは、[RFC9847] セクション 16 で説明されているポリシーとともに、仕様要求登録ポリシー ([RFC8126] セクション 4.6) の対象となります。 IANA は、「TLS ECHConfig Extension」レジストリに次の注記を追加しました。
Note: The role of the designated expert is described in RFC 9847. The designated expert [RFC8126] ensures that the specification is publicly available. It is sufficient to have an Internet-Draft (that is posted and never published as an RFC) or a document from another standards body, industry consortium, university site, etc. The expert may provide more in-depth reviews, but their approval should not be taken as an endorsement of the extension.
注: 指定された専門家の役割は、RFC 9847 に説明されています。指定された専門家 [RFC8126] は、仕様が確実に公開されるようにします。インターネット ドラフト (投稿され、RFC として公開されることはない) または別の標準化団体、業界コンソーシアム、大学のサイトなどからの文書があれば十分です。専門家はより詳細なレビューを提供する可能性がありますが、専門家の承認は拡張機能の承認とみなされるべきではありません。
This document defines several Reserved values for ECH configuration extensions to be used for "greasing" as described in Section 6.2.2.
この文書は、セクション 6.2.2 で説明されている「グリース」に使用される ECH 構成拡張のいくつかの予約値を定義します。
The initial contents for this registry consists of multiple reserved values with the following attributes, which are repeated for each registration:
このレジストリの初期内容は、次の属性を持つ複数の予約値で構成されており、これらの値は登録ごとに繰り返されます。
Value:
値：
0x0000, 0x1A1A, 0x2A2A, 0x3A3A, 0x4A4A, 0x5A5A, 0x6A6A, 0x7A7A, 0x8A8A, 0x9A9A, 0xAAAA, 0xBABA, 0xCACA, 0xDADA, 0xEAEA, 0xFAFA
0x0000、0x1A1A、0x2A2A、0x3A3A、0x4A4A、0x5A5A、0x6A6A、0x7A7A、0x8A8A、0x9A9A、0xAAAA、0xBABA、0xCACA、0xDADA、0xEAEA、0xFAFA
Extension Name:
拡張機能名:
RESERVED
予約済み
Recommended:
推奨：
Y
Y
Reference:
参照：
RFC 9849
RFC 9849
Notes:
注:
GREASE entries
グリースエントリー
[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/info/rfc9180>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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/info/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/info/rfc7918>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[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/info/rfc9147>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[RFC9847] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 9847, DOI 10.17487/RFC9847, December 2025,
<https://www.rfc-editor.org/info/rfc9847>.
[DNS-TERMS]
Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
[ECH-Analysis]
Bhargavan, K., Cheval, V., and C. Wood, "A Symbolic
Analysis of Privacy for TLS 1.3 with Encrypted Client
Hello", CCS '22: Proceedings of the 2022 ACM SIGSAC
Conference on Computer and Communications Security, pp.
365-379, DOI 10.1145/3548606.3559360, November 2022,
<https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-
ccs22.pdf>.
[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>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[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/info/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/info/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/info/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/info/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/info/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/info/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/info/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/info/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/info/rfc8744>.
[RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over
Dedicated QUIC Connections", RFC 9250,
DOI 10.17487/RFC9250, May 2022,
<https://www.rfc-editor.org/info/rfc9250>.
[RFC9848] Schwartz, B., Bishop, M., and E. Nygren, "Bootstrapping
TLS Encrypted ClientHello with DNS Service Bindings",
RFC 9848, DOI 10.17487/RFC9848, March 2026,
<https://www.rfc-editor.org/info/rfc9848>.
[WHATWG-IPV4]
WHATWG, "URL - IPv4 Parser", WHATWG Living Standard, May
2021, <https://url.spec.whatwg.org/>. Commit snapshot:
<https://url.spec.whatwg.org/commit- snapshots/1b8b8c55eb4
bed9f139c9a439fb1c1bf5566b619/#concept- ipv4-parser>.
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 を参照) を線形時間で処理し、ClientHelloOuter で参照されている各拡張機能が最大 1 回含まれるようにします。
1. Let I be initialized to zero and N be set to the number of extensions in ClientHelloOuter.
1. I をゼロに初期化し、N を ClientHelloOuter 内の拡張機能の数に設定します。
2. For each extension type, E, in OuterExtensions:
2. OuterExtensions の各拡張タイプ E については、次のようになります。
* If E is "encrypted_client_hello", abort the connection with an "illegal_parameter" alert and terminate this procedure.
* E が「encrypted_client_hello」の場合、「illegal_parameter」アラートで接続を中止し、この手順を終了します。
* While I is less than N and the I-th extension of ClientHelloOuter does not have type E, increment I.
* I が N より小さく、ClientHelloOuter の I 番目の拡張子のタイプ E がない場合、I をインクリメントします。
* If I is equal to N, abort the connection with an "illegal_parameter" alert and terminate this procedure.
* I が N に等しい場合、「illegal_parameter」アラートで接続を中止し、この手順を終了します。
* Otherwise, the I-th extension of ClientHelloOuter has type E. Copy it to the EncodedClientHelloInner and increment I.
* それ以外の場合、ClientHelloOuter の I 番目の拡張機能のタイプは E です。それを EncodedClientHelloInner にコピーし、I をインクリメントします。
This document draws extensively from ideas in [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.
この文書は [PROTECTED-SNI] のアイデアを広範囲に活用していますが、ECH キーの保護が DNS に依存しているため、はるかに限定されたメカニズムです。Richard Barnes、Christian Huitema、Patrick McManus、Matthew Prince、Nick Sullivan、Martin Thomson、David Benjamin も重要なアイデアと貢献を提供しました。
Eric Rescorla
Independent
Email: ekr@rtfm.com
Kazuho Oku
Fastly
Email: kazuhooku@gmail.com
Additional contact information:
奥 一穂
Fastly
Nick Sullivan
Cryptography Consulting LLC
Email: nicholas.sullivan+ietf@gmail.com
Christopher A. Wood
Apple
Email: caw@heapingbits.net