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
