Draft: draft-ietf-tls-esni

Commentary: cc 
 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 can not probe , e.g. ,   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 do n't know the ECH configuration , but not active attackers . ECH usage is secret from passive attackers who do n'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 can not 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 ) .
Paragraph (version A):
The protocol specified by this document takes a different approach.
It assumes that private origins will co-locate with or hide behind a
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.
Paragraph (version B):
The protocol specified by this document takes a different approach.
It assumes that private origins will co-locate with or hide behind a
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
Given these types of attackers, the primary goals of ECH are as
follows.
Paragraph (version B):
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.
Paragraph (version B):
Passive attackers without the ECH configuration cannot distinguish
between a connection that negotiates ECH and one which uses a
GREASE "encrypted_client_hello" extension.
Paragraph (version B):
Active attackers can distinguish between a connection that
negotiates ECH and one which uses a GREASE
"encrypted_client_hello" extension.
Paragraph (version B):
See do-not-stick-out for more discussion about the "do not stick out"
criteria from RFC8744.