Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Ted Lemon <> Sat, 05 December 2020 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 99A4D3A07A0 for <>; Sat, 5 Dec 2020 08:40:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8h3N8cyxtEP4 for <>; Sat, 5 Dec 2020 08:40:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1C653A0773 for <>; Sat, 5 Dec 2020 08:40:51 -0800 (PST)
Received: by with SMTP id i199so8587272qke.5 for <>; Sat, 05 Dec 2020 08:40:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=g9i368ZV4iITe3qKpfV5JiRCeWjzrTZwgrtLdSGd0+8=; b=JoqmooUjPUnC3sLd+91owso93SRfkuNsycs4NEfLrRyefv8YLcxCR8kXmxQJX9HS9Z dX7EjUyZpdPh63+a6Mh5JsN6cGPLq/s6KPtsMLr1vX7/ojid4qHgF+cfo/u1cDDz25l2 qoNR8XXBiSqvFYfhj56ffzSI5jTNJVa6hwDDFNWp8wkDQW84n5mxtd+WKktm3jFR3F7c 44L6vk5GPRr77VPnAWczW6DZI46naIoFAZqapLsEpYzLzC2/oMifWllKYx0/E+46wLHU 4XRz9K3LZXWkgUJTOR8bWnC7PuuVVBmlUcCDSFMMi6DM4Y+jyx240d4qVx1wQ07Vg+WL 1o4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g9i368ZV4iITe3qKpfV5JiRCeWjzrTZwgrtLdSGd0+8=; b=i+F7VTVf/lizJ6N8KsnAuxlPYHndvA6Mv6GDb+QyiBkx5jgKP5rm2uv5OioNqRH9Qf Ok5QKke7yy2M/+SDeyqymo9Fw2LZ/hIjUY2oVQvcHJ+Zmw5oOAVfkzoeoQBad7Dr3Bnd i3bd6Lk0SVVQmPAlW8hM9WeRTuQK45yObsTHdJGfMn9MfgdTCfcdCXjrChn1Klq0O7bj R8SgdcP0F8qvTShFa1Mq6DyihPQTjkJot59LP8q+F5j0b4H5tEzUanlkLK5kLrtUKcWn yHVsTnd14ISJgsAA++PCa4IeUqTFIWQOEsNSSXayvv1pExPsJ9tQLEVAfBdgkooZYOTG YBlg==
X-Gm-Message-State: AOAM531LteORvQiSnHVH76rHyy+COu4FFRpGUzkmbULSRbwgPsc9C5mu NL/1OsmwcE9+GPHY2va3NFTBaQ==
X-Google-Smtp-Source: ABdhPJxMJ33EaX1sPuvEV10JddnA13RZ/Y2h9AoOfpiopqSzirYNMOkugSCEnARIIYOKMpAe9ps9nA==
X-Received: by 2002:a37:9b05:: with SMTP id d5mr15572120qke.49.1607186450857; Sat, 05 Dec 2020 08:40:50 -0800 (PST)
Received: from mithrandir.lan ( []) by with ESMTPSA id c10sm8085963qkm.71.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 08:40:49 -0800 (PST)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Sat, 05 Dec 2020 11:40:48 -0500
In-Reply-To: <>
Cc: "Ackermann, Michael" <>,, Randy Bush <>,
To: Eliot Lear <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Dec 2020 16:40:55 -0000

I think we are mostly in violent agreement, Eliot, except that I think we (society, not the IETF necessarily) need an architecture for how to deal with the problems you’ve described. If we continue to sweep them under the carpet, we’re going to continue to see ransomware taking over hospitals and resulting in patient deaths or other adverse outcomes, loss of privacy in large enterprises, the continued ongoing data breaches that we see. Addressing the problems you’ve described won’t completely solve those problems, but it’s a necessary part of solving them.

I don’t think there’s a way to do this on a voluntary basis—it requires regulation, or there will always be an incentive not to do it, as you have so eloquently outlined.

> On Dec 5, 2020, at 4:57 AM, Eliot Lear <> wrote:
> [moving to iotops and arch-discuss, as we are now leaving the topic of LC]
> Ted,
> I’m going to pick on you a bit here, but just to call out a larger point, because… we are almost nowhere on this problem.
>> On 4 Dec 2020, at 23:47, Ted Lemon < <>> wrote:
>> Why do people buy stuff that’s not upgradeable? Probably because the manufacturer doesn’t give them a choice, and there’s no way to force the choice. The recent discussions about legally requiring firmware-upgradeable IoT devices (e.g. in Singapore) is definitely a step in the right direction. For medical devices and medical infrastructure, this should have been required, but as far as I know still is not.
> That premise is a bit too sweeping. Stuff doesn’t get upgraded for a myriad of reasons.  One is that stuff gets old.  Every manufacturer has this problem.  Cisco hardware is built to last, and it is not surprising to find equipment in the secondary market that is 15-20 years old.  If you look at a workhorse like a 7200 router that they (I wasn’t at Cisco yet) introduced in 1996, stopped selling in 2012, and only last year stopped issuing software patches for, you can still find equipment on the secondary market.  “Works like new”, $1,200 plus shipping[1].   In that span of time, just how many iPhones and Android systems have come and gone?*  What sort of eWaste problem has been created?  How long should DLink provide security updates for that frisbee that connects you to the world?  5 years? 10 years? 15 years?  Singapore didn’t answer that question, as I understand it.
> And that’s in the IT market.  Now go look at the thermostat in your house.  How old is it?  In most cases, it dates back to when a house was built.  That’s the sign of a good product.  In some cases, the manufacturer may have gone out of business.    How long should an auto manufacturer support a car?  I will tell you that in general it is less than the length of time we support a router, and in some cases far less.  There are manufacturing presses that date back to the first use of electricity.  You think we have problems now?  Just wait a few years.  
> And then there is when and how to perform upgrades.  Apple along with a great many consumer providers has it easy when it comes to device upgrades: they can force the requirement that upgrades occur over the Internet, and that the device be rebooted.  Now try that with a transformer providing power to a hospital or a controller for an oil derrick in Alaska, where the duty cycle of a device can easily be 40 years, and the maintenance window is… oh wait.  There isn’t one.  Clearly these devices need to support in service upgrades, but even those have to be carefully thought out, tested, and planned.  And if something goes wrong, well...
> My point isn’t that these upgrades shouldn’t occur.  But we do need to think differently about the whole life cycle of a system.  I’m far from the first to talk about this, nor is this insight particularly recent.  Dan Geer wrote as far back as 2012 about creating Internet kill switches[2,3].  Nor is this problem related only to security.  I’ve already mentioned the tension between security and eWaste. Cloud computing offers tremendous efficiencies, both economic and environmental, by shifting intelligence from dedicating computing to shared.  But think about what just happened this year: a number of manufacturers who use the cloud failed.  What happened to their products?  And of course Cloud computing by definition assumes Internet access, which the OT world is only beginning to allow.  After Amazon’s and Microsoft’s outages over the last several months, they may be a bit less interested.
> Boiling this down, it seems to me IOT lifecycle, support models, and security models, including software ownership, open source, associated complexities, is a worthy topic to be picked up and discussed in iotops, given the life spans of some of these devices.
> In answer to your direct question: yes we should be deprecating broken protocols faster than we have been.  The LC in question should have occurred at least five years ago, and it will more than justify the challenge it will give the RPC when they go to create the Updates: header ;-)
> Eliot
> * And don’t even get me started on Android and the vast technical deficit it and manufacturers created.  The absolutely naive and self-serving argument that only the h/w manufacturers are responsible for that mess demonstrates the limits of OSS.
> [1] <>
> [2] <>
> [3] <>