It might be better to describe TLS 1.2 as "overtaken by events". If you want to use CSS Grid or Swift UI (name any newish thing), you'll find yourself with a stack that supports TLS 1.3, so there's no need to bother with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea, because that traffic is composed of undesirable bots in many cases.
I know people also work on things that are old, but it seems ok to call them really old, because that is true. No one seems to disagree with this point in the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes most known deficiencies with TLS 1.2". If you think this draft is so strict that it will be ignored, you have nothing to worry about. thanks, Rob On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson <m...@lowentropy.net> wrote: > On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: > > That is not what the just-adopted draft says. It says that except for > > ALPN and exporters that no new registrations will be accepted for TLS > > 1.2 and that new entries should have a Note comment that says “for TLS > > 1.3 or later”. This is a change in the current policy. It has always > > said this; see page 3 of [1]. > > I should learn to read the IANA considerations. This current says: > > > IANA will stop accepting registrations for any TLS parameters [TLS13REG] > except for the following > > Aside from the fact that the wording also says that IANA will stop > accepting TLS 1.3 registrations too, I think that this is a very bad idea. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
