Hi there, There have been no replies on this. I am wondering if it means that TLS client implementations will not support this (retry logic on securely disabled ECH), or just that it has not been implemented yet.
The wording “may trigger the retry logic” from the draft is maybe a hint of the intension. I would like to request the ECH implementers of the various stacks to comment on this please. I suppose the same question should be asked on the QUIC WG also. Though not exactly the same since the “middlebox“ section is not in the QUIC ECH draft. Thanks, SB > On Sep 20, 2022, at 9:35 AM, Safe Browsing <safebrowsing...@gmail.com> wrote: > > Yes, that is it. Via section 8.2: > > 8.2. Middleboxes > > When connecting through a TLS-terminating proxy that does not support this > extension, [RFC8446], Section 9.3 requires the proxy still act as a > conforming TLS client and server. The proxy must ignore unknown parameters, > and generate its own ClientHello containing only parameters it understands. > Thus, when presenting a certificate to the client or sending a ClientHello to > the server, the proxy will act as if connecting to the public name, without > echoing the "encrypted_client_hello" extension. > > Depending on whether the client is configured to accept the proxy's > certificate as authoritative for the public name, this may trigger the retry > logic described in Section 6.1.6 or result in a connection failure. A proxy > which is not authoritative for the public name cannot forge a signal to > disable ECH. > > > Is there a TLS client with ECH support available, implementing ECH disabling > in such a manner that invokes the retry logic to achieve a successful > connection when the middlebox removes/filters the ECH extension? > > >>> On Sep 19, 2022, at 5:10 PM, Eric Rescorla <e...@rtfm.com> wrote: >>> >> >> Are you referring to this text in 6.1.6 or something else? >> >> "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." >> >> -Ekr >> >> >> >>> On Mon, Sep 19, 2022 at 11:20 AM Safe Browsing <safebrowsing...@gmail.com> >>> wrote: >>> Good day, >>> >>> The ECH draft describes a method for securely disabling ECH - at the cost >>> of an extra round trip. Is there a client and server implementation that >>> supports this functionality already - securely disabling ECH? >>> >>> SB >>> _______________________________________________ >>> 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
