Feature Request: `ECHConfigList.permit_plaintext`

[bemasc]

@davidben

Currently, if all the ECHConfigs in the ECHConfigList are rejected by the client, the client always falls back to sending the ClientHello in plaintext. This is normally appropriate, but it may not always be. Once ECH is well-established, secretive servers may prefer for clients to fail the connection rather than revealing the server's SNI by connecting without ECH, especially if the server only accepts ECH ClientHellos.

Unfortunately, an ECHConfig extension cannot be used to express this preference, because extensions are scoped to a specific ECHConfig, and we are discussing the case where all ECHConfigs have been rejected.

A boolean field in ECHConfigList (e.g. permit_plaintext, ech_only) would be sufficient to encode this instruction.

[martinthomson]

Is this better as an ECH extension, or as a separate SVCB extension (for example)? That would allow the assertion to apply more broadly. If you could put that on an AliasMode record, that might have interesting applications.

[davidben]

I think this is something we should defer. As @martinthomson says, we can still do this as a SVCB extension if needed. I expect we can also manage an ECHConfig extension by tweaking the ECHConfigList rules slightly, even if it's a bit janky.

Indeed, the case where all ECHConfigs are rejected is another reason to defer it. Every draft protocol is doomed to die, which means that no server can, right now, produce a stable ECH deployment. They are guaranteed that some future ECH-capable clients will reject their ECHConfigList.

And from the client's perspective, I would be very uncomfortable implementing this mechanism before we understand a bit better how ECH works in practice. How likely are rollbacks? How stale of DNS do we see in practice? How much of a concern are users who switch back and forth from a TLS-terminating middlebox, with all the problems that comes with?

Finally, is changing the outer ECHConfigList structure even an option at this point? Didn't you all have a lot of troubles with renaming the SvcParam, and that didn't even affect the wire format? Changing ECHConfigList would actually be a wire-format change. (If changing that is on the table, I kinda regret the two-byte length prefix in front...)

[sftcd]

On 22/07/2021 07:35, David Benjamin wrote:

I think this is something we should defer.

+1

I wonder would it be useful to see if the TLS WG had consensus on something like "no more changes for ECH for now, (except security fixes if needed)" maybe with an additional "the WG will revisit ECH a year or so after publication-requested to see what changes based on deployment experience might be good"

S.

[chris-wood]

To add to the chorus above, this can be dealt with via an extension. Please propose it via a new draft! I'm closing this based on that recommendation.