[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[tirumal reddy <[e-mail]>]

On Wed, 24 Jul 2024 at 02:29, Ben Schwartz <bemasc=[e-mail]>
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 <[e-mail]>
> *Sent:* Tuesday, July 23, 2024 4:01 PM
> *To:* Paul Wouters <[e-mail]>
> *Cc:* Tommy Jensen <[e-mail]>; Ben Schwartz <
> [e-mail]>; dnsop <[e-mail]>; Damick, Jeffrey <
> [e-mail]>; Engskow, Matt <[e-mail]>; Jessica
> Krynitsky <[e-mail]>
> *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=[e-mail]>
>
> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>