Hi,
I figured it would be better to send an email, rather than proposing and
discussing this on a PR (proposed edits/diffs are at the bottom of this email).
We have two suggestions regarding the specification text
(https://datatracker.ietf.org/doc/draft-ietf-tls-esni/):
Suggestion 1
Make it clear that if an ECH extension is absent from the server_hello, it
qualifies as an ECH disabling signal. The text earlier in the section already
requires that "both authentication and the handshake complete successfully" in
the initial ECH-enabled connection, for ECH to be regarded as disabled. The
same (ECH disabling due to absent ECH ext from server) can be deducted by
reading a few paragraphs, but even then, it is not clear. This makes it much
clearer.
In Section 6.1.6, change:
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.
To:
If none of the values provided in "retry_configs" contains a supported version,
or an earlier TLS version was negotiated, or the server did not supply an
"encrypted_client_hello" extension in its EncryptedExtensions message, the
client can regard ECH as securely disabled by the server. It SHOULD retry
the handshake with a new transport connection and ECH disabled.
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 disabled, then it is an
ECH-disabled retry. Limiting the connections makes sense for ECH-enabled
retries due to config replacement, since the connections seem not be successful
in any case and thus the extra load is not necessary. But limiting it for
ECH-disabled connections could mean that connections may start failing
abruptly, depending on the aggressiveness of the limit on the client. As long
as ECH-disabled connections succeed, they should not be limited so that
connectivity does not suffer unnecessarily.
It would probably even be good/necessary to implement a holdoff on the client
in the ECH-disabled case. 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
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 being absent from the server_hello). 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, middlebox, 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:
Clients SHOULD implement a limit on ECH-enabled retries caused by the secure
replacement of ECH keys by "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 an earlier TLS version was negotiated, or the server did not supply an
"encrypted_client_hello" extension in its EncryptedExtensions message, 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
(suggested diffs to the specification below)
@@ -852,10 +852,11 @@ If the server supplied an "encrypted_client_hello"
extension in its
EncryptedExtensions message, the client MUST check that it is syntactically
valid and the client MUST abort the connection with a "decode_error" alert
otherwise. If an earlier TLS version was negotiated, the client MUST NOT enable
-the False Start optimization {{RFC7918}} for this handshake. If both
-authentication and the handshake complete successfully, the client MUST perform
-the processing described below then abort the connection with an "ech_required"
-alert before sending any application data to the server.
+the False Start optimization {{RFC7918}} for this handshake.
+
+If both authentication and the handshake complete successfully, the client MUST
+perform the processing described below then abort the connection with an
+"ech_required" alert before sending any application data to the server.
If the server provided "retry_configs" and if at least one of the values
contains a version supported by the client, the client can regard the ECH keys
@@ -876,15 +877,21 @@ because the client will send cookies to the server in
parallel connections,
using the retry configurations for these parallel connections does not
introduce a new tracking vector.
+Clients SHOULD implement a limit on ECH-enabled retries caused by the secure
+replacement of ECH keys by "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 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.
+or an earlier TLS version was negotiated, or the server did not supply an
+"encrypted_client_hello" extension in its EncryptedExtensions message, 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.
### Authenticating for the Public Name {#auth-public-name}
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
