From b9b723cd108a96a9218abb34bbc74f4f998900f1 Mon Sep 17 00:00:00 2001 From: EKR Date: Fri, 11 Oct 2024 17:12:22 -0700 Subject: [PATCH 1/2] Comments from AD review. --- draft-ietf-tls-esni.md | 47 +++++++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 21 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index a7048f17..af64160d 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -81,7 +81,7 @@ domain for a given connection, is perhaps the most sensitive information left unencrypted in TLS 1.3. This document specifies a new TLS extension, called Encrypted Client Hello -(ECH), that allows clients to encrypt their ClientHello to such a deployment. +(ECH), that allows clients to encrypt their ClientHello to the TLS server. This protects the SNI and other potentially sensitive fields, such as the ALPN list {{?RFC7301}}. Co-located servers with consistent externally visible TLS configurations and behavior, including supported versions and cipher suites and @@ -95,9 +95,10 @@ anonymity set terminates the connection. Deployment implications of this feature are discussed in {{deployment}}. 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, DoH {{?RFC8484}} -and DPRIVE {{?RFC7858}} {{?RFC8094}} provide mechanisms for clients to conceal +The target domain may also be visible through other channels, such as +plaintext client DNS queries or visible server IP addresses. However, +DNS over HTTPS {{?RFC8484}} and DNS over TLS/DTLS {{?RFC7858}} +{{?RFC8094}} provide mechanisms for clients to conceal DNS lookups from network inspection, and many TLS servers host multiple domains on the same IP address. Private origins may also be deployed behind a common provider, such as a reverse proxy. In such environments, the SNI remains the @@ -171,8 +172,9 @@ and how it relates to the client, client-facing server, and backend server. ## Encrypted ClientHello (ECH) A client-facing server enables ECH by publishing an ECH configuration, which -is an encryption public key and associated metadata. The server must publish -this for all the domains it serves via Shared or Split Mode. This document +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=I-D.ietf-tls-svcb-ech}} for specifics about how ECH @@ -1398,12 +1400,12 @@ unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards). Thus, allowing the ECH records in the clear does not make the situation significantly worse. -Clearly, DNSSEC (if the client validates and hard fails) is a defense against -this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by -attackers on the local network, which is a common case where ClientHello and SNI -encryption are desired. Moreover, as noted in the introduction, SNI encryption -is less useful without encryption of DNS queries in transit via DoH or DPRIVE -mechanisms. +Clearly, DNSSEC (if the client validates and hard fails) is a defense +against this form of attack, but encrypted DNS transport is also a +defenses against DNS attacks by attackers on the local network, which +is a common case where ClientHello and SNI encryption are +desired. Moreover, as noted in the introduction, SNI encryption is +less useful without encryption of DNS queries in transit mechanisms. ## Client Tracking @@ -1451,14 +1453,14 @@ The client SHOULD NOT send values associated with the true server name in the ClientHelloOuter. It MAY send such values in the ClientHelloInner. A client may also use different preferences in different contexts. For example, -it may send a different ALPN lists to different servers or in different +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. 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 -{{encoding-inner}}. However, note that the payload length reveals information +{{encoding-inner}}. However, note that the paylod length reveals information about which extensions are compressed, so inner extensions which only sometimes match the corresponding outer extension SHOULD NOT be compressed. @@ -1568,7 +1570,7 @@ bound by the number of hosts that share an IP address. Server operators may further limit sharing by publishing different DNS records containing ECHConfig values with different keys using a short TTL. -### Prevent SNI-Based Denial-of-Service Attacks +### SNI-Based Denial-of-Service Attacks This design requires servers to decrypt ClientHello messages with ECHClientHello extensions carrying valid digests. Thus, it is possible for an attacker to force @@ -1590,7 +1592,7 @@ evaluate the deployability of ECH. It is designed to mimic the real ECH protocol ({{real-ech}}) without changing the security properties of the handshake. The underlying theory is that if GREASE ECH is deployable without triggering middlebox misbehavior, and real ECH looks enough like GREASE ECH, then ECH -should be deployable as well. Thus, our strategy for mitigating network +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. @@ -1630,15 +1632,18 @@ out-of-scope for this specification. ### Maintain Forward Secrecy -This design is not forward secret because the server's ECH key is static. -However, the window of exposure is bound by the key lifetime. It is RECOMMENDED -that servers rotate keys frequently. +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 frequently. ### Enable Multi-party Security Contexts This design permits servers operating in Split Mode to forward connections directly to backend origin servers. The client authenticates the identity of -the backend origin server, thereby avoiding unnecessary MiTM attacks. +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. Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a @@ -1940,7 +1945,7 @@ Reference: : This document Notes: -: None +: Grease entries. {: spacing="compact"} --- back From 122a1655ab109d3e11ce1622714218a11fefee5e Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Sun, 27 Oct 2024 12:12:25 -0700 Subject: [PATCH 2/2] Update draft-ietf-tls-esni.md Co-authored-by: Martin Thomson --- draft-ietf-tls-esni.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index af64160d..4e7a36c8 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -1460,7 +1460,7 @@ send context-specific values in 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 -{{encoding-inner}}. However, note that the paylod length reveals information +{{encoding-inner}}. 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.