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 <stephen.farr...@cs.tcd.ie>
Sent: Wednesday, February 7, 2024 5:23 PM
To: Elardus Erasmus <elardus.eras...@sophos.com>; tls@ietf.org
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
