TLS 1.3 clients using ECH will not fall back to non-ECH upon unauthenticated failure, just as TLS clients of any kind will not fall back to a lower version upon unauthenticated failure. To control the TLS version, or the usage of ECH, one must either control the client's behavior directly or be able to authenticate as the TLS destination to the client's satisfaction. In an enterprise context, the latter is often accomplished by implanting a special local certificate authority into the client's trust store.
--Ben ________________________________ From: Paul Vixie <p...@redbarn.org> Sent: Thursday, July 25, 2024 12:11 AM To: Paul Wouters <p...@nohats.ca>; Ben Schwartz <bem...@meta.com> Cc: Tommy Jensen <jensen.tho...@microsoft.com>; dnsop <dnsop@ietf.org>; Damick, Jeffrey <jdam...@amazon.com>; Engskow, Matt <mengs...@amazon.com>; Jessica Krynitsky <jess.krynit...@microsoft.com> Subject: Re: [DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt On Tuesday, July 23, 2024 1:56:50 PM PDT Ben Schwartz wrote: > It seems like there's some confusion here. ECH is an extension to TLS that > is still under development (and now nearly final). Use of ECH is optional > in TLS 1.3. Any entity that can control the TLS version in use also has > the ability to disable ECH, so allowing TLS 1.3 does not require an > administrator to permit ECH. > > --Ben Schwartz If a client who tries TLS 1.3 with ECH can be detected by an enterprise ("next generation") firewall using the spoofed-SYNACK trick so common for HTTPS, and made to fail, and would then have some reason to retry TLS 1.3 without ECH, rather than just giving up or moving straight to TLS 1.2, this is the first i'm hearing of it. is this advice-to-implementors specified somewhere? i'd like to see it referenced in: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-campling-ech-deployment-considerations/__;!!Bt8RZUm9aw!_mzGaaZFnvwxN4QOGxmIc2AyuEoPGnSu43oxV_tTqWky9LWWsRLui4Ozhk1Boyxi5O2alFFKlw$ ...and i suggest simply referencing that advice in the draft under discussion. -- P Vixie
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org