On Wed, Feb 7, 2024 at 2:06 PM Elardus Erasmus <Elardus.Erasmus= 40sophos....@dmarc.ietf.org> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
