On Fri, May 1, 2020 at 4:43 PM Keith Moore <[email protected]> wrote:
> On 5/1/20 6:48 PM, Eric Rescorla wrote: > > On Thu, Apr 30, 2020 at 7:59 PM Keith Moore <[email protected]> > wrote: > >> People do not always have the luxury of upgrading their clients and >> servers to versions that support the recent TLS. Some legacy hardware >> has firmware that cannot be upgraded because no upgrades are >> available. Service providers do not always have the leverage to insist >> that their customers upgrade, or the luxury of abandoning customers. etc. >> > > Somewhat tangentially from the topic at hand: if you are running a piece > of hardware that cannot upgrade its TLS stack at all, you quite likely have > a number of serious unpatched vulnerabilities, and should reconsider > whether it is safe to have that hardware attached to the Internet. Of > course, you might be running some ESR software where you can only take > security releases, in which case this does not apply. > > Quite often the issue is not the hardware, but the lack of support. In my > experience, many appliances with IP interfaces have no long-term support to > fix security issues, because (for various reasons) there's no revenue > stream to support it, and there was never any plan to provide long-term > support. But the problem is even deeper than that - customers expect to > pay for the product up front and little if anything for ongoing support. > Even if the vendor wanted to sell the long term support contract there's > little chance that the customer would pay for it. (I'm thinking industrial > markets here, but consumer hardware often has similar issues.) > > (And sometimes the compilers, linkers, etc. needed to build a new version > of the device firmware are not easily found, and sometimes those tools > don't run on newer operating systems, so upgrading these platforms can be > much more complicated than just updating the source code and recompiling.) > Sure. I'm certainly aware of these issues. I'm merely observing that those people probably have bigger problems than modern systems not talking to them. I also think it's odd that there are recommendations like this that say >> "don't support TLS x.y" but say nothing about not supporting cleartext >> for protocols that still have a cleartext mode. Even SSL 1.0 is >> probably better than cleartext (at least from a security perspective, if >> not from a support burden perspective) as long as it's not trusted to be >> secure. >> > > While perhaps technically true, for the reasons above I believe this to be > irrelevant: TLS 1.2 is nearly 12 years old. At this point, any > implementation which does not support it should be presumed to be insecure > regardless of our opinion on the specific protocols it supports. > > I agree that such devices are likely insecure, but there are still devices > in service that only speak TLS 1.0 or 1.1. Are we going to insist that no > standards-conforming peer programs should be able to communicate with > them? > That is precisely what we do for SSLv2 and SSLv3, and is in fact what the TLS WG currently is proposing ( https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/) so I would advise you to keep your eye out for the IETF LC on a mailing list near you. -Ekr
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
