Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

[Keith Moore <[e-mail]>]

On 5/1/20 6:48 PM, Eric Rescorla wrote:

> On Thu, Apr 30, 2020 at 7:59 PM Keith Moore 
> <[e-mail] <mailto:[e-mail]>> 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.)

>
>     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?   (I fully agree that new standards-conforming 
peer programs should not label such connections as "secure")

Keith