FWIW, my plan for the draft (which I hope to submit for adoption within a month) is to include text that says, basically, while no new features will be ADDED to TLS 1.2, the WG may decide to deprecate or remove things that have become security risks. I think it's better to keep specifics in separate documents; ideally this one can be read, understood, and appreciated by those not steeped in the gory technical details.
On 3/31/23, 8:59 AM, "Martin Thomson" <m...@lowentropy.net <mailto:m...@lowentropy.net>> wrote: Just a thought, but in the discussion of TLS 1.2, we might start to consider the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated sooner. RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so maybe requiring it (or not supporting TLS 1.2 if that cannot be negotiated) offers a short term step toward eventual deprecation, while allowing those who find themselves stuck on TLS 1.2 more time to adjust. _______________________________________________ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!UNB0h17Crh0iXqtbjQkhlf5180NWCg6SrAVjadF2H-Era8IqokFYAERHtHrNs3kfu9iwp7h9kw$ <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!UNB0h17Crh0iXqtbjQkhlf5180NWCg6SrAVjadF2H-Era8IqokFYAERHtHrNs3kfu9iwp7h9kw$> _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
