Re: [Uta] Any thoughts on draft-rsalz-uta-require-tls13 ?

[John Mattsson <[e-mail]>]

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 <[e-mail]> on behalf of Orie Steele <[e-mail]>
Date: Thursday, 7 December 2023 at 03:01
To: Salz, Rich <rsalz=[e-mail]>
Cc: [e-mail] <[e-mail]>
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=[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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>