Hi,

I think this should be published asap. A BCP would be even better.

IETF is as usual late:
- NIST requires support TLS 1.3 since 1 Jan 2024. Not just in new deployments 
but everywhere.
- 3GPP requires TLS 1.3 everywhere in the core network since the first 5G 
specification (Rel-15, 2018).

- "New Protocols"
I think this should be "new RFCs". Publishing bis versions of old protocols 
should also require TLS 1.3.

- "TLS 1.2 is in widespread use and can be configured such that it provides 
good security properties."

This is correct but gives the wrong picture of existing deployments. It is not 
uncommon with very badly configured and unsecure TLS 1.2.

- "While application layer traffic is always encrypted"

Not uncommon that TLS 1.2 deployments supports NULL encryption.

- "This deficiency may be addressed through proper configuration"

Only if you have a modern TLS 1.2 implementation. An old TLS 1.2 implementation 
cannot be configured to be secure as it lacks AEAD, extended master secret, and 
might lack ECDHE, etc.

- "Rather, some extensions are required to provide security."

Also cipher suites with ECDHE and AEAD.

Cheers,
John Preuß Mattsson

From: Uta <uta-boun...@ietf.org> on behalf of Orie Steele 
<orie@transmute.industries>
Date: Thursday, 7 December 2023 at 03:01
To: Salz, Rich <rsalz=40akamai....@dmarc.ietf.org>
Cc: uta@ietf.org <uta@ietf.org>
Subject: Re: [Uta] Any thoughts on draft-rsalz-uta-require-tls13 ?
(chair hat off)

I read the draft, it looks good to me.

OS

On Wed, Dec 6, 2023 at 10:21 AM Salz, Rich 
<rsalz=40akamai....@dmarc.ietf.org<mailto:40akamai....@dmarc.ietf.org>> wrote:
The draft is at https://datatracker.ietf.org/doc/draft-rsalz-uta-require-tls13/ 
and it’s maintained on GitHub at 
https://github.com/richsalz/tls12-frozen<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e5e4ba8e3be0422f&q=1&e=88a0ecda-2aaf-4740-a49a-66e650c06005&u=https%3A%2F%2Fgithub.com%2Frichsalz%2Ftls12-frozen>
  There are two documents in that repo.

The draft updates RFC 9325 in the following way:
Any new protocol that uses TLS MUST specify as its default TLS 1.3 (or a higher 
TLS version, when one becomes stadardized). For example, QUIC 
[QUICTLS<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4172a38ca4bb7e3b&q=1&e=88a0ecda-2aaf-4740-a49a-66e650c06005&u=https%3A%2F%2Frichsalz.github.io%2Ftls12-frozen%2Fdraft-rsalz-uta-require-tls13.html%23QUICTLS>]
 requires TLS 1.3 and specifies that endpoints MUST terminate the connection if 
an older version is used.

If deployment considerations are a concern, the protocol MAY specify TLS 1.2 as 
an additional, non-default option. As a counter example, the Usage Profile for 
DNS over TLS 
[DNSTLS<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-731d02a3479eb30f&q=1&e=88a0ecda-2aaf-4740-a49a-66e650c06005&u=https%3A%2F%2Frichsalz.github.io%2Ftls12-frozen%2Fdraft-rsalz-uta-require-tls13.html%23DNSTLS>]
 specifies TLS 1.2 as the default, while also allowing TLS 1.3. For newer 
specifications that choose to support TLS 1.2, those preferences are to be 
reversed.

One motivation is that TLS is in a call for adoption of a “TLS 1.2 is frozen” 
draft which specifies that no new features, in particular *post-quantum crypto* 
will not be added to TLS 1.2. As PQC is now a hot topic, it might be worth 
firming up the advice to applications.

_______________________________________________
Uta mailing list
Uta@ietf.org<mailto:Uta@ietf.org>
https://www.ietf.org/mailman/listinfo/uta


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a7ff2eb208872658&q=1&e=88a0ecda-2aaf-4740-a49a-66e650c06005&u=http%3A%2F%2Fwww.transmute.industries%2F>

[Image removed by 
sender.]<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-833883293856debb&q=1&e=88a0ecda-2aaf-4740-a49a-66e650c06005&u=https%3A%2F%2Ftransmute.industries%2F>
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to