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

Reply via email to