[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Nick Harper <[e-mail]>]

I understand the stated goal of this draft to be to provide a way for
hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
a document that describes how to safely deploy TLS 1.2 sounds like a good
idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
draft is not that.

This draft makes changes to the TLS handshake protocol, which undermines
the goal of supporting hard-to-update endpoints. The two changes made to
the protocol are also addressed by RFC 8446. If endpoints need to be
updated to support TLS-LTS, it would make more sense to update them to
support TLS 1.3 than TLS-LTS.

The rationale section (3.7) of the draft presents two reasons for using
TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new
protocol. LTS requires a change to the protocol and deployment of that new
change, no different from 1.3. The second reason is fear of the unknown in
1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back
the 20 years of experience that we have with all the things that can go
wrong in TLS". The 20 years of all the things that can go wrong in TLS were
due to unsound cryptographic decisions. The research and analysis that
found those 20 years of issues was applied to the design of 1.3 to avoid
making the same mistakes. 1.3 doesn't roll back that experience, and we now
have over 8 years of experience with 1.3.

I do not support adoption of the draft in this format. If the draft made no
changes to the TLS 1.2 protocol and were deployable only through
configuration changes (e.g. a fixed list of cipher suites and extensions),
I would probably support it.

On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich <rsalz=
[e-mail]> wrote:

> I strongly support adoption.
>
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be bothered
> by the impliciation that *THIS ONE WAY* is the only way to get long-term
> support, especially if it's seen to contradict our encouragement of TLS
> 1.3. But that is an editorial issue that can be easily fixed.
>
> I would like to see this adopted, a short change cycle, and then advanced
> in the same cluster with our TLS 1.2 is frozen document.
>
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>