Re: [TLS] Input on ECH specification

[Eric Rescorla <[e-mail]>]

On Wed, Feb 7, 2024 at 2:06 PM Elardus Erasmus <Elardus.Erasmus=
[e-mail]> wrote:

> 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.
>

I agree with this. I have created PR #603 to address this:
https://github.com/tlswg/draft-ietf-tls-esni/pull/603





> *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.
>

I think I agree with you that we shouldn't limit




> 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.*
>

See https://github.com/tlswg/draft-ietf-tls-esni/issues/604 for discussion
on this.

-Ekr


>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>