Note behavior and give an example alongside configurations

[chris-wood]

Closes #519

cc @klinvill, @davidben, @dennisjackson, @cjpatton

[davidben]

I'm not sure what you mean by "how they respond to incoming client connections". Which certificate you send is arguably how part of "how they respond" but presumably we don't mean that! I suppose it could cover other externally-visible implementation choices like division of data into record-layer boundaries. That'd be a pretty solid example... but #519 talks about cipher suite selection, and that's already covered by configurations. So I'm just very confused right now.

[chris-wood]

The idea here is that how a server responds, and how that response is visible to the attacker, influences the anonymity set. So on that basis I would consider what certificate they send to be covered here. Note that we don't need to be very rigorous here -- this is just the introduction and the point is to convey the high-level goal of ECH.

[klinvill]

The broader point I meant to raise in #519 is that there are several choices servers can make that result in visible differences from the vantage point of an attacker, only some of which I would consider as part of the server's configuration (from an end-user's perspective) while others could end up being implementation differences like David mentions. For example, I would consider which cipher suites a server supports as part of a server's configuration. However, the order that extensions (e.g. key_share, pre_shared_key, supported_versions) appear in the plaintext ServerHello message is not typically a configuration value in the server but may be implementation dependent (since an extension order is not specified in neither the TLS 1.3 nor TLS ECH specs).

One could argue that these externally observable behaviors are part of the "externally visible TLS configurations", but I would argue that configurations should primarily refer to user-specifiable configurations to be consistent with the mental model I believe most server-providers would have upon reading the spec. I think it is therefore helpful to have additional text that points out that subtle implementation differences beyond user-provided configurations can result in servers being part of smaller anonymity sets than they may initially believe.

A server's cipher suite preferences could be user-specified, but other implementations may opt for a single static preference which may be incompatible with another implementations preferences. Other distinguishable behavior that I believe is not user-configured but implementation-specific includes choosing to send EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, and Finished messages as separate records or pack them into a few records (which I believe is a subset of what David is referring to as division of data into record-layer boundaries).

[klinvill]

Given that my main concern is that implementation-specific behavior can result in smaller anonymity sets than a user might believe based on their user-provided configurations, maybe we could rewrite the text to explicitly mention implementation-specific behavior. So the text could be something like:

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 ServerHello and HelloRetryRequest messages or division of data into record-layer boundaries, can result in different externally visible behavior, even when servers run using the same user-provided 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.

[chris-wood]

As above, I don't think we need to be rigorous or precise here. This suggestion is a lot more text than I think is warranted for this small point. That said... @davidben, does this additional text clarify your confusion?

[chris-wood]

@klinvill after thinking on this some more I decided to fold in a variant of your suggestion has a parenthetical. Please have another look?

[klinvill]

Thanks for the changes Chris, this looks good to me! I think the explicit parenthetical will help readers of this document understand that external configurations and behavior can include implementation-specific behaviors.

On a related note, I noticed that the security goals section includes a parenthetical that states: (The set of hosts which share the same ECHConfig and TLS configuration is referred to as the anonymity set.). Perhaps this should be updated to reflect the text here (e.g. include "externally visible"), or better yet drop the parenthetical all together and add an explicit definition of "anonymity set". I'll open a separate issue for this though since it's a different concern from what this PR addresses.

[chris-wood]

@klinvill we talk about the anonymity set in the security considerations -- we could simply point there?

[klinvill]

@klinvill we talk about the anonymity set in the security considerations -- we could simply point there?

Anonymity sets are discussed there, but not precisely defined. I think it might be nicer to have a canonical precise definition that could be referenced by the rest of the spec. I opened #568 to discuss this further (if warranted) and would be happy to take a stab at what such revisions would look like (as a PR).