Re: [TLS] Input on ECH specification

[Elardus Erasmus <[e-mail]>]

Hi Stephen (and others),

Any thoughts on the items below? If not, I could create PR for further consideration.

Thanks and regards,
Elardus

From: TLS <[e-mail]> On Behalf Of Elardus Erasmus
Sent: Thursday, February 8, 2024 9:44 AM
To: Stephen Farrell <[e-mail]>; [e-mail]
Subject: Re: [TLS] Input on ECH specification

Hi Stephen,   Thanks for pointing this out. In describing the suggestion, I incorrectly used "server_hello", but in the actual suggested text, the correct "EncryptedExtensions mess

Hi Stephen,

Thanks for pointing this out. In describing the suggestion, I incorrectly used "server_hello", but in the actual suggested text, the correct "EncryptedExtensions message" is used.

Let me update the email accordingly, below, and maybe more in the light of general ECH rejection, as opposed to rejection for an absent ECH extension from EE specifically.

Suggestion 1
If I understand correctly, the intention is that a new transport connection should be made, with ECH disabled, for all ECH rejection scenarios - provided "both authentication and the handshake complete successfully", of course. If that is correct, then maybe this (or something else along these lines) could make it clearer:

Section 6.1.6 states:
If none of the values provided in "retry_configs" contains a supported version,
or an earlier TLS version was negotiated, the client can regard ECH as securely
disabled by the server, and it SHOULD retry the handshake with a new transport
connection and ECH disabled.
Maybe change to:
If none of the values provided in "retry_configs" contains a supported version,
or ECH was rejected for any of the reasons in Section 6.1.4,
the client can regard ECH as securely disabled by the server. It SHOULD retry
the handshake with a new transport connection and ECH disabled. If the client
does not retry, it MUST report an error to the calling application.

Suggestion 2
Section 6.1.6 also mentions that:
Clients SHOULD implement a limit on retries caused by receipt of "retry_configs"
or servers which do not acknowledge the "encrypted_client_hello" extension.

The text does not differentiate between retry types for the purpose of limiting the connections. I.e., if the ECH config was replaced, then it is an ECH-enabled retry (with new keys). But if ECH was rejected, then it is an ECH-disabled retry. Limiting the connections may make sense for ECH-enabled retries due to config replacement. But limiting it for ECH-disabled connection retries could mean that connections may start failing abruptly, depending on the aggressiveness of the limit on the client. As long as ECH-disabled connection retries succeed, they should possibly not be limited so that connectivity does not suffer unnecessarily.

It would probably even be good/necessary to implement a holdoff on ECH-enabled connections after ECH has been rejected. I.e., not making an ECH-enabled connection to an SNI that resulted in ECH disabling for some duration of time. Some scenarios where this would be desirable:

  *   The ECH version steps. This will lead to ECH-disabled retries. During DNS propagation time, the number of connections to client-facing servers of ECH enabled sites will double (say a large CDN activates a version step of all its sites all at once). Clients that limit retries could experience connectivity issues, but clients that implement a holdoff would mitigate the connection doubling problem in such a scenario.
  *   A server disables ECH temporarily or serves TLS 1.2. Again, ECH will be rejected/securely disabled, and a connectivity loss may occur (retry limit). A doubling in connections will be experienced until DNS propagation is finished - or indefinitely in case of a config issue (e.g. server administrator does not remove ECH config from DNS).
  *   Section 8.2 talks about middleboxes acting as TLS-terminating proxies. All connections going through such proxies will result in ECH being disabled (due to the ECH extension not being forwarded to the server). Also leading to a possible connectivity loss, or at the very least a permanent doubling in connections.

The "connection doubling" in the scenarios above increases connection establishment latency and adds load to the client, server, and other stateful network devices, and can be mitigated by a temporary holdoff on ECH-enabled connections on the client.

The proposal is therefore to change Section 6.1.6 from:
If none of the values provided in "retry_configs" contains a supported version,
or an earlier TLS version was negotiated, the client can regard ECH as securely
disabled by the server, and it SHOULD retry the handshake with a new transport
connection and ECH disabled.

Clients SHOULD implement a limit on retries caused by receipt of "retry_configs"
or servers which do not acknowledge the "encrypted_client_hello" extension. If
the client does not retry in either scenario, it MUST report an error to the
calling application.

To something like:
Clients SHOULD implement a limit on retries caused by receipt of "retry_configs".
If the client does not retry, it MUST report an error to the calling application.

If none of the values provided in "retry_configs" contains a supported version,
or ECH was rejected for any of the reasons in Section 6.1.4,
the client can regard ECH as securely disabled by the server. It SHOULD retry
the handshake with a new transport connection and ECH disabled. If the client
does not retry, it MUST report an error to the calling application.

Clients SHOULD implement a holdoff on ECH-enabled connections to an SNI for
which ECH has been securely disabled. I.e., those connections made after the
ECH-disabled retry. Clients SHOULD still send a GREASE ECH extension (see
{{grease-ech}}) for ECH-disabled connections made during the holdoff period.

Thanks,
Elardus


-----Original Message-----
From: Stephen Farrell <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, February 7, 2024 5:23 PM
To: Elardus Erasmus <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [TLS] Input on ECH specification

Caution! This message was sent from outside your organization.


Hiya,

Would have to read the other bits but this jumped out...

On 07/02/2024 22:06, Elardus Erasmus wrote:
> Make it clear that if an ECH extension is absent from the
> server_hello, it qualifies as an ECH disabling signal.
When ECH is in real use, most SH messages won't contain an ECH extension as the acceptance signal is encoded in bits of the SH.random. You only see an ECH extension in a SH when we hit HRR. (IIRC.)

Apologies if I'm misinterpreting you in the quote above.
Just sending now in case correcting this changes other bits of your mail (or how I should read it:-)

Cheers,
S.