On Wed, 24 Jul 2024 at 02:29, Ben Schwartz <bemasc=40meta....@dmarc.ietf.org>
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.
>
Yes. In addition, TLS 1.2 would reveal the device (or user) identity to
eavesdroppers and is not a viable option.
-Tiru
>
> --Ben Schwartz
> ------------------------------
> *From:* Paul Vixie <p...@redbarn.org>
> *Sent:* Tuesday, July 23, 2024 4:01 PM
> *To:* Paul Wouters <p...@nohats.ca>
> *Cc:* Tommy Jensen <jensen.tho...@microsoft.com>; Ben Schwartz <
> bem...@meta.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
>
>
>
>
> --
> P Vixie
>
> On Tuesday, July 23, 2024 12:52:28 PM PDT Paul Wouters wrote:
> > On Jul 23, 2024, at 12:09, Paul Vixie <paul=40redbarn....@dmarc.ietf.org>
>
> wrote:
> > > Making TLS 1.2 available as a fallback is vital. Many secure private
> edge
> > > networks will never allow TLS 1.3 because of ECH.
> >
> > You can do TLS 1.3 without ECH ?
>
> if an endpoint wants TLS 1.3 with ECH, there's no way to negotiate them
> down
> to TLS 1.3 without ECH. there is a way to negotiate them down to TLS 1.2.
>
> > Making a weaker version of TLS mandatory would be unwise, unless it’s to
> > give more time for migration away from it.
>
> migration for military, government, and many corporate networks can't
> happen.
> for reasons of law, regulation, or policy, they must see the client hello
> before they can decide whether to block the flow. "just secure your
> devices"
> can't work due to the way the supply chain works. the only alternative
> will be
> to block outbound entirely and force all traffic through a
> non-intercepting
> proxy.
>
> ietf knew this, but RFC 8890 forbade us to consider it. i was a dissenter.
> the
> fact that you refer to TLS 1.2 as "weaker" may indicate a preference that
> we
> mandate a technology that often _cannot_ be used even those the
> alternative
> ("effective mandate") will be a technology (explicit proxy) which is in
> fact
> weaker than TLS 1.2. we should not argue from talking points.
>
> don't put it in terms of migration. just recommend that fallback be
> allowed.
> 50 years from now, smarter people than us can think of a better way
> forward.
> as things are today, secure private edge networks including military,
> government, and many commercial networks, will not allow TLS 1.3 to be
> used.
>
> paul
>
>
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
>
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
