[arch-d] 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

Eliot Lear <lear@cisco.com> Sat, 05 December 2020 09:57 UTC

Return-Path: <lear@cisco.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD093A10D2 for <architecture-discuss@ietfa.amsl.com>; Sat, 5 Dec 2020 01:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rg_ipfzTi5gP for <architecture-discuss@ietfa.amsl.com>; Sat, 5 Dec 2020 01:57:50 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B873A10D3 for <architecture-discuss@iab.org>; Sat, 5 Dec 2020 01:57:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14138; q=dns/txt; s=iport; t=1607162270; x=1608371870; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=UsjGuPUZIx3MQTT+G81BxoWw43Xpx5x05uT7TDHciMo=; b=PLaDFju9yDHAZLwmbHyvNmfArOEwNjYorFbETjxPc7QdSNhd8zQUBP5o +jEawX0B+NdQAzXFtZdLIvrCA07JzqouFDB0oJniuU7x7xyLKfWcSaPWT +Z0q/L4uc7AFz58vRQmNDqBagryGdMBof288C3533Ew1EQB7udY1wl5sB M=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0ClAACzWMtflxbLJq1iAwoNAQEBAQEBAQEBAQMBAQEBE?= =?us-ascii?q?gEBAQECAgEBAQGCD4EjgXxXASASLoQ8iQSHfyUDh2qMLYgbBAcBAQEKAwEBI?= =?us-ascii?q?wwEAQGBVYF2AX4CghYmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBA?= =?us-ascii?q?YY2DIVyAQEDAQEjVgULGQojBAMCAkYRBhMZgw0BgmYgD6lsgjx2gTKEPgEUQ?= =?us-ascii?q?IVUCgaBOIFTjAmCAIE4DBCBV1Bsgl0BAgEXfSsPRYJhM4IsBIFzBVtFDwEnG?= =?us-ascii?q?xATVB0LCSkVBAcfAiYSATKPIBESCot0gW2aKIJ+BIMdgTeERIt2hioDH5Jxj?= =?us-ascii?q?zuee5EdgQyDbAIEBgUCFYFtIYFZMxoIGxVlAYI+PhIZDY47HYM6hRSFRUADM?= =?us-ascii?q?AIILQIGAQkBAQMJijSCRAEB?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,395,1599523200"; d="asc'?scan'208,217";a="31662969"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Dec 2020 09:57:45 +0000
Received: from [10.61.247.173] ([10.61.247.173]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B59viio023153 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Dec 2020 09:57:45 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Eliot Lear <lear@cisco.com>
In-Reply-To: <77363965-99A5-4790-B40B-011827C8D113@fugue.com>
Date: Sat, 5 Dec 2020 10:57:44 +0100
Cc: "Ackermann, Michael" <MAckermann@bcbsm.com>, iotops@ietf.org, Randy Bush <randy@psg.com>, architecture-discuss@iab.org
Message-Id: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <SN6PR02MB4512B95842251AE4C04B199CC3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <BYAPR14MB31765FD24F4DFD90F81AEE2BD7F30@BYAPR14MB3176.namprd14.prod.outlook.com> <SN6PR02MB4512CBA9E4BF6AAC778BC674C3F30@SN6PR02MB4512.namprd02.prod.outlook.com> <DM6PR14MB31789349B737961728B7691ED7F30@DM6PR14MB3178.namprd14.prod.outlook.com> <CACsn0ckvoqZ5-JPRkOXp2Mw2zeTOdyCYLvX1NV1waJ-yidTwMQ@mail.gmail.com> <SN6PR02MB45129E647485BA5794D5CF4EC3F20@SN6PR02MB4512.namprd02.prod.outlook.com> <MWHPR02MB2464CD5D5B7568E9EAC58B26D6F20@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178EC0521427BF7C3523CACD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <CAChr6SzvQK+exfgYEwfVNknMjr-Y-UJ4A7k0DkOkL9wmLQ84aQ@mail.gmail.com> <MWHPR02MB246499F35613820D45EB55AAD6F10@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178A0C152A746E41C6A01C6D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <f8486514-9726-68d0-2bc8-dccd4293017e@cs.tcd.ie> <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <DM6PR14MB317817FD62369A8E0FF93CA8D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Outbound-SMTP-Client: 10.61.247.173, [10.61.247.173]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/D6ZB2n6Yc4p4GFfH1338AYFDwrk>
Subject: [arch-d] 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-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2020 09:57:53 -0000

[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 <mellon@fugue.com <mailto:mellon@fugue.com>> 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] https://www.ebay.com/p/54829831 <https://www.ebay.com/p/54829831>
[2] https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf <https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf>
[3] https://queue.acm.org/detail.cfm?id=2479677 <https://queue.acm.org/detail.cfm?id=2479677>