TLS Encrypted Client Hello

3.1. Topologies | 拓扑结构

                +---------------------+
                |                     |
                |   2001:DB8::1111    |
                |                     |
Client <----->  | private.example.org |
                |                     |
                | public.example.com  |
                |                     |
                +---------------------+
                        Server
          (Client-Facing and Backend Combined)

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

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.¶

在异址模式下, (网络服务)提供商(提供的面向客户端的)服务器不再是私有域(即内层 ClientHello 实际所指示的 SNI 对应的)的源服务器(后端服务器). 相反, 私有域的 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 威胁模型以及它与客户端、面向客户端的服务器和后端服务器的关系的更多讨论, 参见 Section 10.¶

3.2. Encrypted ClientHello (ECH)

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 [ECH-IN-DNS] 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]. 有关如何在 SVCB 和 HTTPS 记录中公布 ECH 配置的具体信息, 请参见 [ECH-IN-DNS]. 其他传递机制也是可能的. 例如, 客户端可能预配置了 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 会话时, 它构造一个私有 ClientHello, 称为 ClientHelloInner. 然后客户端构造一个公共 ClientHello, 称为 ClientHelloOuter. ClientHelloOuter 包含敏感扩展的无害值和一个 "encrypted_client_hello" 扩展 (Section 5) , 该扩展携带加密的 ClientHelloInner. 最后, 客户端向服务器发送 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.¶

   如果它不支持 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.¶

   如果它成功解密了扩展, 它将 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 是否被接受 (Section 6.1.4) 并相应地进行握手. 当 ECH 被拒绝时, 生成的连接不能被客户端用于应用数据. 相反, ECH 被拒绝后允许客户端使用最新配置重试 (Section 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 安全和隐私目标的更多详细信息, 请参见 Section 10.1.¶

4.1. Configuration Identifiers | 配置标识符

A client-facing server has a set of known ECHConfig values, with corresponding private keys. This set SHOULD contain the currently published values, as well as previous values that may still be in use, since clients may cache DNS records up to a TTL or longer.¶

面向客户端的服务器有一组已知的 ECHConfig 值, 以及相应的私钥. 此集合应包含当前发布的值, 以及可能仍在使用的先前值, 因为客户端可能会缓存 DNS 记录达到 TTL 或更长时间.¶

Section 7.1 describes a trial decryption process for decrypting the ClientHello. This can impact performance when the client-facing server maintains many known ECHConfig values. To avoid this, the client-facing server SHOULD allocate distinct config_id values for each ECHConfig in its known set. The RECOMMENDED strategy is via rejection sampling, i.e., to randomly select config_id repeatedly until it does not match any known ECHConfig.¶

Section 7.1 描述了解密 ClientHello 的试验解密过程. 当面向客户端的服务器维护许多已知的 ECHConfig 值时, 这可能会影响性能. 为了避免这种情况, 面向客户端的服务器应为其已知集合中的每个 ECHConfig 分配不同的 config_id 值. 推荐的策略是通过接受-拒绝算法, 即重复随机选择 config_id, 直到它不匹配任何已知的 ECHConfig.¶

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 值, 但不会对性能产生任何影响. 如果先前的 ECHConfig 不再在已知集合中, 也可以重用值.¶

4.2. Configuration Extensions | 配置扩展

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 配置扩展用于根据需要为附加功能提供空间. 格式如 Section 4 中定义, 镜像自 Section 4.2 of [RFC8446]. 但是, ECH 配置扩展类型由 IANA 维护, 如 Section 11.3 中所述. 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.¶

客户端必须解析扩展列表并检查不支持的强制性扩展. 如果强制性扩展不被支持, 客户端必须忽略此 ECHConfig.¶

Any future information or hints that influence ClientHelloOuter SHOULD be specified as ECHConfig extensions. This is primarily because the outer ClientHello exists only in support of ECH. Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see Section 7). In contrast, the inner ClientHello is the true ClientHello used upon ECH negotiation.¶

任何影响 ClientHelloOuter 的未来可能加入的信息或提示都推荐指定为 ECHConfig 扩展. 这主要是因为外部 ClientHello 仅存在于支持 ECH. 也就是说, 它既充当内部保存有加密 ClientHello 的信封, 又作为认证密钥不匹配信号的启用机制 (参见 Section 7) . 相比之下, 内部 ClientHello 才是在 ECH 协商时使用的真正 ClientHello.¶

5.1. Encoding the ClientHelloInner | 编码 ClientHelloInner

Before encrypting, the client pads and optionally compresses ClientHelloInner into a EncodedClientHelloInner structure, defined below:¶

在加密之前, 客户端将 ClientHelloInner 填充并可选地压缩到 EncodedClientHelloInner 结构中, 定义如下：¶

    struct {
        ClientHello client_hello;
        uint8 zeros[length_of_padding];
    } EncodedClientHelloInner;

The client_hello field is computed by first making a copy of ClientHelloInner and setting the legacy_session_id field to the empty string. In TLS, this field uses the ClientHello structure defined in Section 4.1.2 of [RFC8446]. In DTLS, it uses the ClientHello structured defined in Section 5.3 of [RFC9147]. This does not include Handshake structure's four-byte header in TLS, nor twelve-byte header in DTLS. The zeros field MUST be all zeroes of length length_of_padding (see Section 6.1.3).¶

client_hello 字段通过首先复制 ClientHelloInner 并将 legacy_session_id 字段设置为空字符串来计算. 在 TLS 中, 此字段使用 Section 4.1.2 of [RFC8446] 中定义的 ClientHello 结构. 在 DTLS 中, 它使用 Section 5.3 of [RFC9147] 中定义的 ClientHello 结构. 这不包括 TLS 中握手结构的四字节头部, 也不包括 DTLS 中的十二字节头部. zeros 字段必须是长度为 length_of_padding 的全零填充 (参见 Section 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", 可能导致过大的 ClientHello. 为了减少大小影响, 客户端可以替换它知道将在 ClientHelloOuter 中重复的扩展. 它通过从 EncodedClientHelloInner 中删除和替换扩展为单个 "ech_outer_extensions" 扩展来实现, 定义如下：¶

    enum {
       ech_outer_extensions(0xfd00), (65535)
    } ExtensionType;

    ExtensionType OuterExtensions<2..254>;

OuterExtensions contains the removed ExtensionType values. Each value references the matching extension in ClientHelloOuter. The values MUST be ordered contiguously in ClientHelloInner, and the "ech_outer_extensions" extension MUST be inserted in the corresponding position in EncodedClientHelloInner. Additionally, the extensions MUST appear in ClientHelloOuter in the same relative order. However, there is no requirement that they be contiguous. For example, OuterExtensions may contain extensions A, B, C, while ClientHelloOuter contains extensions A, D, B, C, E, F.¶

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.¶

最后, 客户端通过将 zeros 字段设置为内容全为零且长度为要添加的填充量的字节字符串来填充消息. Section 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.¶

  OuterExtensions 中引用了 "encrypted_client_hello".¶

• The extensions in ClientHelloOuter corresponding to those in OuterExtensions do not occur in the same order.¶

  ClientHelloOuter 中对应于 OuterExtensions 中那些扩展的扩展没有以相同顺序出现.¶

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 执行数据包放大攻击. 这在 Section 10.12.4 中进一步讨论.¶

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. 二次型时间实现 (如朴素复制) 会产生拒绝服务风险. Appendix A 描述了可用于此目的的线性时间过程.¶

5.2. Authenticating the ClientHelloOuter | 认证 ClientHelloOuter

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 Handshake structure's four-byte header in TLS nor twelve-byte header in DTLS.¶

为了防止网络攻击者在保持相同加密 ClientHelloInner 的同时修改 ClientHelloOuter (参见 Section 10.12.3) , ECH 通过将 ClientHelloOuterAAD 作为 HPKE 密封和打开操作的关联数据来认证 ClientHelloOuter. ClientHelloOuterAAD 是一个序列化的 ClientHello 结构, 在 TLS 的 Section 4.1.2 of [RFC8446] 和 DTLS 的 Section 5.3 of [RFC9147] 中定义, 它匹配 ClientHelloOuter, 除了 "encrypted_client_hello" 的 payload 字段被替换为相同长度但内容为零的字节字符串. 此值不包括 TLS 中握手结构的四字节头部, 也不包括 DTLS 中的十二字节头部.¶

6.1. Offering ECH | 提供 ECH

To offer ECH, the client first chooses a suitable ECHConfig from the server's ECHConfigList. To determine if a given ECHConfig is suitable, it checks that it supports the KEM algorithm identified by ECHConfig.contents.kem_id, at least one KDF/AEAD algorithm identified by ECHConfig.contents.cipher_suites, and the version of ECH indicated by ECHConfig.contents.version. Once a suitable configuration is found, the client selects the cipher suite it will use for encryption. It MUST NOT choose a cipher suite or version not advertised by the configuration. If no compatible configuration is found, then the client SHOULD proceed as described in Section 6.2.¶

为了提供 ECH, 客户端首先从服务器的 ECHConfigList 中选择合适的 ECHConfig. 为了确定给定的 ECHConfig 是否合适, 它检查是否支持由 ECHConfig.contents.kem_id 标识的 KEM 算法, 至少一个由 ECHConfig.contents.cipher_suites 标识的 KDF / AEAD 算法, 以及由 ECHConfig.contents.version 指示的 ECH 版本. 一旦找到合适的配置, 客户端选择它将用于加密的密码套件. 它不得选择配置未公布的密码套件或版本. 如果找不到兼容的配置, 则客户端必须按照 Section 6.2 中的描述进行.¶

Next, the client constructs the ClientHelloInner message just as it does a standard ClientHello, with the exception of the following rules:¶

接下来, 客户端构造 ClientHelloInner 消息, 就像构造标准 ClientHello 一样, 但有以下规则的例外：¶

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.¶

   它绝不能协商 TLS 1.2 或以下版本. 这是必要的, 以确保后端服务器不协商与 ECH 不兼容的 TLS 版本.¶

2. It MUST NOT offer to resume any session for TLS 1.2 and below.¶

   它绝不能执行 TLS 1.2 及以下任何版本的会话恢复.¶

3. If it intends to compress any extensions (see Section 5.1), it MUST order those extensions consecutively.¶

   如果它打算压缩任何扩展 (参见 Section 5.1) , 它必须连续排序这些扩展.¶

4. It MUST include the "encrypted_client_hello" extension of type inner as described in Section 5. (This requirement is not applicable when the "encrypted_client_hello" extension is generated as described in Section 6.2.)¶

   它必须包含类型为 inner 的 "encrypted_client_hello" 扩展, 如 Section 5 中所述.¶

The client then constructs EncodedClientHelloInner as described in Section 5.1. It also computes an HPKE encryption context and enc value as:¶

然后客户端按照 Section 5.1 中的描述构造 EncodedClientHelloInner. 它还计算 HPKE 加密上下文和 enc 值：¶

    pkR = DeserializePublicKey(ECHConfig.contents.public_key)
    enc, context = SetupBaseS(pkR,
                              "tls ech" || 0x00 || ECHConfig)

Next, it constructs a partial ClientHelloOuterAAD as it does a standard ClientHello, with the exception of the following rules:¶

接下来, 它构造部分 ClientHelloOuterAAD, 就像构造标准 ClientHello 一样, 但有以下规则的例外：¶

1. It MUST offer to negotiate TLS 1.3 or above.¶

   它必须协商 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.¶

   如果它在 EncodedClientHelloInner 中压缩了任何扩展, 它必须从 ClientHelloInner 复制相应的扩展. 复制的扩展还必须与 ClientHelloInner 中的相对顺序相同.¶

3. It MUST copy the legacy_session_id field from ClientHelloInner. This allows the server to echo the correct session ID for TLS 1.3's compatibility mode (see Appendix D.4 of [RFC8446]) when ECH is negotiated. 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.¶

   它必须从 ClientHelloInner 复制 legacy_session_id 字段. 这允许服务器在协商 ECH 时为 TLS 1.3 的兼容模式回显正确的会话 ID (参见 Appendix D.4 of [RFC8446]) . 请注意, 兼容模式在 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.)¶

   它可以从 ClientHelloInner 复制任何其他字段, 除了 ClientHelloInner.random. 相反, 它必须使用安全随机数生成器生成新的 ClientHelloOuter.random. (参见 Section 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.¶

   它必须将 ECHConfig.contents.public_name 的值放在 "server_name" 扩展中. 不遵循此步骤或在 "server_name" 扩展中放置不同值的客户端可能会破坏 Section 6.1.6 中描述的重试机制或无法与要求执行此步骤的服务器互操作；参见 Section 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.¶

   当客户端在 ClientHelloInner 中提供 "pre_shared_key" 扩展时, 它也应该在 ClientHelloOuter 中包含 GREASE "pre_shared_key"扩展, 按照 Section 6.1.2 中描述的方式生成. 客户端绝不能使用此扩展向面向客户端的服务器公布 PSK. (参见 Section 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.¶

   当客户端在 ClientHelloInner 中提供"early_data"扩展时, 它也必须在 ClientHelloOuter 中包含"early_data"扩展. 这允许拒绝 ECH 并使用 ClientHelloOuter 的服务器根据 [RFC8446], Section 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 中提供. 有关其他指导, 请参见 Section 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.¶

最后, 客户端使用上述值加密 EncodedClientHelloInner, 如 Section 6.1.1 中所述, 以构造 ClientHelloOuter. 它将此发送给服务器, 并按照 Section 6.1.4 中的描述处理响应.¶

    final_payload = context.Seal(ClientHelloOuterAAD,
                                 EncodedClientHelloInner)

6.2. GREASE ECH

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 连接突出的程度 (参见 Section 10.10.4) .¶

7.1. Client-Facing Server | 面向客户端的服务器

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 值. 此列表由以下两种方法之一确定：¶

1. Compare ECHClientHello.config_id against identifiers of each known ECHConfig and select the ones that match, if any, as candidates.¶

   将 ECHClientHello.config_id 与每个已知 ECHConfig 的标识符进行比较, 并选择匹配的 (如果有) 作为候选.¶

2. Collect all known ECHConfig values as candidates, with trial decryption below determining the final selection.¶

   收集所有已知的 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, 因为它可以用作跟踪向量. 在这种情况下, 必须使用第二种方法将 ECHClientHello 匹配到已知的 ECHConfig. 参见 Section 10.4. 除非由应用程序配置文件指定或以其他方式外部配置, 实现必须使用第一种方法.¶

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 从 ClientHelloOuter 计算, 如 Section 5.2 中所述. SetupBaseR 的 info 参数是连接 "tls ech"、零字节和序列化的 ECHConfig. 如果解密失败, 服务器继续到下一个候选 ECHConfig. 当解密成功, 服务器从 EncodedClientHelloInner 重构 ClientHelloInner, 如 Section 5.1 中所述. 然后它停止遍历候选 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" 警报中止. 此可选检查允许服务器将 ECH 连接限制为仅使用其 ECHConfigs 中公布的公共 SNI 值. 如果在具有不同公共名称的多个 ECHConfigs 中使用相同的 ECHConfig id 或密钥对, 服务器必须小心不要不必要地拒绝连接.¶

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 转发给适当的后端服务器, 后端服务器按照 Section 7.2 中的方式进行. 如果后端服务器响应 HelloRetryRequest, 面向客户端的服务器转发它, 使用 Section 7.1.1 中的过程解密客户端的第二个 ClientHelloOuter, 并转发结果的第二个 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 继续连接, 但有以下修改：¶

• 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" 扩展；详见 Section 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.¶

  如果服务器配置了任何 ECHConfigs, 它必须在其 EncryptedExtensions 中包含 "encrypted_client_hello" 扩展, 将 "retry_configs" 字段设置为一个或多个具有最新密钥的 ECHConfig 结构. 服务器可以提供不同版本的多个 ECHConfig 值. 这允许服务器同时支持多个版本.¶

Note that decryption failure could indicate a GREASE ECH extension (see Section 6.2), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required. In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (Section 8.1.1). Instead, servers can measure occurrences of the "ech_required" alert to detect this case.¶

请注意, 解密失败可能表示(客户端提供了) GREASE ECH 扩展 (参见 Section 6.2) , 因此服务器有必要继续连接并依赖客户端在需要 ECH 时中止. 特别是, 仅仅无法识别的值并不表示 ECH 公布配置错误 (Section 8.1.1) . 相反, 服务器可以测量 "ech_required" 警报的出现次数来检测这种情况.¶

    EncodedClientHelloInner = context.Open(ClientHelloOuterAAD,
                                         ECHClientHello.payload)

7.2. Backend Server | 后端服务器

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 已被接受.¶

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, 但 ServerHello.random 的最后 8 字节设置为零. 然后, 它计算从 ClientHelloInner 到包括修改后的 ServerHello 的 Transcript-Hash, 如 [RFC8446], Section 4.4.1 中所述. 让 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], Section 7.1, "0" 表示一串设置为零的 Hash.length 字节, 而 Hash 是用于计算 Transcript-Hash 的哈希函数. 在 DTLS 中, 使用 [RFC9147], Section 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 或更低版本, 则它绝不能执行此操作. 请注意, 这样做会覆盖 TLS 1.3 的降级信号 (参见 [RFC8446], Section 4.1.3) .¶

   hrr_accept_confirmation = HKDF-Expand-Label(
      HKDF-Extract(0, ClientHelloInner1.random),
      "hrr ech accept confirmation",
      transcript_hrr_ech_conf,
      8)

8.1. Compatibility Issues | 兼容性问题

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 扩展不同, 将 SNI 值放置在 ECH 扩展中与现有服务器不兼容, 这些服务器期望该值位于现有的明文扩展中. 因此, 服务器运营商必须确保服务器在发布 ECH 密钥集之前理解这些密钥. 此外, 服务器必须在其有效期内保留对先前发布的密钥的支持.¶

However, in more complex deployment scenarios, this may be difficult to fully guarantee. Thus this protocol was designed to be robust in case of inconsistencies between systems that advertise ECH keys and servers, at the cost of extra round-trips due to a retry. Two specific scenarios are detailed below.¶

然而, 在更复杂的部署场景中, 这可能难以完全保证. 因此, 该协议被设计为在发布 ECH 密钥的系统和(实际的)服务器之间存在不一致的情况下保持鲁棒性, 代价是由于重试而产生额外的往返. 下面详细说明了两个具体场景.¶

8.2. Deployment Impact | 部署影响

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, 并让客户端实现遵守此操作. 依赖于 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.¶

在 Section 6.1.6 的上下文中, 另一种方法可能是拦截和解密客户端TLS连接. 替代解决方案的可行性特定于个别部署.¶

10.1. Security and Privacy Goals

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 考虑两种类型的攻击者: 被动攻击者和主动攻击者. 被动攻击者可以从网络中读取数据包, 但他们无法执行任何主动行为, 如探测服务器或查询 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 做出了两个额外的假设:¶

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.¶

   每个面向客户端的服务器与每个后端服务器之间的通道是经过身份验证的, 使得后端服务器只接受来自受信任的面向客户端服务器的消息. 建立这个经过身份验证的通道的确切机制超出了本文档的范围.¶

2. The attacker cannot correlate messages between 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.¶

   攻击者无法将客户端与面向客户端的服务器之间的消息与面向客户端服务器与后端服务器之间的消息进行关联. 这种关联可能允许攻击者将后端服务器特有的信息 (如其服务器名称或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.¶

   安全性保护. 使用 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.)¶

   握手隐私. 与匿名集内服务器名称的 TLS 连接建立与匿名集内任何其他服务器名称的连接无法区分. (匿名集在 Section 1 中定义.)¶

3. Downgrade resistance. An attacker cannot downgrade a connection that attempts to use ECH to one that does not use ECH.¶

   降级抵抗. 攻击者无法将尝试使用 ECH 的连接降级为不使用 ECH 的连接.¶

These properties were formally proven in [ECH-Analysis].¶

这些属性在 [ECH-Analysis] 中得到了正式证明.¶

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. 这意味着面向客户端的服务器应该为尽可能多的服务器名称使用相同的ECHConfig. 攻击者可以基于 ECHClientHello.config_id 值区分具有不同 ECHConfig 值的两个服务器名称.¶

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 unencrypted handshake message. Similarly, if a backend origin reuses KeyShare values, then that provides a unique identifier for that server.¶

这也意味着 TLS 握手中的公开信息应该在服务器名称之间保持一致. 例如, 如果面向客户端的服务器为许多后端源服务器提供服务, 其中只有一个支持某个密码套件, 则可能基于未加密握手消息的内容识别该服务器名称. 类似地, 如果后端源重用 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 还旨在在一定程度上隐藏其正在被使用的事实. 具体来说, Section 6.2 中描述的 GREASE ECH 扩展完全不改变TLS握手的安全属性. 其目标是为真实的ECH协议 (Section 6.1) 提供 "掩护", 作为满足 [RFC8744] 的 "不突出" 要求的手段. 详见 Section 10.10.4.¶

10.2. Unauthenticated and Plaintext DNS | 未认证的或明文的 DNS

ECH supports delivery of configurations through the DNS using SVCB or HTTPS records, without requiring any verifiable authenticity or provenance information [ECH-IN-DNS]. 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 支持通过 DNS 使用 SVCB 或 HTTPS 记录来传递配置, 无任何可供验证的真实性或来源信息 [ECH-IN-DNS]. 这意味着任何能够注入 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 加密的常见情况. 此外, 如引言中所述, 如果没有对传输中 DNS 查询的加密, SNI 加密就不那么有用.¶

10.3. Client Tracking | 客户端跟踪

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 RRs 交付的针对每个客户端的 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 轮换率对于非恶意服务器也是一个问题, 这些服务器可能希望频繁轮换密钥以限制密钥被泄露时的暴露. 轮换过于频繁会限制客户端匿名集. 在实践中, 服务许多服务器名称且因此具有高负载的服务器是成为面向客户端服务器的最佳候选者, 因此即使在相当快的轮换间隔下, 匿名集通常也会涉及许多连接.¶

10.4. Ignored Configuration Identifiers and Trial Decryption | 忽略配置标识符和试验解密

Ignoring configuration identifiers may be useful in scenarios where clients and client-facing servers do not want to reveal information about the client-facing server in the "encrypted_client_hello" extension. In such settings, clients send a randomly generated config_id in the ECHClientHello. Servers in these settings must perform trial decryption since they cannot identify the client's chosen ECH key using the config_id value. As a result, ignoring configuration identifiers may exacerbate DoS attacks. Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECH key, in order to force wasteful decryption. Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the potential damage caused by such attacks.¶

忽略配置标识符在客户端和面向客户端的服务器不希望在 "encrypted_client_hello" 扩展中透露面向客户端服务器信息的场景中可能很有用. 在这种设置中, 客户端在 ECHClientHello 中发送随机生成的 config_id. 这些设置中的服务器必须执行试验解密, 因为它们无法使用 config_id 值识别客户端选择的 ECH 密钥. 因此, 忽略配置标识符可能会加剧 DoS 攻击. 具体来说, 攻击者可能发送恶意 ClientHello 消息, 即那些无法用任何已知 ECH 密钥解密的消息, 以强制进行浪费性解密. 支持此功能的服务器应该, 例如, 实现某种形式的速率限制机制来限制此类攻击造成的潜在损害.¶

Unless specified by the application using (D)TLS or externally configured, implementations MUST NOT use this mode.¶

除非使用(D)TLS的应用程序明确指定或外部配置, 否则实现绝不能使用此模式.¶

10.5. Outer ClientHello | 外层 ClientHello

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 中包含的任何信息对被动观察者都是可见的. 客户端绝不能在 ClientHelloOuter 中发送会透露敏感 ClientHelloInner 属性 (如真实服务器名称) 的值. 它可以在 ClientHelloOuter 中发送与公共名称相关的值.¶

In particular, some extensions require the client send a server-name-specific value in the ClientHello. These values may reveal information about the true server name. For example, the "cached_info" ClientHello extension [RFC7924] can contain the hash of a previously observed server certificate. The client SHOULD NOT send values associated with the true server name in the ClientHelloOuter. It MAY send such values in the ClientHelloInner.¶

特别是, 某些扩展要求客户端在 ClientHello 中发送特定于服务器名称的值. 这些值可能透露有关真实服务器名称的信息. 例如, "cached_info" ClientHello 扩展 [RFC7924] 可以包含先前观察到的服务器证书的哈希值. 客户端不应在 ClientHelloOuter 中发送与真实服务器名称相关的值. 它可以在 ClientHelloInner 中发送此类值.¶

A client may also use different preferences in different contexts. For example, it may send different ALPN lists to different servers or in different application contexts. A client that treats this context as sensitive SHOULD NOT send context-specific values in ClientHelloOuter.¶

客户端也可能在不同上下文中使用不同的首选项. 例如, 它可能向不同服务器或在不同应用程序上下文中发送不同的 ALPN 列表. 将此上下文视为敏感信息的客户端不应在 ClientHelloOuter 中发送特定于上下文的值.¶

Values which are independent of the true server name, or other information the client wishes to protect, MAY be included in ClientHelloOuter. If they match the corresponding ClientHelloInner, they MAY be compressed as described in Section 5.1. However, note 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 中. 如果它们与相应的 ClientHelloInner 匹配, 可以按 Section 5.1 中描述的方式进行压缩. 但是, 请注意, 载荷长度会透露有关哪些扩展被压缩的信息, 因此仅有时与相应外部扩展匹配的内部扩展不应被压缩.¶

Clients MAY include additional extensions in ClientHelloOuter to avoid signaling unusual behavior to passive observers, provided the choice of value and value itself are not sensitive. See Section 10.10.4.¶

客户端可以在 ClientHelloOuter 中包含额外的扩展以避免向被动观察者发出异常行为信号, 前提是值的选择和值本身不敏感. 参见 Section 10.10.4.¶

10.6. Inner ClientHello | 内层 ClientHello

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 提供的隐私属性时应考虑此类侧信道.¶

10.7. Related Privacy Leaks | 相关隐私泄漏

ECH requires encrypted DNS to be an effective privacy protection mechanism. However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity. Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess. It may also include implementation-specific traffic for additional information sources as part of verification.¶

ECH 需要加密 DNS 才能成为有效的隐私保护机制. 但是, 从 Certificate 消息验证服务器身份, 特别是使用 X509 CertificateType 时, 可能导致可能透露服务器身份的额外网络流量. 此类流量的示例可能包括对撤销信息的请求, 如 OCSP 或 CRL 流量, 或对存储库信息的请求, 如 authorityInformationAccess. 它还可能包括特定于实现的流量, 用于作为验证一部分的额外信息源.¶

Implementations SHOULD avoid leaking information that may identify the server. Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used. To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation.¶

实现应避免泄漏可能识别服务器的信息. 即使通过加密传输发送, 此类请求也可能导致服务器身份的间接暴露, 例如指示正在使用的特定 CA 或服务. 为了减轻此风险, 服务器应在可能时在带内传递此类信息, 例如 OCSP 装订, 客户端应采取措施在证书验证期间最小化或保护此类请求.¶

Attacks that rely on non-ECH traffic to infer server identity in an ECH connection are out of scope for this document. For example, a client that connects to a particular host prior to ECH deployment may later resume a connection to that same host after ECH deployment. An adversary that observes this can deduce that the ECH-enabled connection was made to a host that the client previously connected to and which is within the same anonymity set.¶

依赖非 ECH 流量来推断 ECH 连接中服务器身份的攻击超出了本文档的范围. 例如,在 ECH 部署之前连接到特定主机的客户端可能在 ECH 部署后恢复到同一主机的连接. 观察到这一点的攻击者可以推断 ECH 启用的连接是向客户端先前连接的主机建立的,并且该主机在同一匿名集内.¶

10.8. Cookies

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.¶

Section 4.2.2 of [RFC8446] 定义了服务器可能在 HelloRetryRequest 中发送供客户端在第二个 ClientHello 中回显的 cookie 值. 虽然 ECH 在第二个 ClientHelloInner 中加密 cookie, 但后端服务器的 HelloRetryRequest 是未加密的. 这意味着后端服务器之间 cookie 的差异, 如长度或明文组件, 可能泄漏有关服务器身份的信息.¶

Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server. This may be done by handling HelloRetryRequest statefully, thus not sending cookies, or by using the same cookie construction for all backend servers.¶

匿名集中的后端服务器绝不能在 cookie 中透露识别服务器的信息. 这可以通过有状态地处理 HelloRetryRequest (因此不发送cookie) 或对所有后端服务器使用相同的 cookie 构造来实现.¶

Note that, if the cookie includes a key name, analogous to Section 4 of [RFC5077], this may leak information if different backend servers issue cookies with different key names at the time of the connection. In particular, if the deployment operates in Split Mode, the backend servers may not share cookie encryption keys. Backend servers may mitigate this by either handling key rotation with trial decryption, or coordinating to match key names.¶

请注意,如果 cookie 包含密钥名称, 类似于 Section 4 of [RFC5077], 如果不同后端服务器在连接时使用不同密钥名称发出 cookie, 这可能泄漏信息. 特别是, 如果部署在分离模式下运行, 后端服务器可能不共享 cookie 加密密钥. 后端服务器可以通过试验解密处理密钥轮换或协调匹配密钥名称来缓解这一问题.¶

10.9. Attacks Exploiting Acceptance Confirmation | 利用接受确认的攻击

To signal acceptance, the backend server overwrites 8 bytes of its ServerHello.random with a value derived from the ClientHelloInner.random. (See Section 7.2 for details.) This behavior increases the likelihood of the ServerHello.random colliding with the ServerHello.random of a previous session, potentially reducing the overall security of the protocol. However, the remaining 24 bytes provide enough entropy to ensure this is not a practical avenue of attack.¶

为了发出接受信号, 后端服务器用从 ClientHelloInner.random 派生的值覆盖其 ServerHello.random 的 8 个字节. (详见 Section 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.¶

另一方面, 两个 8 字节字符串相同的概率是不可忽略的. 这带来了适度的操作风险. 假设面向客户端的服务器终止连接 (即,ECH被拒绝或绕过): 如果其 ServerHello.random 的最后 8 字节与确认信号重合, 那么客户端将错误地假定接受并继续进行, 就好像后端服务器终止连接一样. 但是, 给定连接出现误报的概率仅为 2^64 分之一. 此值小于实际网络连接故障的概率.¶

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], Section 4.1.3). 这些机制不会干扰, 因为后端服务器仅在 TLS 1.3 或更高版本中发出ECH接受信号.¶

10.10. Comparison Against Criteria | 与标准对比

[RFC8744] lists several requirements for SNI encryption. In this section, we re-iterate these requirements and assess the ECH design against them.¶

[RFC8744] 列出了 SNI 加密的几个要求. 在本节中, 我们重申这些要求并根据它们评估 ECH 设计.¶

10.11. Padding Policy | 填充策略

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 密文长度的变化可能泄漏有关相应明文的信息. Section 6.1.3 描述了旨在减少潜在信息泄漏的客户端推荐填充机制.¶

10.12. Active Attack Mitigations | 主动攻击缓解

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 属性和机制作为对主动攻击防御的基本原理. 在下面的所有攻击中, 攻击者位于目标客户端和服务器之间的路径上. 攻击者的目标是了解有关内部 ClientHello 的私有信息, 如真实 SNI 值.¶

 Client                         Attacker               Server
   ClientHello
   + key_share
   + ech         ------>      (intercept)     -----> X (drop)

                             ServerHello
                             + key_share
                   {EncryptedExtensions}
                   {CertificateRequest*}
                          {Certificate*}
                    {CertificateVerify*}
                 <------
   Alert
                 ------>

 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)

      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
                                          <--------

11.1. Update of the TLS ExtensionType Registry

IANA is requested to create the following entries in the existing registry for ExtensionType (defined in [RFC8446]):¶

要求 IANA 增加以下拓展类型 (定义于 [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 "Yes".¶

   encrypted_client_hello(0xfe0d), "TLS 1.3" 栏为 "CH, HRR, EE", "DTLS-Only" 栏为 "N", "Recommended" 栏为 "Yes".¶

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 "Yes", and the "Comment" column set to "Only appears in inner CH."¶

   ech_outer_extensions(0xfd00), "TLS 1.3" 栏为 "CH", "DTLS-Only" 栏为 "N", "Recommended" 栏为 "Yes", "Comment" 栏为 "Only appears in inner CH. (仅在 CH 出现)".¶

11.2. Update of the TLS Alert Registry

IANA is requested to create an entry, ech_required(121) in the existing registry for Alerts (defined in [RFC8446]), with the "DTLS-OK" column set to "Y".¶

要求 IANA 增加 ech_required(121) 警报 (定义于 [RFC8446]), "DTLS-OK" 项设置为 "Y".¶

11.3. ECH Configuration Extension Registry

IANA is requested to create a new "ECHConfig Extension" registry in a new "TLS Encrypted Client Hello (ECH) Configuration Extensions" page. New registrations need to list the following attributes:¶

要求 IANA 增加 "TLS Encrypted Client Hello (ECH) Configuration Extensions" 页, 记录 "ECHConfig Extension", 包含下列属性:¶

Value:

The two-byte identifier for the ECHConfigExtension, i.e., the ECHConfigExtensionType¶

ECHConfigExtension 二字节标识符, 即 ECHConfigExtensionType¶

Extension Name:

Name of the ECHConfigExtension¶

ECHConfigExtension 名称¶

Recommended:

A "Y" or "N" value indicating if the extension is TLS WG recommends that the extension be supported. This column is assigned a value of "N" unless explicitly requested. Adding a value with a value of "Y" requires Standards Action [RFC8126].¶

一个 "Y" 或 "N" 值, 表示扩展是否为 TLS 工作组建议支持的扩展. 除非明确请求, 否则此列被赋值为 "N". 添加值为 "Y" 的条目需要标准行动 [RFC8126].¶

Reference:

The specification where the ECHConfigExtension is defined¶

此 ECHConfigExtension 的定义位置¶

Notes:

Any notes associated with the entry¶

有关该项的注意事项¶

New entries in the "ECHConfig Extension" registry are subject to the Specification Required registration policy ([RFC8126], Section 4.6), with the policies described in [RFC8447], Section 17. IANA [shall add/has added] the following note to the TLS ECHConfig Extension registry:¶

"ECHConfig Extension" 中的新条目需要遵循规范要求注册策略 ([RFC8126], Section 4.6), 以及 [RFC8447], Section 17 中描述的策略. IANA [shall add/has added] 以下说明到 TLS ECHConfig Extension 注册表:¶

Note: The role of the designated expert is described in RFC 8447. 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 8447 中有所描述. 指定的专家 [RFC8126] 确保规范是公开可用的. 拥有互联网草案 (已发布但从未作为 RFC 发布) 或来自其他标准机构、行业联盟、大学站点等的文档就足够了. 专家可以提供更深入的审查, 但他们的批准不应被视为对扩展的认可.¶

This document defines several Reserved values for ECH configuration extensions to be used for "greasing" as described in Section 6.2.2.¶

本文档为 ECH 配置扩展定义了几个保留值, 用于 Section 6.2.2 中描述的 "greasing".¶

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¶

Extension Name:

RESERVED¶

Recommended:

Y¶

Reference:

This document¶

Notes:

Grease entries.¶

12.1. Normative References

[ECH-IN-DNS]

Schwartz, B. M., Bishop, M., and E. Nygren, "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings", Work in Progress, Internet-Draft, draft-ietf-tls-svcb-ech-08, 16 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-svcb-ech-08>.

[HPKE]

Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, <https://www.rfc-editor.org/rfc/rfc9180>.

[RFC2119]

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

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC6125]

Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/rfc/rfc6125>.

[RFC7918]

Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", RFC 7918, DOI 10.17487/RFC7918, August 2016, <https://www.rfc-editor.org/rfc/rfc7918>.

[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/rfc/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/rfc/rfc8174>.

[RFC8446]

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

[RFC8447]

Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/rfc/rfc8447>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/rfc/rfc9147>.

[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/rfc/rfc9460>.

12.2. Informative References

[DNS-TERMS]

Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, <https://www.rfc-editor.org/rfc/rfc9499>.

[ECH-Analysis]

"A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted Client Hello", November 2022, <https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf>.

[I-D.kazuho-protected-sni]

Oku, K., "TLS Extensions for Protecting SNI", Work in Progress, Internet-Draft, draft-kazuho-protected-sni-00, 18 July 2017, <https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00>.

[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/rfc/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/rfc/rfc3986>.

[RFC5077]

Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/rfc/rfc5077>.

[RFC7301]

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

[RFC7858]

Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/rfc/rfc7858>.

[RFC7924]

Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/rfc/rfc7924>.

[RFC8094]

Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, <https://www.rfc-editor.org/rfc/rfc8094>.

[RFC8484]

Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/rfc/rfc8484>.

[RFC8701]

Benjamin, D., "Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility", RFC 8701, DOI 10.17487/RFC8701, January 2020, <https://www.rfc-editor.org/rfc/rfc8701>.

[RFC8744]

Huitema, C., "Issues and Requirements for Server Name Identification (SNI) Encryption in TLS", RFC 8744, DOI 10.17487/RFC8744, July 2020, <https://www.rfc-editor.org/rfc/rfc8744>.

[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/rfc/rfc9250>.

[WHATWG-IPV4]

"URL Living Standard - IPv4 Parser", May 2021, <https://url.spec.whatwg.org/#concept-ipv4-parser>.

C.1. Since draft-ietf-tls-esni-16

• Keep-alive¶

C.2. Since draft-ietf-tls-esni-15

• Add CCS2022 reference and summary (#539)¶

C.3. Since draft-ietf-tls-esni-14

• Keep-alive¶

C.4. Since draft-ietf-tls-esni-13

• Editorial improvements¶

C.5. Since draft-ietf-tls-esni-12

• Abort on duplicate OuterExtensions (#514)¶

• Improve EncodedClientHelloInner definition (#503)¶

• Clarify retry configuration usage (#498)¶

• Expand on config_id generation implications (#491)¶

• Server-side acceptance signal extension GREASE (#481)¶

• Refactor overview, client implementation, and middlebox sections (#480, #478, #475, #508)¶

• Editorial iprovements (#485, #488, #490, #495, #496, #499, #500, #501, #504, #505, #507, #510, #511)¶

C.6. Since draft-ietf-tls-esni-11

• Move ClientHello padding to the encoding (#443)¶

• Align codepoints (#464)¶

• Relax OuterExtensions checks for alignment with RFC8446 (#467)¶

• Clarify HRR acceptance and rejection logic (#470)¶

• Editorial improvements (#468, #465, #462, #461)¶

C.7. Since draft-ietf-tls-esni-10

• Make HRR confirmation and ECH acceptance explicit (#422, #423)¶

• Relax computation of the acceptance signal (#420, #449)¶

• Simplify ClientHelloOuterAAD generation (#438, #442)¶

• Allow empty enc in ECHClientHello (#444)¶

• Authenticate ECHClientHello extensions position in ClientHelloOuterAAD (#410)¶

• Allow clients to send a dummy PSK and early_data in ClientHelloOuter when applicable (#414, #415)¶

• Compress ECHConfigContents (#409)¶

• Validate ECHConfig.contents.public_name (#413, #456)¶

• Validate ClientHelloInner contents (#411)¶

• Note split-mode challenges for HRR (#418)¶

• Editorial improvements (#428, #432, #439, #445, #458, #455)¶

C.8. Since draft-ietf-tls-esni-09

• Finalize HPKE dependency (#390)¶

• Move from client-computed to server-chosen, one-byte config identifier (#376, #381)¶

• Rename ECHConfigs to ECHConfigList (#391)¶

• Clarify some security and privacy properties (#385, #383)¶