On Tue, Dec 12, 2023 at 1:09 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> are > you saying you don't believe that there are systems out there deployed and > used with multi-decade life cycles? I believe that--but these are so old that the other parts are starting to become a problem. In my case, the ethernet stack is a bit obsolete, and needs special treatment. That said, the draft doesn't deny the existence of TLS 1.2 on old hardware. It says: "Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. This document specifies that outside of urgent security fixes, no new features will be approved for TLS 1.2." So, this document makes it clear that the 15yr-old TLS 1.2 RFC is not going to be getting new features. This is already true, really. For example, ECH requires TLS 1.3+, and there's a lot of QUIC traffic out there (RFC 9001: "Clients MUST NOT offer TLS versions older than 1.3."). I can't see why anyone aiming for multi-decade deployments would start with TLS 1.2 today. I have been dismayed to see WGs like UTA and NETCONF list TLS 1.2 as a MUST in 2023. I can understand that people might /choose/ to support it, where there's a bunch of older hardware around. But as a conformance requirement, or as a target for feature work, it doesn't make sense to me. It's starting to resemble Homer's sandwich: <https://imgur.com/gallery/qBJdFMQ> The draft is a good idea, because it makes what is already happening clear. But it seems like not every WG is getting the memo (even if they don't like it). The conversation basically goes "why is TLS 1.2 a MUST?" and the answer is "allowing 1.3-only implementations would be controversial" without really explaining what that controversy might be. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
