Original text:
The protocol specified by this document takes a different approach. It assumes that private origins will co-locate with or hide behind a <del> provider (reverse proxy, application server, etc.) that protects SNIs for all of the domains it hosts.  As a result, SNI protection does not indicate that the client is attempting to reach a private origin, but only that it is going to a particular service provider, which the observer could already tell from the visible IP address. </del>  This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to a or not ECH was accepted and proceeds with the handshake accordingly. (See client-behavior for details.)  4. ECH uses HPKE for public key encryption I-D.irtf-cfrg-hpke.  The ECH 10.1. <del> Informally, the primary security and privacy goals of ECH against an active attacker are as follows: </del>  Use of ECH does not weaken the security properties of TLS without ECH. cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages.  10.2. In comparison to I-D.kazuho-protected-sni, wherein DNS Resource

Reviewer comments:
cc NAME
In just a few sentences, let's define the anonymity set and say what it means for connections to end points in this set to be indistignuishable. We might also enumerate non-goals (though we still need consensus on what these are).
I've not yet gotten around to the PR yet, but here's the gist: Attackers: Passive attackers are those which cannot probe, e.g., buggy middleboxes that filter based on plaintext packet contents. Active attackers can probe, e.g., censors. Goals: ECH does not negatively affect any existing security properties of TLS 1.3. ECH connections to servers in the same anonymity set are indistinguishable from one another for passive and active attackers, modulo traffic analysis. (Note: an anonymity set is determined by the client and server parameters, e.g., the SNI, supported application protocols, and so on.) ECH support is secret from passive attackers who don't know the ECH configuration, but not active attackers. ECH usage is secret from passive attackers who don't know the ECH configuration, but not active attackers. More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not (GREASEd or using a different configuration). Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which does not (but GREASEd). Active attackers can distinguish between a connection that negotiates ECH and one which does not (but GREASEd).
Yeah this looks good.
From the interim: merge this as a PR and then address censorship separately (if desired).

Revised text:
The protocol specified by this document takes a different approach. It assumes that private origins will co-locate with or hide behind a  <ins> provider (reverse proxy, application server, etc.) that protects sensitive ClientHello parameters, including the SNI, for all of the domains it hosts.  These co-located servers form an anonymity set wherein all elements have a consistent configuration, e.g., the set of supported application protocols, ciphersuites, TLS versions, and so on.  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.  Thus, it leaks no more than what is already visible from the server IP address. </ins> This document specifies a new TLS extension, called Encrypted Client Hello (ECH), that allows clients to encrypt their ClientHello to a or not ECH was accepted and proceeds with the handshake accordingly. (See client-behavior for details.) <ins> Informally, a primary goal of ECH is ensuring that connections to servers in the same anonymity set are indistinguishable from one another without affecting any existing security properties of TLS 1.3.  See goals for more details about the ECH security and privacy goals. </ins> 4. ECH uses HPKE for public key encryption I-D.irtf-cfrg-hpke.  The ECH 10.1.  <ins> ECH considers two types of attackers: passive and active.  Passive attackers can read packets from the network.  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 write packets into the network for malicious purposes, such as interfering with existing connections, probing servers, and querying DNS.  In short, an active attacker corresponds to the conventional threat model for TLS 1.3 RFC8446. Given these types of attackers, the primary goals of ECH are as follows. </ins> Use of ECH does not weaken the security properties of TLS without ECH. cipher suite, it may be possible to identify that host based on the contents of unencrypted handshake messages. <ins> Beyond these primary security and privacy goals, ECH also aims to hide, to some extent, (a) whether or not a specific server supports ECH and (b) whether or not ECH was accepted for a particular connection.  ECH aims to achieve both properties, assuming the attacker is passive and does not know the set of ECH configurations offered by the client-facing server.  It does not achieve these properties for active attackers.  More specifically: Passive attackers with a known ECH configuration can distinguish between a connection that negotiates ECH with that configuration and one which does not, because the latter used a GREASE "encrypted_client_hello" extension (as specified in grease- extensions) or a different ECH configuration. Passive attackers without the ECH configuration cannot distinguish between a connection that negotiates ECH and one which uses a GREASE "encrypted_client_hello" extension. Active attackers can distinguish between a connection that negotiates ECH and one which uses a GREASE "encrypted_client_hello" extension. See do-not-stick-out for more discussion about the "do not stick out" criteria from RFC8744. </ins> 10.2. In comparison to I-D.kazuho-protected-sni, wherein DNS Resource