On Fri, Jan 19, 2024 at 10:29:27PM +0100, Jo Durchholz wrote:
Thing is, you are doing analysis to argue that your usage is safe enough. Which is exactly the kind of overhead you'll have to do whenever the security landscape changes.
My use case is basically opportunistic TLS in SMTP, which is typically unauthenticated, and best-effort (also DoT to auth in DNS). TLS 1.0 is better than cleartext. I am also operating a broad deployment survey, and the survey needs to be able to connect with whatever the other end supports. Security against active attacks is irrelevant. I am not suggesting that anyone should stick with TLS 1.0, though it is in practice "good enough" in some applications. Its deployment numbers are substantially lower and falling. I was just asking that TLS 1.0 continue to be available when explicitly requested, rather than removed.
Also, it would likely be a good idea to add some push towards 1.2. If entire ecosystems still stick with 1.x, they're rotten. I know that some ecosystems just are that way; the best we can do is to add some small push towards a better policy, and it's the least we *should* do.
The push has already happened, TLS 1.3 is widely available and is negotiated by default when supported by both ends. The negotation is downgrade-resistant. It is addition of TLS 1.3 support, not removal of TLS 1.0 support that has the biggest impact on improved security. There are however still some pockets of devices and systems, and it is a judgement call as to when it is appropriate to cut off interoperability with those systems. Yes, it could be now, but a case can be made that this does not improve security, though it does perhaps reduce support effort if there is still a real support burden in keeping the TLS 1.0 code working. -- Viktor.