From nobody Wed Dec 2 02:30:43 2020 Return-Path: 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 6296B3A12AE for ; Wed, 2 Dec 2020 02:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uEGM5MeynTYc for ; Wed, 2 Dec 2020 02:30:39 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9AA3A12AB for ; Wed, 2 Dec 2020 02:30:38 -0800 (PST) Received: from p200300dee74a38008deb27ef8c3c6d95.dip0.t-ipconnect.de ([2003:de:e74a:3800:8deb:27ef:8c3c:6d95]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kkPP9-000834-JA; Wed, 02 Dec 2020 11:30:35 +0100 From: Mirja Kuehlewind Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Wed, 2 Dec 2020 11:30:34 +0100 Cc: Wes Hardaker To: architecture-discuss@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1606905039;6a8d037b; X-HE-SMSGID: 1kkPP9-000834-JA Archived-At: Subject: [arch-d] IABopen minutes from IETF-109 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 10:30:41 -0000 Hi all, We have uploaded the minutes for the IABopen session at IETF-109 two = weeks ago. Thanks Cindy for taking them! = https://datatracker.ietf.org/meeting/109/materials/minutes-109-iabopen-01 Please let me know if there are any edits or corrections needed! Also feel free to reach out to me or the rest of the IAB if you have any = further questions about any of the topics discussed! See you next time! Mirja From nobody Sat Dec 5 01:57:58 2020 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: <77363965-99A5-4790-B40B-011827C8D113@fugue.com> Date: Sat, 5 Dec 2020 10:57:44 +0100 Cc: "Ackermann, Michael" , iotops@ietf.org, Randy Bush , architecture-discuss@iab.org Message-Id: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> To: Ted Lemon 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: Subject: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 09:57:53 -0000 --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F Content-Type: multipart/alternative; boundary="Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B" --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [moving to iotops and arch-discuss, as we are now leaving the topic of = LC] Ted, I=E2=80=99m going to pick on you a bit here, but just to call out a = larger point, because=E2=80=A6 we are almost nowhere on this problem. > On 4 Dec 2020, at 23:47, Ted Lemon > wrote: >=20 > Why do people buy stuff that=E2=80=99s not upgradeable? Probably = because the manufacturer doesn=E2=80=99t give them a choice, and = there=E2=80=99s 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=E2=80=99t 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=E2=80=99t 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. =E2=80=9CWorks like = new=E2=80=9D, $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=E2=80=99t answer that question, as I = understand it. And that=E2=80=99s 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=E2=80=99s 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=E2=80=A6 oh wait. There isn=E2=80=99= 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=E2=80=99t that these upgrades shouldn=E2=80=99t occur. But = we do need to think differently about the whole life cycle of a system. = I=E2=80=99m 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=E2=80=99ve 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=E2=80=99s and Microsoft=E2=80=99s 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=E2=80=99t 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 [2] = https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf = [3] https://queue.acm.org/detail.cfm?id=3D2479677 = --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[moving to iotops and arch-discuss, as we are = now leaving the topic of LC]

Ted,

I=E2=80=99m going to pick on you a bit = here, but just to call out a larger point, because=E2=80=A6 we are = almost nowhere on this problem.

On 4 Dec 2020, at 23:47, Ted Lemon <mellon@fugue.com> = wrote:

Why do people buy stuff that=E2=80= =99s not upgradeable? Probably because the manufacturer doesn=E2=80=99t = give them a choice, and there=E2=80=99s 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=E2=80=99t 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=E2=80=99t 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. =  =E2=80=9CWorks like new=E2=80=9D, $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=E2=80=99t answer that question, as I understand = it.

And = that=E2=80=99s 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=E2=80=99s 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=E2=80=A6 oh wait.  There = isn=E2=80=99t 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=E2=80=99t that these upgrades shouldn=E2=80=99t occur. =  But we do need to think differently about the whole life cycle of = a system.  I=E2=80=99m 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=E2=80=99ve 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=E2=80=99s and = Microsoft=E2=80=99s 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=E2=80=99t 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
[2] https://www.usenix.org/system/files/login/articles/geeronlineon= ly.pdf
[3] https://queue.acm.org/detail.cfm?id=3D2479677


= --Apple-Mail=_9EE5CE96-5C51-460E-A4BD-CCD050674E3B-- --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/LWZgACgkQh7ZrRtnS ejOy9ggArag43y9RCgO2m3j9AlIn7CsO47Pjjn7GY+iZqOnElz4G0No8tH6XoOw3 l8YHcwkPdgyfePlgzwbCy8NHGuZEf3MX6WBWhQohYSqT38946YAgqkMLl6GMg4C+ C4uhMa+n42dbEC5hNOqtV+E/XEXq/TjeUhFUHCDpq2+q06nOdYHiXtyyaa7eR0et Yb2AS4eyzxdNGWuQ5gQ6+j4WIQzeN5m4bfoQ6a4WAPoGm+TGnD8IEk/Yth+i3LhJ Xku/IvlMK4ewhD94pQODN36M1v5sORRy90FgL5xArhM9/o3DhSNP1yYhVtoAAjE3 mCUv2hbEFtRMuJMDLhJTFXgwwbhMuQ== =Bopg -----END PGP SIGNATURE----- --Apple-Mail=_D11D0F56-6FED-4FDC-ABA7-8AB9EA76B92F-- From nobody Sat Dec 5 08:41:00 2020 Return-Path: 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 E42EE3A0773 for ; Sat, 5 Dec 2020 08:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 ICJ_TDktU2dj for ; Sat, 5 Dec 2020 08:40:52 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 301603A0799 for ; Sat, 5 Dec 2020 08:40:51 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id q22so8579595qkq.6 for ; Sat, 05 Dec 2020 08:40:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=g9i368ZV4iITe3qKpfV5JiRCeWjzrTZwgrtLdSGd0+8=; b=d53MV80pCwcBcWvTh2kmQjcjA5Bm2u5Q0TZDxlzMMd9a+2uF6FfRdDDnDJAOT3TRgK XnjSI4CubOE6A8kVBZ/CxVNMrAQIxHO2X8EMCmFmk+xT0LPMqV6dDCRCCMynYuZgwEiF XQoQaOscjL7WxQCXT/BR9BjMiN17nKQrEfeIyCOBrNZNt/aM1eRw8cZmOtnge88XI0Q8 rrvjhrIEpHdqMFkOPmYVZ3yCwzXDGZ4EzesTUwtCfxHlLwLIYB5CGaPChN0g5I3wKD+z c2swt8LTmcUnLv8QxQXcR5pMkNqn/Vn2RKrkKuxj+WJpsGJiW6hLOekmj42+Ex4C2ePp Sgbw== X-Gm-Message-State: AOAM53337lt6dK7HZ5OO4mMPzotZoMFLER2JO719iRTbxhxo/LsC33S2 ji9MM3K4FUiQGPyGFsnfp3SVBA== 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 (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c10sm8085963qkm.71.2020.12.05.08.40.49 (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: <5379569B-FEC5-4AEB-BEB6-C959114ABCCB@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sat, 5 Dec 2020 11:40:48 -0500 In-Reply-To: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> Cc: "Ackermann, Michael" , iotops@ietf.org, Randy Bush , architecture-discuss@iab.org To: Eliot Lear References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 16:40:55 -0000 --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99ve described. If we continue to sweep = them under the carpet, we=E2=80=99re 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=E2=80=99ve = described won=E2=80=99t completely solve those problems, but it=E2=80=99s = a necessary part of solving them. I don=E2=80=99t think there=E2=80=99s a way to do this on a voluntary = basis=E2=80=94it 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: >=20 > [moving to iotops and arch-discuss, as we are now leaving the topic of = LC] >=20 > Ted, >=20 > I=E2=80=99m going to pick on you a bit here, but just to call out a = larger point, because=E2=80=A6 we are almost nowhere on this problem. >=20 >> On 4 Dec 2020, at 23:47, Ted Lemon > wrote: >>=20 >> Why do people buy stuff that=E2=80=99s not upgradeable? Probably = because the manufacturer doesn=E2=80=99t give them a choice, and = there=E2=80=99s 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. >=20 >=20 > That premise is a bit too sweeping. Stuff doesn=E2=80=99t 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=E2=80=99t 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. =E2=80=9CWorks like = new=E2=80=9D, $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=E2=80=99t answer that question, as I = understand it. >=20 > And that=E2=80=99s 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=E2=80=99s 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. =20 >=20 > 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=E2=80=A6 oh wait. There isn=E2=80=99= 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... >=20 > My point isn=E2=80=99t that these upgrades shouldn=E2=80=99t occur. = But we do need to think differently about the whole life cycle of a = system. I=E2=80=99m 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=E2=80=99ve 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=E2=80=99s and Microsoft=E2=80=99s outages over the last several = months, they may be a bit less interested. >=20 > 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. >=20 > 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 ;-) >=20 > Eliot >=20 > * And don=E2=80=99t 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. >=20 > [1] https://www.ebay.com/p/54829831 > [2] = https://www.usenix.org/system/files/login/articles/geeronlineonly.pdf = > [3] https://queue.acm.org/detail.cfm?id=3D2479677 = >=20 >=20 --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99ve described. If we continue to sweep them = under the carpet, we=E2=80=99re 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=E2=80=99ve = described won=E2=80=99t completely solve those problems, but it=E2=80=99s = a necessary part of solving them.

I don=E2=80=99t think there=E2=80=99s a way to do this on a = voluntary basis=E2=80=94it 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 <lear@cisco.com> = wrote:

[moving to iotops and arch-discuss, as we are = now leaving the topic of LC]

Ted,

I=E2=80=99m going to pick on you a bit = here, but just to call out a larger point, because=E2=80=A6 we are = almost nowhere on this problem.

On 4 Dec 2020, at 23:47, Ted Lemon <mellon@fugue.com> = wrote:

Why do people buy stuff that=E2=80= =99s not upgradeable? Probably because the manufacturer doesn=E2=80=99t = give them a choice, and there=E2=80=99s 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=E2=80=99t 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=E2=80=99t 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. =  =E2=80=9CWorks like new=E2=80=9D, $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=E2=80=99t answer that question, as I understand = it.

And = that=E2=80=99s 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=E2=80=99s 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=E2=80=A6 oh wait.  There = isn=E2=80=99t 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=E2=80=99t that these upgrades shouldn=E2=80=99t occur. =  But we do need to think differently about the whole life cycle of = a system.  I=E2=80=99m 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=E2=80=99ve 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=E2=80=99s and = Microsoft=E2=80=99s 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=E2=80=99t 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
[2] https://www.usenix.org/system/files/login/articles/geeronlineon= ly.pdf
[3] https://queue.acm.org/detail.cfm?id=3D2479677



= --Apple-Mail=_9F38B339-8369-4601-A1D2-627505FA435D-- From nobody Sat Dec 5 10:10:10 2020 Return-Path: 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 732FC3A0AA0; Sat, 5 Dec 2020 10:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cxWi-IXpNK4i; Sat, 5 Dec 2020 10:10:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8E73A0A9C; Sat, 5 Dec 2020 10:10:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klc0P-0005sV-QS; Sat, 05 Dec 2020 18:10:01 +0000 Date: Sat, 05 Dec 2020 10:10:01 -0800 Message-ID: From: Randy Bush To: Eliot Lear Cc: Ted Lemon , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:10:09 -0000 [ where are we going and why am i in this handbasket? ] < rant > when you have a plant which can turn out a jillion new thingies with a day of set-up, the costs of the infrastructure to securely maintain and upgrade them in the field for three, let alone 20, years is astronomical in comparison. now multiply that by a new and different thingie being manufactured next month. now multiply that by a few hundred manufacturers. perhaps the only way to understand in one's gut the scale of this problem is to spend a few weeks in shenzhen. to improve the math one would have to amortize the cost of maintenance over many many flavors and makers of thingies. so the acme thingie mfr, and the hackme thingie mfr, and the ... need to have a common code base and upgrade infrastructure. this is seen as stifling innovation in a highly innovative and competitive space. the time from first pitch to vc term sheet and funding has gone down to two weeks. and the resulting landfill rivals the problem of plastics in the oceans. android is the only example i can think of with a multi-manufacturer upgrade and maintenance infrastructure; and it is notoriously horrid. researchers publish papers on how bad it is. but credit to android for trying. long way to go. alternatively, one could be in a regulated environment, e.g. military, medical, etc., where multiplying the cost of the thingie by orders of magnitude is seen as worth the social benefit. but, even in these environments, do not underestimate the attack surface due to sloppy ops. we, for some value of we, are used building a reliable network from unreliable components. distributed protocols are the key. that is a different universe from a reliable and long-term maintainable thingie. and maybe we don't want to use our favorite vendors' boat anchors as examples. randy, who still has a curta and a k&e log log duplex decitrig From nobody Sat Dec 5 10:19:33 2020 Return-Path: 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 9FE0D3A0AD0 for ; Sat, 5 Dec 2020 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 1FBQcw8A_pko for ; Sat, 5 Dec 2020 10:19:25 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD9D3A0AD3 for ; Sat, 5 Dec 2020 10:19:25 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id b144so8690615qkc.13 for ; Sat, 05 Dec 2020 10:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=YzOMFY6cGb56d2/yZEgQQyMbqX3eU3+szMfAfAMVGOc=; b=JmveM3Vs64ZBqYA7oZpn7KZTpN2M7QDCriryROKEdSw82KCs3xdGRqnKxnEu4HhLgP JCL+9+MFVwuVU+giL7INp3cXPiTvx4ZWvlt9YoLsJRpHc22AaQLjb53rBYpm1FVxTTDM clrfEiTgAkoZqYlASKdok5N6a3Q4zZEvHhRBdptXm7VX6/zoj7IKX/D3z9RPk4TaxL7y MJaaatDc1tOobX68DpcNkMv6QeL+qe6ZpDDl62ReczcvslKHAMIh08fJKvd96MISKBnr +NQi6eci5Wn90+Cf/6TKbUA6H+Nrapw16TVdMOuFSXVvDfMv1zreR1Tcx5EhGLqQmkb/ bZ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=YzOMFY6cGb56d2/yZEgQQyMbqX3eU3+szMfAfAMVGOc=; b=oMOYg4fAyrmXHZeHHSulsAF6c7OOWXAhbJ+QLvkRZ4xWCndCAqeMOdSc59gZF0+ZhD n/UHdmJH13t5gZ3RIP3/vjN9T8IGes/+BcC94GDgO+509kuU+PaA+k0MjFIVkvcNg9/M /mFAReCtg6nlRhC1hD77Trr33HjAIb/3Ivi867EQtHMOLKaIUH99uA7+l5AOgoYY9UnR bnbtGIfGb7cZsSPOF0ml+zbYd81LBvGAp0702oNdtUsuCA+VlV2HCsTYxUTQGcy5M5jF SnUbROcKgGGZJIH9k47n4b5GsC07UDI0zDnj6NBXXj/YXlfgF46H7ENhMrQEQgHckTm5 WEpw== X-Gm-Message-State: AOAM5326xNskSafWEyQKksZe8GEBJSA1BWgwoMLOwrVtnB1Z4Z9DP+9R NeKm+I62HBu4z9APsIFot2N0/g== X-Google-Smtp-Source: ABdhPJw+30A1z5G4v6FC2342154wdeO9LAGCVWZg3J0q3CVcdk4c7J6rC9esyJFVe6Z0oD7qbUh7lg== X-Received: by 2002:ae9:df01:: with SMTP id t1mr3927998qkf.5.1607192364212; Sat, 05 Dec 2020 10:19:24 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id x28sm7438016qtv.8.2020.12.05.10.19.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 10:19:23 -0800 (PST) From: Ted Lemon Message-Id: <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 13:19:20 -0500 In-Reply-To: Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:19:28 -0000 --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 5, 2020, at 1:10 PM, Randy Bush wrote: > to improve the math one would have to amortize the cost of maintenance > over many many flavors and makers of thingies. so the acme thingie = mfr, > and the hackme thingie mfr, and the ... need to have a common code = base > and upgrade infrastructure. this is seen as stifling innovation in a > highly innovative and competitive space. >=20 > the time from first pitch to vc term sheet and funding has gone down = to > two weeks. and the resulting landfill rivals the problem of plastics = in > the oceans. The landfill issue is certainly heartbreaking. But most of those = Shenzhen products you=E2=80=99re talking about are based on open source = already. I=E2=80=99m not convinced that this particular problem is = actually as intractable as you are suggesting. --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 5, 2020, at 1:10 PM, Randy Bush <randy@psg.com> wrote:
to improve the math one would have to amortize the cost of = maintenance
over many = many flavors and makers of thingies.  so the acme thingie = mfr,
and the = hackme thingie mfr, and the ... need to have a common code = base
and upgrade = infrastructure.  this is seen as stifling innovation in a
highly = innovative and competitive space.

the time from first pitch to vc term sheet and funding has = gone down to
two weeks. =  and the resulting landfill rivals the problem of plastics = in
the = oceans.

The = landfill issue is certainly heartbreaking. But most of those Shenzhen = products you=E2=80=99re talking about are based on open source already. = I=E2=80=99m not convinced that this particular problem is actually as = intractable as you are suggesting.

= --Apple-Mail=_93EB1331-6DAD-40B0-A849-B3E7B61D56C6-- From nobody Sat Dec 5 10:27:48 2020 Return-Path: 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 6060C3A0AF6; Sat, 5 Dec 2020 10:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 a4QYZaQAud23; Sat, 5 Dec 2020 10:27:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6603A0A0E; Sat, 5 Dec 2020 10:27:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcHT-0005uP-2U; Sat, 05 Dec 2020 18:27:39 +0000 Date: Sat, 05 Dec 2020 10:27:38 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:27:44 -0000 > most of those Shenzhen products you=A2re talking about are based on open > source already and open source is notoriously secure, inspected, formally verified, and well updated. can you spell "m i r a i?" how many kernel upgrades have you had to do over the last month; and what percentage of ops did them? randy From nobody Sat Dec 5 10:32:31 2020 Return-Path: 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 DB65C3A0B1A for ; Sat, 5 Dec 2020 10:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 UTbAOvJ5y8sq for ; Sat, 5 Dec 2020 10:32:27 -0800 (PST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFC43A0B16 for ; Sat, 5 Dec 2020 10:32:26 -0800 (PST) Received: by mail-qt1-x830.google.com with SMTP id d5so6500669qtn.0 for ; Sat, 05 Dec 2020 10:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tIq14bohZFtwHfwNywzg9gaytwGrJXTDRNGbbKi9HHE=; b=vbGlZpOSI6xtP10+U0/z0rEDKQWHlVZkwc4a2plikqIGbtY+q/nri5Y6stj+A81/1u CRMv6NXLiesh+MZ8htTy6tkKDMNVXNz7QMsMlghbK+3q3Tzo/EnZS3+mHfcipXhLIlBX FZMmIZH1DLUSZAtxdcJKoVIRAbqFTWZG8oF5ABkKww71gpiQjYESyAK3/3F1g07+mhe5 kFoEhssaXA458aiEXI8GHN7rr1XLiT+NF3Q3htHDME7VHTJOzVsCjJdIGEIkWy8IiQrS hpNeDChJaxWnHja2BqAPD8PqqOKmEz6r/nhmYrxJIquD6f1hk6577kjxdcMkzjR7pWCe ewEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tIq14bohZFtwHfwNywzg9gaytwGrJXTDRNGbbKi9HHE=; b=A/eS8Nk6QVpN7TNTtX9sIAg8HJ9g3diL3s/Kd2z2fmOK3lqt3qS1If0RAsLaxNNUlH JuwJsvKx6abQSDd73WdN1LJZC/lMRHZMiHtmVjJPTqT90gj3DkaFzoFuYC1JOETSPl6c XCyjc5lhUS1By3PShfBkFz2c82rE7wyB6xJKaErG2Qs9ovj+GbNGfr3Yhvaq4vCAqgMF /uZCjJvRZSLXklaDoj+Pf4+xSO/yuBUxytaI34PID1CvKF/GKtfGZO6gV8svJZFS2ABg UytqodzCkmqjUKG/qLPxSJOo1e/1BN9lQal14g6d8USLfYzdaLpKMLTdl4mfPW2/CZfs CpPg== X-Gm-Message-State: AOAM5319auWP+N0wB8TQzyh6S3tHwSBP3mz+E45REHoCTCYAnX6tIBGd b6NzzssZDGO8Z4ae30YO+EBWeQ== X-Google-Smtp-Source: ABdhPJxpvwhJ8hVY1sjWQJ/IQ2CAkMS6KHtbxQbVXeNmAAVim1ZD0PAPaq63d1w0kjqQBRnhjZ3R8g== X-Received: by 2002:ac8:44c7:: with SMTP id b7mr2027515qto.351.1607193146085; Sat, 05 Dec 2020 10:32:26 -0800 (PST) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id j124sm9297217qkf.113.2020.12.05.10.32.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 10:32:25 -0800 (PST) From: Ted Lemon Message-Id: <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 13:32:23 -0500 In-Reply-To: Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:32:29 -0000 --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Dec 5, 2020, at 1:27 PM, Randy Bush wrote: > and open source is notoriously secure, inspected, formally verified, = and > well updated. can you spell "m i r a i?" how many kernel upgrades = have > you had to do over the last month; and what percentage of ops did = them? I think you misunderstand. I=E2=80=99m not saying there=E2=80=99s not a = problem. I=E2=80=99m saying that solving it maybe isn=E2=80=99t quite as = hard as you=E2=80=99re suggesting. Most of these products, the = manufacturer has already moved on after a year. They have no interest in = maintaining the software, but they can dump it on github. They don=E2=80=99= t because they don=E2=80=99t have to, not because they strongly care not = to. If you bought a thousand units, it=E2=80=99s probably worth hiring = someone to update it to TLS 1.3. Getting Cisco to dump IOS on github is probably a bigger ask, but if the = enterprise that=E2=80=99s buying the equipment is required for = regulatory compliance to subscribe to updates, that creates a cash flow = that can then be used to pay to do them. If the regulatory environment = similarly requires that Cisco either do the updates, or allow someone to = do them, then that problem is solved too. Yes, this costs more than disposable technology, iff you don=E2=80=99t = count the externalized costs. --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Dec 5, 2020, at 1:27 PM, Randy Bush <randy@psg.com> wrote:
and open source is notoriously secure, inspected, formally = verified, and
well updated. =  can you spell "m i r a i?"  how many kernel upgrades = have
you had to do = over the last month; and what percentage of ops did = them?

I = think you misunderstand. I=E2=80=99m not saying there=E2=80=99s not a = problem. I=E2=80=99m saying that solving it maybe isn=E2=80=99t quite as = hard as you=E2=80=99re suggesting. Most of these products, the = manufacturer has already moved on after a year. They have no interest in = maintaining the software, but they can dump it on github. They don=E2=80=99= t because they don=E2=80=99t have to, not because they strongly care not = to. If you bought a thousand units, it=E2=80=99s probably worth hiring = someone to update it to TLS 1.3.

Getting Cisco to dump IOS on github is = probably a bigger ask, but if the enterprise that=E2=80=99s buying the = equipment is required for regulatory compliance to subscribe to updates, = that creates a cash flow that can then be used to pay to do them. If the = regulatory environment similarly requires that Cisco either do the = updates, or allow someone to do them, then that problem is solved = too.

Yes, this = costs more than disposable technology, iff you don=E2=80=99t count the = externalized costs.

= --Apple-Mail=_16AECF83-304B-4CDE-AF66-5E036E6B4E36-- From nobody Sat Dec 5 10:46:14 2020 Return-Path: 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 7B6903A003E; Sat, 5 Dec 2020 10:46:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6AYhAiP6k2os; Sat, 5 Dec 2020 10:46:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206E73A0039; Sat, 5 Dec 2020 10:46:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcZG-0005vy-JM; Sat, 05 Dec 2020 18:46:02 +0000 Date: Sat, 05 Dec 2020 10:46:01 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:46:08 -0000 > they can dump it on github well chosen verb now that github is owned by msoft, next year msoft ai will formally verify and correct all the dren on github. w00t! randy From nobody Sat Dec 5 10:48:33 2020 Return-Path: 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 0FB0D3A02BD; Sat, 5 Dec 2020 10:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 2TvswAqFOG0g; Sat, 5 Dec 2020 10:48:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D0D63A0147; Sat, 5 Dec 2020 10:48:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klcba-0005w9-0t; Sat, 05 Dec 2020 18:48:26 +0000 Date: Sat, 05 Dec 2020 10:48:25 -0800 Message-ID: From: Randy Bush To: Ted Lemon Cc: Eliot Lear , "Ackermann, Michael" , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:48:30 -0000 >> they can dump it on github > well chosen verb > now that github is owned by msoft, next year msoft ai will formally > verify and correct all the dren on github. w00t! and, of course, once msoft ai fixes the code, it will magically and securely distribute it to the 42 jillion deployed devices. via luftschweinza randy From nobody Sat Dec 5 10:54:50 2020 Return-Path: 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 EDF443A0596 for ; Sat, 5 Dec 2020 10:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 EYLwZBRljLL5 for ; Sat, 5 Dec 2020 10:54:47 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F0B3A048B for ; Sat, 5 Dec 2020 10:54:46 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id r18so10486969ljc.2 for ; Sat, 05 Dec 2020 10:54:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ckCzTpqd+VYzCUUeIlbswDDow+2mmMmMHt9zsBmcXK0=; b=iFFE3vxRz1q848iQQgVvHOzvMI6tAG7q6v99xeW2sy/zVv0Po0cnem0rAZcj8Ob/Hc rg4DG4GqvtpanwQxbANNmkRVecBEvXBmtfE8/S5S8HSUaMJQMIhTIySuRhr5zMMTD7TS xEaV09caI+oKa6ccka8Om7BuhboRF5XgjrVgaru3cDhbvOSJrHv54nJmFEmXZfLkHFLI 39djUgEIqVAK7tC8JHdNejYDOV+vqw4BgzmtS0eNE9BGnePkp82lHkItKpDyjhQFb4SV tqxsZVk4XIp0pfF+NNB3TBOVOwD6yeGxu9uHAdeUApRPIjsbpk8EVWLZ7Y9Z9QwAIlnP cedg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ckCzTpqd+VYzCUUeIlbswDDow+2mmMmMHt9zsBmcXK0=; b=MhHFQ6CmTCJjxbrNHNIJ6nJOM+p9v9p53fxmTJyN24c8pKDoc3xv6mBGsuJE6FXHRx YD4UXAePp4mJC2znzSLL/Ep936G+uZzfTqiDv+QcghwWT9M6t/ZvijY1QoPAClCTOLCw ZcMX/kPGIPheD37zeNN8HSclIxis+bLKoe1YUVwVNBJ/X1y1Cxls1ksTSY4Hjy8RYCPA TWcD5G6cXVzZJNUsyZz6mOOeR3fGcyUqHzqpkMKLnDRwngnSdncoQAVcytw7s75tIDJk nZrP9DWWwYeblAHFqpdqhETu6LxdzjW+xmAyZIavZGLIrycFCHWDrYl8LqAHqxnOCncO kkOg== X-Gm-Message-State: AOAM532DxIIHpOtY2WyGeQymBhPsESudaUU9OqZpVXNE540IbGofSWRp PnS6DY1gRsWKV7StPxe5DxW9jWtrEW3K+D6SgvBpRw== X-Google-Smtp-Source: ABdhPJzx8unsUIFdtuTes7doWo0aZmVy0W202eMfzRwrI08K3cd67qHwUvW95gOdqn61rUtKIYvDmLSr81S8QhnkTD8= X-Received: by 2002:a2e:9614:: with SMTP id v20mr5747693ljh.13.1607194484953; Sat, 05 Dec 2020 10:54:44 -0800 (PST) MIME-Version: 1.0 References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> In-Reply-To: From: Eric Rescorla Date: Sat, 5 Dec 2020 10:54:08 -0800 Message-ID: To: Randy Bush Cc: Ted Lemon , iotops@ietf.org, architecture-discuss@iab.org, "Ackermann, Michael" Content-Type: multipart/alternative; boundary="0000000000005c65fe05b5bc2066" Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 18:54:49 -0000 --0000000000005c65fe05b5bc2066 Content-Type: text/plain; charset="UTF-8" I know you're just being sarcastic, but Microsoft, in cooperation with INRIA and others has done a bunch of great work on code verification, including: - mitls - a verified TLS stack [https://www.mitls.org/] - HACL* - verified implementations of a number of important cryptographic algorithms [https://hacl-star.github.io/] HACL* is actually seeing quite a bit of use. To quote from their site "Code from HACL* has been incorporated into Firefox , the Windows kernel, the Linux kernel, the Tezos blockchain , the Microsoft MSQuic implementation of the QUIC protocol, and the Wireguard VPN ." -Ekr On Sat, Dec 5, 2020 at 10:46 AM Randy Bush wrote: > > they can dump it on github > > well chosen verb > > now that github is owned by msoft, next year msoft ai will formally > verify and correct all the dren on github. w00t! > > randy > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --0000000000005c65fe05b5bc2066 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I know you're just being sarcastic, but Microsoft= , in cooperation with INRIA and others has done a bunch of great work on co= de verification, including:

- mitls - a verified T= LS stack [https://www.mitls.org/]
- HACL* - verified implementations of a number of important cryptog= raphic algorithms [https://hacl-st= ar.github.io/]

HACL* is actually seeing quite = a bit of use. To quote from their site "Code from HACL* has been incor= porated into Firefox, the Windows kernel, the Linux kernel, the Tezos blockchain, the Microsoft MSQuic implementation of the QUIC protocol, and the Wireguard VPN."

-Ekr

<= /div>
O= n Sat, Dec 5, 2020 at 10:46 AM Randy Bush <randy@psg.com> wrote:
> they can dump it on github

well chosen verb

now that github is owned by msoft, next year msoft ai will formally
verify and correct all the dren on github.=C2=A0 w00t!

randy

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--0000000000005c65fe05b5bc2066-- From nobody Sat Dec 5 11:01:34 2020 Return-Path: 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 7300D3A0763; Sat, 5 Dec 2020 11:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AAPP_lF0Zjse; Sat, 5 Dec 2020 11:01:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713B03A0762; Sat, 5 Dec 2020 11:01:21 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1klco2-0005xe-W1; Sat, 05 Dec 2020 19:01:19 +0000 Date: Sat, 05 Dec 2020 11:01:18 -0800 Message-ID: From: Randy Bush To: Eric Rescorla Cc: Ted Lemon , iotops@ietf.org, architecture-discuss@iab.org, "Ackermann, Michael" In-Reply-To: References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <29EBB9B3-4AF6-4734-B7C4-A03F99935F6D@fugue.com> <6FA07BCE-B9A9-490C-A687-2EA0FF6E6993@fugue.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:01:30 -0000 > I know you're just being sarcastic moi? > Microsoft, in cooperation with INRIA and others has done a bunch of > great work on code verification indeed. impressive work. and galois has a solid foot in a very interesting part of the space too; as do a bunch of folk. but i suspect that it will be at least until after the holidays that all this will seriously improve the quality of the code 'dumped' on github. randy From nobody Sat Dec 5 11:43:56 2020 Return-Path: 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 B87483A0C3A for ; Sat, 5 Dec 2020 11:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no 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 Sl4i1Q1jHz14 for ; Sat, 5 Dec 2020 11:43:49 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07E53A0C33 for ; Sat, 5 Dec 2020 11:43:48 -0800 (PST) Received: from xse290.mail2web.com ([66.113.197.36] helo=xse.mail2web.com) by mx14.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kldT4-0004IF-NL for architecture-discuss@iab.org; Sat, 05 Dec 2020 20:43:46 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CpKkh26M7zP8x for ; Sat, 5 Dec 2020 11:43:40 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kldT2-0004So-5i for architecture-discuss@iab.org; Sat, 05 Dec 2020 11:43:40 -0800 Received: (qmail 10109 invoked from network); 5 Dec 2020 19:43:39 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.42]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Dec 2020 19:43:39 -0000 To: Randy Bush , Eliot Lear Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> From: Christian Huitema Message-ID: <25c496c0-98d0-e15b-d16f-e55b40936e35@huitema.net> Date: Sat, 5 Dec 2020 11:43:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.36 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ecN11dQIc3aKzz9DU5dqGmpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDeW3+HZ7LK0h6oEMb2VkOa5vM xCtZSe87wnSOA0YTnlDnx8yeplRO3sLIqUlSH7OGMipaUlZj6EboddkbzgrvmoMlhcTgOXSCz8qb ysTVYVn6w92A9ufZeIxcANJL/o3BYMduR415Dhyr6aT7qqy64jBZvGs5kIlIylOX/ITZ+jbBU3X0 vv4ek5BNjExj4CjFBnrB5iBLOq4raHGySpe/LzCgJPEsrB5Nu4n7X3OzIdUZWaEwBpD8B8JHBF7v Iebmhj41iaxIaf6y8y5vGduCbZKDcNF1LrVoVLXP90si9LxEozyv0Y0npPwcFeA3apMBboZD5vPF e84pJQGk5dfbFPdfcXgLzsY3kBHC+ZTZl3S5+IwAWiarTQyLhmI9lhnr3l4BTMsdLA+IUUtrsjBa axEfRPm7RhvF5NbroBPxVOCfU642KNtk4n/u8nyV2xsjehIqUczFWeS6sE8e1b5/Uj/i4hYVfUxI FxiN15g3w5xVgddXYQ3GpyBacgDtpRVbgV4eE4ITtcyTXXHRTrA5R+GxOQky7QcLP49qViNOweBM ozjVBy4sgtNitOb4F/gk7+aVm/NqgKA5dyCxkhdL5g7yNAxIoTne18wgCHBWXWPglGrdRgcS3bYi 8gwoFJOVHhLBjiTilP5Cxp8STDou3d4JH52k6hlME7V4H+/Xw7kan9u1XhzpF3vNmn81pQyLR7rk 1sdiXZvS9isGGFLyxRxwEiTVJqDh0qKoKsXx5ln2SMMcYcLzHFodDBnL1LUIZ8D6b7Rv+O/SExrX MUg3MNbxIx8r0tkGYkfgGWL38RL2RSrvmTNpgdQqU4ccmgaW3jR5NeVaJQBh0uawl0Cg8gkFJY4U lg4VofOxwUi4TVKOKogdFzFUBtke4lHzswE2heUd4UCZPAsMlEWCkNGHtIkd2x35zAiBFPp64JaI ysCWp33KKvSLEepfzmW/VTBD X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 19:43:52 -0000 On 12/5/2020 10:10 AM, Randy Bush wrote: > when you have a plant which can turn out a jillion new thingies with a > day of set-up, the costs of the infrastructure to securely maintain and > upgrade them in the field for three, let alone 20, years is astronomical > in comparison. now multiply that by a new and different thingie being > manufactured next month. now multiply that by a few hundred > manufacturers. > > perhaps the only way to understand in one's gut the scale of this > problem is to spend a few weeks in shenzhen. That's indeed the big tension. People set up factories, hospitals and many other environments with a focus on their main mission, be it mass production of widget or the saving of lives. They don't want to stop doing what they are doing just because all the thermostats needs to be replaced. At the same time, we have ample evidence not replacing these obsolete little thermostats or other devices opens them to catastrophic failures, such as the casino that got hacked through an aquarium control device, the many hospitals that were hit by ransomware attacks, or the uranium enrichment plant that was crippled by a virus. So, what gives? The Mirai worm attacked routers, which supposedly were acting as firewalls for home networks. That uranium enrichment plant was supposedly air-gapped. It is pretty clear that solutions based just on isolating networks with firewalls do not work in practice. But then, it is also clear that the current IAB recommendation of "regular software updates" does not work either. People don't do that because they fear the update itself will damage their network, or maybe because the device is so old that the manufacturer is not producing updates anymore, or for what other reason that I have yet to understand. As Randy says, we are supposed to construct a reliable network from unreliable components. We are failing at that. What should we do? Should we recommend some form of preventive maintenance, in which devices are systematically replaced after some years, much like we currently systematically replace batteries or light bulbs before they fail? For devices that cannot be replaced, such as maybe MRI machines, should we suggest some kind of individual firewall that isolates them from the network? I don't know, and my ideas are probably wrong. But we need to have that discussion, and we need to have it with the people who actually manage plants, hospitals and other environments. -- Christian Huitema From nobody Sat Dec 5 13:11:12 2020 Return-Path: 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 E2FD43A0D64 for ; Sat, 5 Dec 2020 13:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ambotec.org 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 toq-JE9Zs4ww for ; Sat, 5 Dec 2020 13:11:08 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8411B3A0D4B for ; Sat, 5 Dec 2020 13:11:08 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id a3so10080472wmb.5 for ; Sat, 05 Dec 2020 13:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambotec.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=sfX2XP982QTx+HzDrdiwrUj13f2GMHF59YdyTv/z5uM=; b=K28zYpKBuKg2JhhUeVtkI+mOxsD7SyDum6DdxUw1rmeOyR812j75yDlCVLNGVQ2NtD 8p8ogrSPhZsQLNqsTjL/jZvojXnhfGQyraQUrI9rKvcfpAXp4fXxSEtABjEFu32Nwvvn lk/e8iZPNCtgqrgRQUAJdAnw/qo4Zl1OZWD8IHkqCTCVIB6o8ZD0EPHr2Nm0N8El1QGt gPfu7FUgGYuxxGh07lp42GOAlQXklNeM0Zi123qWby3e/VgDUSiq9UcuH+d5A7riRae4 wJXaY0F/XfIDrlmo2eEkWrld2brmoXRMszqi8X1o4IVgFwpwafMVRLCxEk0j5FhoDd0G S/Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=sfX2XP982QTx+HzDrdiwrUj13f2GMHF59YdyTv/z5uM=; b=eJSd9TbU9tM9T/okjmesnzcnrsBXIr22VjwN7CaGeqPEbIuawwnjKz+hZQQEqTL6gm iWfTfRAwww/6ZQL0YZNvATo9AaV4EJo2fVUkFp5+kVo5HrZRIggeN+p/xs1BkRL+Hivz W4FnP/mrRe/rsZH2r1QznFVjxH51LB/c9KCi63AtX3uhnK6CXlLhG2IRgSPT7zEL6rlc UxyEVuIn9uwNfDYvGNOgVsP5cyl69CpydCmnHZDnhjNKyceV+0kssJWht19mi4yBInyo u8NDJaYXW0v4QKUiUx/53fCjsY4lx0Iuq5Dcwtu5tLpt+MRxlZjW9asG5ybXmpw5ZhqK qHfA== X-Gm-Message-State: AOAM531H1xlab5AjkzygWT0YLHUgpynXIi9G8Z8zpzkMPWo4EpNq0uSd 77wjtAVl4LYuEcgOy2gOWuYZKQ== X-Google-Smtp-Source: ABdhPJyNMVMTIYjszYFGeuPCt9urpiRE2S4xSSQ5oPyiJi+l28oAfcdyqbYC2QBi6EJHiqyZhN1WlA== X-Received: by 2002:a1c:6689:: with SMTP id a131mr10686694wmc.33.1607202666512; Sat, 05 Dec 2020 13:11:06 -0800 (PST) Received: from [192.168.1.4] (3.236.90.146.dyn.plus.net. [146.90.236.3]) by smtp.gmail.com with ESMTPSA id f14sm8802521wme.14.2020.12.05.13.11.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Dec 2020 13:11:05 -0800 (PST) From: Amyas Phillips Message-Id: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 5 Dec 2020 21:11:04 +0000 In-Reply-To: Cc: Eliot Lear , architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 21:11:11 -0000 --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Dec 2020, at 18:10, Randy Bush wrote: >=20 > to improve the math one would have to amortize the cost of maintenance > over many many flavors and makers of thingies. so the acme thingie = mfr, > and the hackme thingie mfr, and the ... need to have a common code = base > and upgrade infrastructure. =20 Exactly right, it=E2=80=99s hard to imagine any other economically = viable way of maintaining devices which aren=E2=80=99t sold with a = service contract. Even for devices which are sold with a service = contract, this is still a cheaper and likely better way of delivering = the security maintenance part of that service.=20 There=E2=80=99s a few commercial products which do this. They = essentially offer modules with an OS and application environment which = they maintain for you, to a more or less hands-off degree: msoft Sphere, = Balena, Particle, Electric Imp, Ubuntu Core. They don=E2=80=99t maintain = your application but that may well be a relatively small part of the = attack surface, and possibly defended by features of the maintained = environment.=20 Microsoft Sphere in particular is interesting because the maintenance is = completely hands off and the costs are folded into the initial BOM cost = of the module, there=E2=80=99s no service fee. Amyas= --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:

to improve the math one would = have to amortize the cost of maintenance
over many many flavors and makers of thingies.  so the = acme thingie mfr,
and the hackme thingie mfr, and the ... need to have a common = code base
and upgrade = infrastructure.  


Exactly right, it=E2=80=99= s hard to imagine any other economically viable way of maintaining = devices which aren=E2=80=99t sold with a service contract. Even for = devices which are sold with a service contract, this is still a cheaper = and likely better way of delivering the security maintenance part of = that service. 

There=E2=80=99s = a few commercial products which do this. They essentially offer modules = with an OS and application environment which they maintain for you, to a = more or less hands-off degree: msoft Sphere, Balena, Particle, Electric = Imp, Ubuntu Core. They don=E2=80=99t maintain your application but that = may well be a relatively small part of the attack surface, and possibly = defended by features of the maintained environment. 

Microsoft Sphere in particular is interesting = because the maintenance is completely hands off and the costs are folded = into the initial BOM cost of the module, there=E2=80=99s no service = fee.

Amyas
= --Apple-Mail=_10E9567C-D934-4F48-B2D4-DF65F04E289A-- From nobody Sun Dec 6 04:32:43 2020 Return-Path: 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 214A73A0D1C for ; Sun, 6 Dec 2020 04:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 D5f_cm2qCca5 for ; Sun, 6 Dec 2020 04:32:40 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C793A0D14 for ; Sun, 6 Dec 2020 04:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2312; q=dns/txt; s=iport; t=1607257960; x=1608467560; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=TI/aMTFdV4qj8DMbP5tpgFR7In/THeT89w23sLhNGrI=; b=H7H3hdOn0kdoJmRCFHPE5Szi6WVVE/oLULGeXxGTy7o2Mtmln/zgb/Co TLnyrPjZXDp5FafJRXlRO+tA8t4H+5d/tqcle8/2cYCAWQDMdXXlnXh/S vUfzP469793zK8EM2KomJteIWv1C1QOzKTh0gtpO33CE9rIwM36pOG/Lv o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BmDADUzsxf/xbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4N2ASASLoQ8iQSHfyUDnDIEBwEBAQoDAQEvBAEBg0sBAX0CghYmOBMCAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBHGFbYVyAQEBAwEjVgULCxgjBwICVwYTgyYBgmYgq?= =?us-ascii?q?nt2gTKFV4USEIE4gVOJI4JmggCBOAwQgiAHLj6HVTOCLASDJ3IwDShUApBEH?= =?us-ascii?q?It0nBWCfoMhgTeWZAMfknGPO7Ekg2wCBAYFAhWBbSOBVzMaCBsVZQGCPj4SG?= =?us-ascii?q?Q2OWI4TQAMwNwIGAQkBAQMJjSgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,397,1599523200"; d="asc'?scan'208";a="29245021" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Dec 2020 12:32:35 +0000 Received: from [10.61.245.231] ([10.61.245.231]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B6CWYUn027615 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 6 Dec 2020 12:32:35 GMT From: Eliot Lear Message-Id: <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sun, 6 Dec 2020 13:32:34 +0100 In-Reply-To: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> Cc: Randy Bush , architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon , "Ackermann, Michael" To: Amyas Phillips References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.245.231, [10.61.245.231] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 12:32:42 -0000 --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Dec 2020, at 22:11, Amyas Phillips wrote: >=20 > There=E2=80=99s a few commercial products which [=E2=80=A6] = essentially offer modules with an OS and application environment which = they maintain for you, to a more or less hands-off degree: msoft Sphere, = Balena, Particle, Electric Imp, Ubuntu Core. They don=E2=80=99t maintain = your application but that may well be a relatively small part of the = attack surface, and possibly defended by features of the maintained = environment. >=20 > Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM = cost of the module, there=E2=80=99s no service fee. It=E2=80=99s a start. The question is long those contracts stay in = place. The issue is not 1, 2, or 3 years from purchase, but generally = later. The more recent the product was shipped the more motivation to = fix it within the existing framework, as D-Link discovered. In looking 10 years out, the aggregate exposure is lower due to the = number of units, but that means that the maintenance costs, which are = independent of outstanding units, need to be borne by a smaller based, = or priced in at time of sale. That=E2=80=99s not a small number for any = but the largest companies. Eliot --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/Mz2IACgkQh7ZrRtnS ejNxHQf/UVfuTZEsh6yR//kx4CTrJ4WZJzg9PnRRuKi0Mco7Jw3oEL+ZSpHd6dUY qB/Ev82yNbs/ZGW+V3GeSY+0BrujefNVGrF1nUa2jzIRad+2Lotxj+j9OtefNzrz 37IG1EqXmcgylGIwOh+eaJ814Idla/uiKoHi6G6G9CpDYAdQB8VCOM/0hNWdGiCR 8rqvQSE3XsSbYnKrgjs8gHevI/OJJ3d4NND9JhYvv0zmKc6Lk4poh79oaral1+N0 GlaTFhrK6sFgSZZyOsd+vWy5hQDSqeu60UywYlyhvRVVHI2JxvbJu7InQLNbGAWO UJPGfTmW/CSbYCBKIagVjZ73Eku4xA== =uzGu -----END PGP SIGNATURE----- --Apple-Mail=_BE889DFF-0392-4BDA-A6D6-87DD67AE2714-- From nobody Mon Dec 7 01:19:03 2020 Return-Path: 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 AF1A13A1258 for ; Mon, 7 Dec 2020 01:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 1evHh4RyyGwl for ; Mon, 7 Dec 2020 01:19:00 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9691E3A1256 for ; Mon, 7 Dec 2020 01:19:00 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 732E9549B09; Mon, 7 Dec 2020 10:18:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 69371440041; Mon, 7 Dec 2020 10:18:54 +0100 (CET) Date: Mon, 7 Dec 2020 10:18:54 +0100 From: Toerless Eckert To: Amyas Phillips Cc: Randy Bush , Ted Lemon , "Ackermann, Michael" , architecture-discuss@iab.org, Eliot Lear , iotops@ietf.org Message-ID: <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 09:19:03 -0000 Great pportunity for a rant: Its easy to understand how the mayority of participants in these discussions are from either a commercial supplier side, or from a commercial user side. In either case, a clearly time restricted use case scenario is easily be most important default. This btw. also applies to where my pay check comes from (i think). Nevertheless, i would highly recommend to no limit our design decisions to this scenarios. Personally, i for once would be happy as an individual to see any standards be blackmailed in the press and in public as an evil conspiracy for planned obsolescence that does not consider the ability for devices to operate as long as their hardware can without being constrained by 'security' software. Obviously, there are also significant commercial applications undetermined long life cycles are required. Just think of any deep space exploration NASA satellites go dark because of their non-crypto agility. Or the non-desire to upgrade nuclear missile control systems to new HW/SW because overall system security analysis shows how new HW/SW more likely than not will be MORE susceptible to attacks than simpler older SW/HW around for 50 years. Just two extreme examples. I am not 10% sure about generic approaches to solve this problem, but one approach could be the following: - A device communications is designed to be able to operate solely within a "walled garden" environment. Not as the ONLY option, but as one option. - Walled garden means that all communication channels of the device can be directed to go through other nodes of the "walled garden". - "Walled garden" should IMHO also mean that the higher layer semantic of all communications is well enough defined/documented, so that another device in the walled-garden can be set up to convert/proxy the communications. - Aka: If the crypto starts to become obsolete, then the obsolete crypto would be possible to constrain to the walled-carden (physical security) environment, and be proxied, and if the original remote communication parties do not exist anymore, but the data to be exchanged exists, then such a proxy could also proxy/convert the data into the 'legacy' format. The ability to understand all the information communicated well enough to be able to re-recreate the format is also necessary for any type of higher-layer security filtering, so this type of communications design is not only good for longevity, but also for security beyond transit confidentiality. Cheers Toerless On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > to improve the math one would have to amortize the cost of maintenance > > over many many flavors and makers of thingies. so the acme thingie mfr, > > and the hackme thingie mfr, and the ... need to have a common code base > > and upgrade infrastructure. > > > Exactly right, it???s hard to imagine any other economically viable way of maintaining devices which aren???t sold with a service contract. Even for devices which are sold with a service contract, this is still a cheaper and likely better way of delivering the security maintenance part of that service. > > There???s a few commercial products which do this. They essentially offer modules with an OS and application environment which they maintain for you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, Electric Imp, Ubuntu Core. They don???t maintain your application but that may well be a relatively small part of the attack surface, and possibly defended by features of the maintained environment. > > Microsoft Sphere in particular is interesting because the maintenance is completely hands off and the costs are folded into the initial BOM cost of the module, there???s no service fee. > > Amyas > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops -- --- tte@cs.fau.de From nobody Mon Dec 7 06:43:44 2020 Return-Path: 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 9DB2B3A13F4 for ; Mon, 7 Dec 2020 06:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu 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 19X51mhbpI1Z for ; Mon, 7 Dec 2020 06:43:38 -0800 (PST) Received: from mx0a-00364e01.pphosted.com (mx0a-00364e01.pphosted.com [148.163.135.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611DC3A13F6 for ; Mon, 7 Dec 2020 06:43:38 -0800 (PST) Received: from pps.filterd (m0167072.ppops.net [127.0.0.1]) by mx0a-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B7EgEkp031451 for ; Mon, 7 Dec 2020 09:43:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=pFBdmRO466xkBuJ+GH/w1k2euHTfQg6iBJxXk4OP6mM=; b=Se8zsGfN/aRZprCob8vxSwXUjaor9NHWpCx9Bp4d3pjMtgK2+E+g+Uya31UG4cagg639 Nax4NuwoFaWThWqu/FD0hjnJGQ8NAUG7WwOf6GsMFUT/unKTzFW5jS5glV+KT5skdAZa qZy9N5dGvibkIvEc4ECGpDP7yt54HlIFb2ZFwXQ4Bh6dUvoPIAgxZsyWVEo9LiJNVAV3 7pJAC7KlOcPAHT8Xk5vkiAoLpiF+kQmkE5g2p8r85GwLyoJZ30v0mEzy+5PCB1GJQFQD FP8GkfZHM6d5SqnnpAFXAij7yLuZRs2+69DSH3QtzSbD7FWrBuE587wzfG6l/NudtE3d zw== Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0a-00364e01.pphosted.com with ESMTP id 3587901qca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 Dec 2020 09:43:37 -0500 Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B7EhZQX044754 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 7 Dec 2020 09:43:36 -0500 Received: by mail-qv1-f69.google.com with SMTP id 12so11653354qvk.23 for ; Mon, 07 Dec 2020 06:43:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFBdmRO466xkBuJ+GH/w1k2euHTfQg6iBJxXk4OP6mM=; b=swdUQtBUJ6P9MnRVtHgnWN9D6hIlYidDBZ/TTqfFdDq8mUjnnXdpPYudHHhb1pkcJT U1k/iTue8q10LBK74OgFyZTzimoYCyQaLfqkESi8871gjjYvUpl5rLrro9ugMV7EReeN suElq4tNDwJmucUO//bHQDnuZrby6O/j/OOVfUlxyEuk9A4+uJC6ssQUnHH1F4Q/dFL+ RMW+UKfwVBPtePE7YyzWwSpMr9dGHkpuG3E8njIZafnDYrsTXY8qtkaSfkbUKQK5Ch3v dVvsnMDsC8vTx72nstCzwi9LN5bFGB5cA4FCaaiL2wALCZ12oYYHzU0jxuNMD+UNwLh2 +p0A== X-Gm-Message-State: AOAM532rDs6Y7vdh1nu9Knnv4Aj3EZ1i/RFIzpqAo50MVJd3ZUrKiDe0 1TwneJGT0F6mNo2fPwHWB7rgiLtakgbBhC65WL6xC3arGtjBDogGuNGWx3f2i6IcgrjB9EkROuh 51PEE2N8ganx3dUFZOy3i9RUjKPfHMvpIhu2ltYPjyAXHENBE X-Received: by 2002:a05:620a:2296:: with SMTP id o22mr24565518qkh.261.1607352214688; Mon, 07 Dec 2020 06:43:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyf3e4kna/2FCZBL2LdX89NmMbdYMf3oq9ZCT4QljJM5+bmJ7Bh9Y6SghEpmAVqJMtbJ8Nc633TZKfmxgtoAso= X-Received: by 2002:a05:620a:2296:: with SMTP id o22mr24565471qkh.261.1607352214180; Mon, 07 Dec 2020 06:43:34 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> From: Henning Schulzrinne Date: Mon, 7 Dec 2020 09:43:07 -0500 Message-ID: To: Toerless Eckert Cc: Amyas Phillips , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Randy Bush , "Ackermann, Michael" Content-Type: multipart/alternative; boundary="000000000000c16a0705b5e0d99f" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_11:2020-12-04, 2020-12-07 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 bulkscore=10 mlxlogscore=999 clxscore=1011 impostorscore=10 spamscore=0 priorityscore=1501 lowpriorityscore=10 phishscore=0 mlxscore=0 suspectscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012070093 Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 14:43:41 -0000 --000000000000c16a0705b5e0d99f Content-Type: text/plain; charset="UTF-8" It used to be that vendors announced end-of-life for products years after introduction. For example, there was no way for a purchaser of Windows NT to know, at purchase time, how long Microsoft was intending to support the operating system. Now, better vendors seem to have started to make some commitments, e.g., "this Android phone will receive new versions of the OS for three releases and security updates until 2025". All the major Linux distributions now have some kind of an LTS version, with long-term stability and security/bug upgrades planned. There have been proposals (in the UK?) of making vendors of IoT equipment state their support commitment, so that a purchaser can choose "cheap" or "lasts a lifetime". Unfortunately, industry advocacy is often for minimal regulation - there's an opportunity here for ISOC and others to make a difference. One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina) broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my printer working. Dell, the distributor of the printers (made by Fuji-Xerox, apparently) simply states that "due to circumstances beyond their control", they won't be providing any Catalina/Big Sur printer drivers. Given that most commercial systems are now assembled out of open-source components, with customization or glue on top, you'd want some kind of automated component checker. "17 of your components have not committed to long-term support. Are you prepared to fix them yourselves?" I don't know if this is feasible in all cases, but I suspect we often know that certain technologies are getting long in the tooth. They are not quite obsolete (historic) yet, but there's no active development or community and they probably shouldn't be components that can't be replaced in the field. No need (or resources) to do this for every RFC, but identifying critical pieces of technology and providing a support roadmap would be helpful, I think. On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > Great pportunity for a rant: > > Its easy to understand how the mayority of participants in these > discussions are > from either a commercial supplier side, or from a commercial user side. In > either > case, a clearly time restricted use case scenario is easily be most > important default. > This btw. also applies to where my pay check comes from (i think). > > Nevertheless, i would highly recommend to no limit our design decisions to > this > scenarios. > > Personally, i for once would be happy as an individual to see any > standards be > blackmailed in the press and in public as an evil conspiracy for planned > obsolescence > that does not consider the ability for devices to operate as long as their > hardware can > without being constrained by 'security' software. > > Obviously, there are also significant commercial applications undetermined > long > life cycles are required. Just think of any deep space exploration NASA > satellites > go dark because of their non-crypto agility. Or the non-desire to upgrade > nuclear > missile control systems to new HW/SW because overall system security > analysis > shows how new HW/SW more likely than not will be MORE susceptible to > attacks than > simpler older SW/HW around for 50 years. Just two extreme examples. > > I am not 10% sure about generic approaches to solve this problem, but one > approach > could be the following: > > - A device communications is designed to be able to operate solely within a > "walled garden" environment. Not as the ONLY option, but as one option. > > - Walled garden means that all communication channels of the device can be > directed > to go through other nodes of the "walled garden". > > - "Walled garden" should IMHO also mean that the higher layer semantic of > all communications is well enough defined/documented, so that another > device > in the walled-garden can be set up to convert/proxy the communications. > > - Aka: If the crypto starts to become obsolete, then the obsolete crypto > would > be possible to constrain to the walled-carden (physical security) > environment, > and be proxied, and if the original remote communication parties do not > exist > anymore, but the data to be exchanged exists, then such a proxy could > also > proxy/convert the data into the 'legacy' format. > > The ability to understand all the information communicated well enough to > be able > to re-recreate the format is also necessary for any type of higher-layer > security > filtering, so this type of communications design is not only good for > longevity, > but also for security beyond transit confidentiality. > > Cheers > Toerless > > On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > > > to improve the math one would have to amortize the cost of maintenance > > > over many many flavors and makers of thingies. so the acme thingie > mfr, > > > and the hackme thingie mfr, and the ... need to have a common code base > > > and upgrade infrastructure. > > > > > > Exactly right, it???s hard to imagine any other economically viable way > of maintaining devices which aren???t sold with a service contract. Even > for devices which are sold with a service contract, this is still a cheaper > and likely better way of delivering the security maintenance part of that > service. > > > > There???s a few commercial products which do this. They essentially > offer modules with an OS and application environment which they maintain > for you, to a more or less hands-off degree: msoft Sphere, Balena, > Particle, Electric Imp, Ubuntu Core. They don???t maintain your application > but that may well be a relatively small part of the attack surface, and > possibly defended by features of the maintained environment. > > > > Microsoft Sphere in particular is interesting because the maintenance is > completely hands off and the costs are folded into the initial BOM cost of > the module, there???s no service fee. > > > > Amyas > > > -- > > Iotops mailing list > > Iotops@ietf.org > > https://www.ietf.org/mailman/listinfo/iotops > > > -- > --- > tte@cs.fau.de > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000c16a0705b5e0d99f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It used to be that vendors announced end-of-life for = products years after introduction. For example, there was no way for a purc= haser of Windows NT to know, at purchase time, how long Microsoft was inten= ding to support the operating system. Now, better vendors seem to have star= ted to make some commitments, e.g., "this Android phone will receive n= ew versions of the OS for three releases and security updates until 2025&qu= ot;. All the major Linux distributions now have some kind of an LTS version= , with long-term stability and security/bug upgrades planned. There have be= en proposals (in the UK?) of making vendors of IoT equipment state their su= pport commitment, so that a purchaser can choose "cheap" or "= ;lasts a lifetime". Unfortunately, industry advocacy is often for mini= mal regulation - there's an opportunity here for ISOC and others to mak= e a difference.

One reason for not upgrading: OS d= ependencies. Apple Big Sur (and Catalina) broke a lot of printer drivers, s= o I had a choice: Upgrade my OS or keep my printer working. Dell, the distr= ibutor of the printers (made by Fuji-Xerox, apparently) simply states that = "due to circumstances beyond their control", they won't be pr= oviding any Catalina/Big Sur printer drivers.

Give= n that most commercial systems are now assembled out of open-source compone= nts, with customization or glue on top, you'd want some kind of automat= ed component checker. "17 of your components have not committed to lon= g-term support. Are you prepared to fix them yourselves?"
I don't know if this is feasible in all cases, but I suspe= ct we often know that certain technologies are getting long in the tooth. T= hey are not quite obsolete (historic) yet, but there's no active develo= pment or community and they probably shouldn't be components that can&#= 39;t be replaced in the field. No need (or resources) to do this for every = RFC, but identifying critical pieces of technology and providing a support = roadmap would be helpful, I think.

On Mon, Dec 7, 2020 at 4:19 AM Toerless E= ckert <tte@cs.fau.de> wrote:
=
Great pportunity fo= r a rant:

Its easy to understand how the mayority of participants in these discussion= s are
from either a commercial supplier side, or from a commercial user side. In = either
case, a clearly time restricted use case scenario is easily be most importa= nt default.
This btw. also applies to where my pay check comes from (i think).

Nevertheless, i would highly recommend to no limit our design decisions to = this
scenarios.

Personally, i for once would be happy as an individual to see any standards= be
blackmailed in the press and in public as an evil conspiracy for planned ob= solescence
that does not consider the ability for devices to operate as long as their = hardware can
without being constrained by 'security' software.

Obviously, there are also significant commercial applications undetermined = long
life cycles are required. Just think of any deep space exploration NASA sat= ellites
go dark because of their non-crypto agility. Or the non-desire to upgrade n= uclear
missile control systems to new HW/SW because overall system security analys= is
shows how new HW/SW more likely than not will be MORE susceptible to attack= s than
simpler older SW/HW around for 50 years. Just two extreme examples.

I am not 10% sure about generic approaches to solve this problem, but one a= pproach
could be the following:

- A device communications is designed to be able to operate solely within a=
=C2=A0 "walled garden" environment. Not as the ONLY option, but a= s one option.

- Walled garden means that all communication channels of the device can be = directed
=C2=A0 to go through other nodes of the "walled garden".

- "Walled garden" should IMHO also mean that the higher layer sem= antic of
=C2=A0 all communications is well enough defined/documented, so that anothe= r device
=C2=A0 in the walled-garden can be set up to convert/proxy the communicatio= ns.

- Aka: If the crypto starts to become obsolete, then the obsolete crypto wo= uld
=C2=A0 be possible to constrain to the walled-carden (physical security) en= vironment,
=C2=A0 and be proxied, and if the original remote communication parties do = not exist
=C2=A0 anymore, but the data to be exchanged exists, then such a proxy coul= d also
=C2=A0 proxy/convert the data into the 'legacy' format.

The ability to understand all the information communicated well enough to b= e able
to re-recreate the format is also necessary for any type of higher-layer se= curity
filtering, so this type of communications design is not only good for longe= vity,
but also for security beyond transit confidentiality.

Cheers
=C2=A0 =C2=A0 Toerless

On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote:
>
> > On 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:
> >
> > to improve the math one would have to amortize the cost of mainte= nance
> > over many many flavors and makers of thingies.=C2=A0 so the acme = thingie mfr,
> > and the hackme thingie mfr, and the ... need to have a common cod= e base
> > and upgrade infrastructure.=C2=A0
>
>
> Exactly right, it???s hard to imagine any other economically viable wa= y of maintaining devices which aren???t sold with a service contract. Even = for devices which are sold with a service contract, this is still a cheaper= and likely better way of delivering the security maintenance part of that = service.
>
> There???s a few commercial products which do this. They essentially of= fer modules with an OS and application environment which they maintain for = you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, El= ectric Imp, Ubuntu Core. They don???t maintain your application but that ma= y well be a relatively small part of the attack surface, and possibly defen= ded by features of the maintained environment.
>
> Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM cost = of the module, there???s no service fee.
>
> Amyas

> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000c16a0705b5e0d99f-- From nobody Mon Dec 7 08:43:58 2020 Return-Path: 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 1ACDF3A0FC2 for ; Mon, 7 Dec 2020 08:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mm9zsJHJdyt3 for ; Mon, 7 Dec 2020 08:43:51 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58E83A1458 for ; Mon, 7 Dec 2020 08:43:50 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id v22so14403330edt.9 for ; Mon, 07 Dec 2020 08:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xp6fVrKPalQphE4abU7DWfbY+FeqHSd6/tNq/UNw1ic=; b=g6N3tepOJ9IdSR8DR6L312bcz/CqyKa1EggQnQekJ1UXAUlPQ4t29vqmTMZCRuMPO8 pF/pX6HmmT39hzI3JH3bpHf5hIbRdkUfXLbnxWfxPiF1r4W5xL3a1vppUd+ZS0DIUJx9 Bx66aP6qg0pumkhPK6c8NMzpAob9KZNUSih/ChZd0G5xXossWT0WgFsVZA+2X3BSF5Ih fiu4Su0AhMRrzFaujuIpLOgf+wu+Xtez2L+swO4kDFHnUqKz+dx56Lc5Cb8tokTfM8L4 WRwomYohCGZgZJWGLFljfawwmuzo3PKbfkE0MTdjhKz0mu/Kk79lT6HnhRGtwBGbRgra McUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xp6fVrKPalQphE4abU7DWfbY+FeqHSd6/tNq/UNw1ic=; b=E96j8azVNmYqpWkRLT5+ZZ16pm2Y/zVAcIWBjKP6ziGJHPHqF/jwITP9FRYr1hYDfd bT1PBmsKKVjlXB6GgGyR3VCU9l6sJnfMZbKWeI5gQCSek+LKL9PVtPlmV/lY/y0q1qJ1 mdTZVHNMD3sle/swF3GhSn4aJXCNcq/mLtMoYpi5nH7D8TPJc4x1SHZdnnbUMpZLpyj/ R4wgCITjrhoaCsJohHbX82F6K6fiNZuL2O3wmW4j+L5kW/3PZHqvpfSkUjdA2SDWOwrv 1jMxgDd6gDdL4g+DZqRpUHOgnqxvvlBXGGlaUlBBNlUR2BqM3C3XUDu8GvJOzbvSdef2 y5Sg== X-Gm-Message-State: AOAM532KwTcy/rTGckSeptAAm/iVk3SAc9kHvBLcg5ej6VbmJnSv3Y1o lTImuUzxL3/rNGfOsxhVubm5S/xvFus5MlkH9YQ= X-Google-Smtp-Source: ABdhPJxNH+X+pxy8ofJcryFo59eO+xmVZP26gyODPf/4oX+PAoOmCrM2kFM95qXRiwxIqKe2Zr3LzK/MqXUK31w8HhI= X-Received: by 2002:aa7:c3cf:: with SMTP id l15mr10960081edr.282.1607359429107; Mon, 07 Dec 2020 08:43:49 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> In-Reply-To: From: =?UTF-8?B?U8OhdnlvIFZpbsOtY2l1cw==?= Date: Mon, 7 Dec 2020 13:43:37 -0300 Message-ID: To: Henning Schulzrinne Cc: Toerless Eckert , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Amyas Phillips , Randy Bush , "Ackermann, Michael" Content-Type: multipart/alternative; boundary="000000000000cc646605b5e2873c" Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:43:56 -0000 --000000000000cc646605b5e2873c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another point we need to pay attention to is the situation of the SMEs running in the local market of in-development-countries. These companies are in a vulnerable position and can, after just launching a device, close due to bankruptcy, shortening the device update life cycle. People who just bought the device will not just discard the expensive device, even knowing about the risks -- when the most probable is they never know about them. I really believe in the efficacy of an open source-based approach, but there is a long way to develop a consistent framework (including community, regulation, best practices, and other relevant stuff) to do it. Still in this context, regulatory approaches need much attention because they can be restrictive to those companies, and contribute to more bankruptcies. Another approach that can be taken is by creating a kind of contractual best practices (maybe informational RFCs?) for advising different sectors on what kind of terms they need to care about when building or buying solutions. But this brings the challenge of how to make this information reach the intended targets that are out of the IETF scope. Em seg., 7 de dez. de 2020 =C3=A0s 11:43, Henning Schulzrinne < hgs@cs.columbia.edu> escreveu: > It used to be that vendors announced end-of-life for products years after > introduction. For example, there was no way for a purchaser of Windows NT > to know, at purchase time, how long Microsoft was intending to support th= e > operating system. Now, better vendors seem to have started to make some > commitments, e.g., "this Android phone will receive new versions of the O= S > for three releases and security updates until 2025". All the major Linux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposals (i= n > the UK?) of making vendors of IoT equipment state their support commitmen= t, > so that a purchaser can choose "cheap" or "lasts a lifetime". > Unfortunately, industry advocacy is often for minimal regulation - there'= s > an opportunity here for ISOC and others to make a difference. > > One reason for not upgrading: OS dependencies. Apple Big Sur (and > Catalina) broke a lot of printer drivers, so I had a choice: Upgrade my O= S > or keep my printer working. Dell, the distributor of the printers (made b= y > Fuji-Xerox, apparently) simply states that "due to circumstances beyond > their control", they won't be providing any Catalina/Big Sur printer > drivers. > > Given that most commercial systems are now assembled out of open-source > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committed to > long-term support. Are you prepared to fix them yourselves?" > > I don't know if this is feasible in all cases, but I suspect we often kno= w > that certain technologies are getting long in the tooth. They are not qui= te > obsolete (historic) yet, but there's no active development or community a= nd > they probably shouldn't be components that can't be replaced in the field= . > No need (or resources) to do this for every RFC, but identifying critical > pieces of technology and providing a support roadmap would be helpful, I > think. > > On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > >> Great pportunity for a rant: >> >> Its easy to understand how the mayority of participants in these >> discussions are >> from either a commercial supplier side, or from a commercial user side. >> In either >> case, a clearly time restricted use case scenario is easily be most >> important default. >> This btw. also applies to where my pay check comes from (i think). >> >> Nevertheless, i would highly recommend to no limit our design decisions >> to this >> scenarios. >> >> Personally, i for once would be happy as an individual to see any >> standards be >> blackmailed in the press and in public as an evil conspiracy for planned >> obsolescence >> that does not consider the ability for devices to operate as long as >> their hardware can >> without being constrained by 'security' software. >> >> Obviously, there are also significant commercial applications >> undetermined long >> life cycles are required. Just think of any deep space exploration NASA >> satellites >> go dark because of their non-crypto agility. Or the non-desire to upgrad= e >> nuclear >> missile control systems to new HW/SW because overall system security >> analysis >> shows how new HW/SW more likely than not will be MORE susceptible to >> attacks than >> simpler older SW/HW around for 50 years. Just two extreme examples. >> >> I am not 10% sure about generic approaches to solve this problem, but on= e >> approach >> could be the following: >> >> - A device communications is designed to be able to operate solely withi= n >> a >> "walled garden" environment. Not as the ONLY option, but as one option= . >> >> - Walled garden means that all communication channels of the device can >> be directed >> to go through other nodes of the "walled garden". >> >> - "Walled garden" should IMHO also mean that the higher layer semantic o= f >> all communications is well enough defined/documented, so that another >> device >> in the walled-garden can be set up to convert/proxy the communications= . >> >> - Aka: If the crypto starts to become obsolete, then the obsolete crypto >> would >> be possible to constrain to the walled-carden (physical security) >> environment, >> and be proxied, and if the original remote communication parties do no= t >> exist >> anymore, but the data to be exchanged exists, then such a proxy could >> also >> proxy/convert the data into the 'legacy' format. >> >> The ability to understand all the information communicated well enough t= o >> be able >> to re-recreate the format is also necessary for any type of higher-layer >> security >> filtering, so this type of communications design is not only good for >> longevity, >> but also for security beyond transit confidentiality. >> >> Cheers >> Toerless >> >> On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: >> > >> > > On 5 Dec 2020, at 18:10, Randy Bush wrote: >> > > >> > > to improve the math one would have to amortize the cost of maintenan= ce >> > > over many many flavors and makers of thingies. so the acme thingie >> mfr, >> > > and the hackme thingie mfr, and the ... need to have a common code >> base >> > > and upgrade infrastructure. >> > >> > >> > Exactly right, it???s hard to imagine any other economically viable wa= y >> of maintaining devices which aren???t sold with a service contract. Even >> for devices which are sold with a service contract, this is still a chea= per >> and likely better way of delivering the security maintenance part of tha= t >> service. >> > >> > There???s a few commercial products which do this. They essentially >> offer modules with an OS and application environment which they maintain >> for you, to a more or less hands-off degree: msoft Sphere, Balena, >> Particle, Electric Imp, Ubuntu Core. They don???t maintain your applicat= ion >> but that may well be a relatively small part of the attack surface, and >> possibly defended by features of the maintained environment. >> > >> > Microsoft Sphere in particular is interesting because the maintenance >> is completely hands off and the costs are folded into the initial BOM co= st >> of the module, there???s no service fee. >> > >> > Amyas >> >> > -- >> > Iotops mailing list >> > Iotops@ietf.org >> > https://www.ietf.org/mailman/listinfo/iotops >> >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> > -- > Iotops mailing list > Iotops@ietf.org > https://www.ietf.org/mailman/listinfo/iotops > --000000000000cc646605b5e2873c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Another point we need to pay attention to is the situation= of the SMEs running in the local market of in-development-countries.
Th= ese companies are in a vulnerable position and can, after just launching a = device, close due to bankruptcy, shortening the device update life cycle.People who just bought the device will not just discard the expensive dev= ice, even knowing about the risks -- when the most probable is they never k= now about them.

I really believe in the efficacy of an open source-b= ased approach, but there is a long way to develop a consistent framework (i= ncluding community, regulation, best practices, and other relevant stuff) t= o do it.
Still in this context, regulatory approaches need much attentio= n because they can be restrictive to those companies, and contribute to mor= e bankruptcies.

Another approach that can be taken is by creating a = kind of contractual best practices (maybe informational RFCs?) for advising= different sectors on what kind of terms they need to care about when build= ing or buying solutions. But this brings the challenge of how to make this = information reach the intended targets that are out of the IETF scope.
<= div>

Em seg., 7 de dez. de 2020 =C3=A0s 11:43, Henning Schulzrinne <= ;hgs@cs.columbia.edu> escreve= u:
It used to be that vendors announced end-of-life for products year= s after introduction. For example, there was no way for a purchaser of Wind= ows NT to know, at purchase time, how long Microsoft was intending to suppo= rt the operating system. Now, better vendors seem to have started to make s= ome commitments, e.g., "this Android phone will receive new versions o= f the OS for three releases and security updates until 2025". All the = major Linux distributions now have some kind of an LTS version, with long-t= erm stability and security/bug upgrades planned. There have been proposals = (in the UK?) of making vendors of IoT equipment state their support commitm= ent, so that a purchaser can choose "cheap" or "lasts a life= time". Unfortunately, industry advocacy is often for minimal regulatio= n - there's an opportunity here for ISOC and others to make a differenc= e.

One reason for not upgrading: OS dependencies. = Apple Big Sur (and Catalina) broke a lot of printer drivers, so I had a cho= ice: Upgrade my OS or keep my printer working. Dell, the distributor of the= printers (made by Fuji-Xerox, apparently) simply states that "due to = circumstances beyond their control", they won't be providing any C= atalina/Big Sur printer drivers.

Given that most c= ommercial systems are now assembled out of open-source components, with cus= tomization or glue on top, you'd want some kind of automated component = checker. "17 of your components have not committed to long-term suppor= t. Are you prepared to fix them yourselves?"

= I don't know if this is feasible in all cases, but I suspect we often k= now that certain technologies are getting long in the tooth. They are not q= uite obsolete (historic) yet, but there's no active development or comm= unity and they probably shouldn't be components that can't be repla= ced in the field. No need (or resources) to do this for every RFC, but iden= tifying critical pieces of technology and providing a support roadmap would= be helpful, I think.

On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert <tte@cs.fau.de> wrote= :
Great pportuni= ty for a rant:

Its easy to understand how the mayority of participants in these discussion= s are
from either a commercial supplier side, or from a commercial user side. In = either
case, a clearly time restricted use case scenario is easily be most importa= nt default.
This btw. also applies to where my pay check comes from (i think).

Nevertheless, i would highly recommend to no limit our design decisions to = this
scenarios.

Personally, i for once would be happy as an individual to see any standards= be
blackmailed in the press and in public as an evil conspiracy for planned ob= solescence
that does not consider the ability for devices to operate as long as their = hardware can
without being constrained by 'security' software.

Obviously, there are also significant commercial applications undetermined = long
life cycles are required. Just think of any deep space exploration NASA sat= ellites
go dark because of their non-crypto agility. Or the non-desire to upgrade n= uclear
missile control systems to new HW/SW because overall system security analys= is
shows how new HW/SW more likely than not will be MORE susceptible to attack= s than
simpler older SW/HW around for 50 years. Just two extreme examples.

I am not 10% sure about generic approaches to solve this problem, but one a= pproach
could be the following:

- A device communications is designed to be able to operate solely within a=
=C2=A0 "walled garden" environment. Not as the ONLY option, but a= s one option.

- Walled garden means that all communication channels of the device can be = directed
=C2=A0 to go through other nodes of the "walled garden".

- "Walled garden" should IMHO also mean that the higher layer sem= antic of
=C2=A0 all communications is well enough defined/documented, so that anothe= r device
=C2=A0 in the walled-garden can be set up to convert/proxy the communicatio= ns.

- Aka: If the crypto starts to become obsolete, then the obsolete crypto wo= uld
=C2=A0 be possible to constrain to the walled-carden (physical security) en= vironment,
=C2=A0 and be proxied, and if the original remote communication parties do = not exist
=C2=A0 anymore, but the data to be exchanged exists, then such a proxy coul= d also
=C2=A0 proxy/convert the data into the 'legacy' format.

The ability to understand all the information communicated well enough to b= e able
to re-recreate the format is also necessary for any type of higher-layer se= curity
filtering, so this type of communications design is not only good for longe= vity,
but also for security beyond transit confidentiality.

Cheers
=C2=A0 =C2=A0 Toerless

On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote:
>
> > On 5 Dec 2020, at 18:10, Randy Bush <randy@psg.com> wrote:
> >
> > to improve the math one would have to amortize the cost of mainte= nance
> > over many many flavors and makers of thingies.=C2=A0 so the acme = thingie mfr,
> > and the hackme thingie mfr, and the ... need to have a common cod= e base
> > and upgrade infrastructure.=C2=A0
>
>
> Exactly right, it???s hard to imagine any other economically viable wa= y of maintaining devices which aren???t sold with a service contract. Even = for devices which are sold with a service contract, this is still a cheaper= and likely better way of delivering the security maintenance part of that = service.
>
> There???s a few commercial products which do this. They essentially of= fer modules with an OS and application environment which they maintain for = you, to a more or less hands-off degree: msoft Sphere, Balena, Particle, El= ectric Imp, Ubuntu Core. They don???t maintain your application but that ma= y well be a relatively small part of the attack surface, and possibly defen= ded by features of the maintained environment.
>
> Microsoft Sphere in particular is interesting because the maintenance = is completely hands off and the costs are folded into the initial BOM cost = of the module, there???s no service fee.
>
> Amyas

> --
> Iotops mailing list
> Iotops@ietf.org
> https://www.ietf.org/mailman/listinfo/iotops

--
---
tte@cs.fau.de

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--
Iotops mailing list
Iotops@ietf.org https://www.ietf.org/mailman/listinfo/iotops
--000000000000cc646605b5e2873c-- From nobody Mon Dec 7 08:49:21 2020 Return-Path: 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 DD3F03A0FC2; Mon, 7 Dec 2020 08:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9Cr9p_DHfdTY; Mon, 7 Dec 2020 08:49:14 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5383A12E7; Mon, 7 Dec 2020 08:49:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kmJgz-0002YG-Nu; Mon, 07 Dec 2020 16:48:53 +0000 Date: Mon, 07 Dec 2020 08:48:52 -0800 Message-ID: From: Randy Bush To: =?ISO-8859-1?Q?=22S=E1vyo_Vin=EDcius=22?= Cc: Henning Schulzrinne , Toerless Eckert , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Amyas Phillips , "Ackermann, Michael" In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:49:16 -0000 > I really believe in the efficacy of an open source-based approach, but > there is a long way to develop a consistent framework (including community, > regulation, best practices, and other relevant stuff) to do it. https://xkcd.com/2347/ From nobody Mon Dec 7 08:57:05 2020 Return-Path: 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 E05793A12E7 for ; Mon, 7 Dec 2020 08:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 SQhDFhIqKUBn for ; Mon, 7 Dec 2020 08:57:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0EC3A139A for ; Mon, 7 Dec 2020 08:57:00 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A5BA2549B45; Mon, 7 Dec 2020 17:56:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 9F974440041; Mon, 7 Dec 2020 17:56:54 +0100 (CET) Date: Mon, 7 Dec 2020 17:56:54 +0100 From: Toerless Eckert To: Henning Schulzrinne Cc: Amyas Phillips , iotops@ietf.org, Ted Lemon , architecture-discuss@iab.org, Randy Bush , "Ackermann, Michael" Message-ID: <20201207165654.GF44833@faui48f.informatik.uni-erlangen.de> References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 16:57:04 -0000 When i buy a glass or marmelade, the packaging indicates all the ingredients and epecially also all aditives. So i can kinda be an educated consumer. I i am always thinking that i would like similar labelling for equivalent, especially about the (external) dependencies to continue operating the device. Yes, there are all type of devices, and you mention one extreme, which are general purpose devices (mobile phones). Even when i have an embedded device with android, the dependencies to keep it running will typically be much more constrained but difficult to understand for most users. Maybe an organization like IETF could first start to document the problem of such external dependencies. Taxonomy etc. pp. Starting with the most obvious problem of certificate management. Then dependencies against external protocol peers, possible cloud-services, crypto-agility... E.g.: If you had to decide between two different options for one type of device and you where worried about longevity: whats all the stuff you would need to know about it, and which pieces would make a difference. IMHO, this is all way too much in its infancy to think about regulation i think. Once three is a better and broader agreement as to what the best practices are for apsects in support of longevity... then one could think about supportive measures to encourage vendors. Cheers Toerless On Mon, Dec 07, 2020 at 09:43:07AM -0500, Henning Schulzrinne wrote: > It used to be that vendors announced end-of-life for products years after > introduction. For example, there was no way for a purchaser of Windows NT > to know, at purchase time, how long Microsoft was intending to support the > operating system. Now, better vendors seem to have started to make some > commitments, e.g., "this Android phone will receive new versions of the OS > for three releases and security updates until 2025". All the major Linux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposals (in > the UK?) of making vendors of IoT equipment state their support commitment, > so that a purchaser can choose "cheap" or "lasts a lifetime". > Unfortunately, industry advocacy is often for minimal regulation - there's > an opportunity here for ISOC and others to make a difference. > > One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina) > broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my > printer working. Dell, the distributor of the printers (made by Fuji-Xerox, > apparently) simply states that "due to circumstances beyond their control", > they won't be providing any Catalina/Big Sur printer drivers. > > Given that most commercial systems are now assembled out of open-source > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committed to > long-term support. Are you prepared to fix them yourselves?" > > I don't know if this is feasible in all cases, but I suspect we often know > that certain technologies are getting long in the tooth. They are not quite > obsolete (historic) yet, but there's no active development or community and > they probably shouldn't be components that can't be replaced in the field. > No need (or resources) to do this for every RFC, but identifying critical > pieces of technology and providing a support roadmap would be helpful, I > think. > > On Mon, Dec 7, 2020 at 4:19 AM Toerless Eckert wrote: > > > Great pportunity for a rant: > > > > Its easy to understand how the mayority of participants in these > > discussions are > > from either a commercial supplier side, or from a commercial user side. In > > either > > case, a clearly time restricted use case scenario is easily be most > > important default. > > This btw. also applies to where my pay check comes from (i think). > > > > Nevertheless, i would highly recommend to no limit our design decisions to > > this > > scenarios. > > > > Personally, i for once would be happy as an individual to see any > > standards be > > blackmailed in the press and in public as an evil conspiracy for planned > > obsolescence > > that does not consider the ability for devices to operate as long as their > > hardware can > > without being constrained by 'security' software. > > > > Obviously, there are also significant commercial applications undetermined > > long > > life cycles are required. Just think of any deep space exploration NASA > > satellites > > go dark because of their non-crypto agility. Or the non-desire to upgrade > > nuclear > > missile control systems to new HW/SW because overall system security > > analysis > > shows how new HW/SW more likely than not will be MORE susceptible to > > attacks than > > simpler older SW/HW around for 50 years. Just two extreme examples. > > > > I am not 10% sure about generic approaches to solve this problem, but one > > approach > > could be the following: > > > > - A device communications is designed to be able to operate solely within a > > "walled garden" environment. Not as the ONLY option, but as one option. > > > > - Walled garden means that all communication channels of the device can be > > directed > > to go through other nodes of the "walled garden". > > > > - "Walled garden" should IMHO also mean that the higher layer semantic of > > all communications is well enough defined/documented, so that another > > device > > in the walled-garden can be set up to convert/proxy the communications. > > > > - Aka: If the crypto starts to become obsolete, then the obsolete crypto > > would > > be possible to constrain to the walled-carden (physical security) > > environment, > > and be proxied, and if the original remote communication parties do not > > exist > > anymore, but the data to be exchanged exists, then such a proxy could > > also > > proxy/convert the data into the 'legacy' format. > > > > The ability to understand all the information communicated well enough to > > be able > > to re-recreate the format is also necessary for any type of higher-layer > > security > > filtering, so this type of communications design is not only good for > > longevity, > > but also for security beyond transit confidentiality. > > > > Cheers > > Toerless > > > > On Sat, Dec 05, 2020 at 09:11:04PM +0000, Amyas Phillips wrote: > > > > > > > On 5 Dec 2020, at 18:10, Randy Bush wrote: > > > > > > > > to improve the math one would have to amortize the cost of maintenance > > > > over many many flavors and makers of thingies. so the acme thingie > > mfr, > > > > and the hackme thingie mfr, and the ... need to have a common code base > > > > and upgrade infrastructure. > > > > > > > > > Exactly right, it???s hard to imagine any other economically viable way > > of maintaining devices which aren???t sold with a service contract. Even > > for devices which are sold with a service contract, this is still a cheaper > > and likely better way of delivering the security maintenance part of that > > service. > > > > > > There???s a few commercial products which do this. They essentially > > offer modules with an OS and application environment which they maintain > > for you, to a more or less hands-off degree: msoft Sphere, Balena, > > Particle, Electric Imp, Ubuntu Core. They don???t maintain your application > > but that may well be a relatively small part of the attack surface, and > > possibly defended by features of the maintained environment. > > > > > > Microsoft Sphere in particular is interesting because the maintenance is > > completely hands off and the costs are folded into the initial BOM cost of > > the module, there???s no service fee. > > > > > > Amyas > > > > > -- > > > Iotops mailing list > > > Iotops@ietf.org > > > https://www.ietf.org/mailman/listinfo/iotops > > > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- --- tte@cs.fau.de From nobody Mon Dec 7 13:17:01 2020 Return-Path: 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 A5EE73A0B04 for ; Mon, 7 Dec 2020 13:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=Ulhr2jJf; dkim=pass (2048-bit key) header.d=taugh.com header.b=Z+ODsB1q 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 dX4dxvJWODdo for ; Mon, 7 Dec 2020 13:16:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8747F3A0A4A for ; Mon, 7 Dec 2020 13:16:57 -0800 (PST) Received: (qmail 24817 invoked from network); 7 Dec 2020 21:16:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=60ef.5fce9bc5.k2012; bh=+pjk+5CsvMIFgvLEqlTwiOr2MoUnrnWYTsBbDjwLeKg=; b=Ulhr2jJfKP33x2gEGudNyYWfo80RKXxdtr6GZvboCB+bsOF2h6IkBpE4Eb/2xHuxeGjO9J3gNJkD5t2Ualqt9EUHB6uu5VRYdWZUih2eoLGJ7sqBefxC5cIxk5vVTr5yxIz9Y4nJ17hyBqPqX8Hu2LXMxsJ2F7X0uXJfyGyCLswgHR6a7V32t3bF8UmKFRAgLhmI4PDoULaDJo+RYWecwJi5YfA6gzYYfhougzuCVqwObwm27eMxfcha1ka6dYwUgCFHdLC3ArTOT2ueUc+IEgimj1V8rj0hVw3qo/iy3GAbHLvYgtAqKQ/Dp5UYhWORpgt/Ni69HVZtpFwEVPZCfg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=60ef.5fce9bc5.k2012; bh=+pjk+5CsvMIFgvLEqlTwiOr2MoUnrnWYTsBbDjwLeKg=; b=Z+ODsB1qxf/RS5aBk/rjysol9i/Wt3wExXMI1WN2KHd9KjGtWreaDoREki1XHDnecaZa9Mive4OKVAub5fTSONAPK1afaa+bMLe8TCP42ECMTwo9TgJg4LYUaz1B2U9oXEUeSHNZ5p3gzzsp6bVJ+BJvcTzok/2aILkMjPzieYI4g29qa5i604XgqEAR18dikyVyPzzpvXy2+jEgBy3pmGXgqKYCIaQUhQjzPM4N8I00CV0zd/1F+fCdqeWOkrcuUgaa0FxgqP6LVQBvE47TJzQVlOSM2S1tCZ9OYL6kDjzncFqRp6xlyKF/LZoDudhr6845ycYA71g+uhfCkqT6lA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 Dec 2020 21:16:53 -0000 Received: by ary.qy (Postfix, from userid 501) id 1140729224BB; Mon, 7 Dec 2020 16:16:52 -0500 (EST) Date: 7 Dec 2020 16:16:52 -0500 Message-Id: <20201207211653.1140729224BB@ary.qy> From: "John Levine" To: architecture-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 21:17:00 -0000 In article you write: > >One reason for not upgrading: OS dependencies. Apple Big Sur (and Catalina) >broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep my >printer working. Dell, the distributor of the printers (made by Fuji-Xerox, >apparently) simply states that "due to circumstances beyond their control", >they won't be providing any Catalina/Big Sur printer drivers. Catalina broke a lot of applications, too, when it ended support for 32 bit x86 code. I waited most of a year until the text editor I used, Lugaru Epsilon, put out a new 64 bit update. I also have an old laptop running Windows 7. It's pretty slow but it works OK and I'm not inclined to pay for Windows 10 which will make it even slower. The whole software update process has deeply perverse incentives. I can understand why software vendors are not eager to support software running on ten year old equipment, but outside the computer world, ten years is not very long. Yesterday my wife brought me a table lamp her mother bought around 1960 where the cord had frayed. The cord was pretty long so I snipped off the frayed part, carefully peeled off the felt that was glued to the bottom of the lamp, removed the socket and took it apart with a screwdriver, attached the new end of the cord to the socket, put it back together, unscrewed and remounted the cord-mounted switch, put the felt back with double-stick tape, and it's probably good for another 60 years. Oh, and I replaced the old CF bulb with a lower wattage LED which fits in the same socket. Will we ever have computers like that? I'm not holding my breath. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Dec 7 13:35:58 2020 Return-Path: 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 13B183A0B2E for ; Mon, 7 Dec 2020 13:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=columbia.edu 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 l17-BuxRAdis for ; Mon, 7 Dec 2020 13:35:55 -0800 (PST) Received: from mx0b-00364e01.pphosted.com (mx0b-00364e01.pphosted.com [148.163.139.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8813A0B35 for ; Mon, 7 Dec 2020 13:35:54 -0800 (PST) Received: from pps.filterd (m0167073.ppops.net [127.0.0.1]) by mx0b-00364e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0B7LXxSg001718 for ; Mon, 7 Dec 2020 16:35:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=columbia.edu; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=pps01; bh=AyDWn1uU4NGgxFbNIlG1gyNGg8+fhXDH/Mzwj55Onto=; b=qEwJYKtkzS1eZVXk8saMoT/ad044Uar6uDD0NjnxjB+W+3YJh37DqdHszJ3D7qL+uXLw XkJ4HHs8YWtdnHK9IJ16V+RgUeaFiGkVJRt7xJ6xMbV/tY+yq1c19rC+Z9QKOlu3wv5e 18GSwmpndhEOvvVOYDYstnq4mRaTRZJwsD719D6/hiLOYOTp2qCXc9XY/ldgbqrgvJVF r8znXYXg1LD2eUggqS0EC8t9kF7/UgraLB+ywKaBkyMnfUfHRX5t/Bq90jauVF9duegX C10me6NSL5CnLTwcFZPBA4RhrsPbpkGFOD3gBO0dk6LvJMzFOoSb7avNb6NC7UU4+Qg5 tw== Received: from sendprodmail12.cc.columbia.edu (sendprodmail12.cc.columbia.edu [128.59.72.20]) by mx0b-00364e01.pphosted.com with ESMTP id 3586yjn2a2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 Dec 2020 16:35:54 -0500 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by sendprodmail12.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B7LZrcA057710 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 7 Dec 2020 16:35:53 -0500 Received: by mail-qk1-f197.google.com with SMTP id a68so7049021qke.9 for ; Mon, 07 Dec 2020 13:35:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AyDWn1uU4NGgxFbNIlG1gyNGg8+fhXDH/Mzwj55Onto=; b=EUCpu2b62RFR1b8L/E294oNtG3njK7NwHvG1Tn9NffofdahO3gwL5Bid90P1IU0ilw vjQLkVp0tl4abeiK2U0sPVsfm2DRspNK4dKouBA9h8bR5jvA8PhpZ2Fx3edjkijjSpgZ 7pC9l3tsnBK5eH/LBn4ifsLmWQfc119WYwI60nuWAkTsQiDrB7bE8mXiwc/lXvBwhEW2 svgbjujhEoHdmXzixSlhmuHwm8iWVzt5De8rMV9DG2FiO8dM5jjfh6pKj4wKmKiisIuT mPkYylJPWt67HONjeIVOQxzP4RA7WkghVbg/al6F/NCVtBs2A18fbSPUBlKvA752Tx1z yDLw== X-Gm-Message-State: AOAM533ohJLFONwLxKlvMs7xWxJPRIZHuPA0fg5ZaWoASUqmvW1Bd+Lh /Rh6q54jpBdMx/pX8GE4war3D4nOvMHhTDvKmBERpGrMjTbNQ5tfDGBSHsLnjx4lfv8UHnluHLl yvWF/4AuWr+QyRXQSmknwNvZsxPRioBzv7+s4aW6UUs/RJVmFLQ== X-Received: by 2002:ac8:4e4c:: with SMTP id e12mr26250225qtw.164.1607376952536; Mon, 07 Dec 2020 13:35:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJxc8e3sP2b89KOvv25D8JwEVX4yvFLh3/yTdlDq0ByrPeo5frVjGEts7kQjzjISkCOxsr5ALOzONpl+yGRzAJA= X-Received: by 2002:ac8:4e4c:: with SMTP id e12mr26250198qtw.164.1607376952209; Mon, 07 Dec 2020 13:35:52 -0800 (PST) MIME-Version: 1.0 References: <20201207211653.1140729224BB@ary.qy> In-Reply-To: <20201207211653.1140729224BB@ary.qy> From: Henning Schulzrinne Date: Mon, 7 Dec 2020 16:35:25 -0500 Message-ID: To: John Levine Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="00000000000041d26205b5e69c0a" X-CU-OB: Yes X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_16:2020-12-04, 2020-12-07 signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 malwarescore=0 priorityscore=1501 phishscore=0 adultscore=0 spamscore=0 clxscore=1011 bulkscore=10 lowpriorityscore=10 mlxscore=0 impostorscore=10 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012070139 Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 21:35:57 -0000 --00000000000041d26205b5e69c0a Content-Type: text/plain; charset="UTF-8" For peripherals, this would seem wholly avoidable - the printer protocol hasn't changed, the format of the printer format bits hasn't changed (still PCL6), but it still doesn't work. Apple could provide a few basic printer drivers - even if they don't support the fancier functionality. Indeed, if I pretend that my printer is an HP LaserJet (one of those few left), I can print, albeit only in black&white... This isn't about a particular printer or OS vendor, but even one critical peripheral can keep an obsolete system from getting upgraded. We've actually gotten better in some ways - document formats seem to last decades once they become mainstream (PDF and Word, not WordPerfect). Same for standards-based peripherals such as USB mice and keyboards. A 20-year-old USB keyboard may still work. On Mon, Dec 7, 2020 at 4:17 PM John Levine wrote: > In article LMbkH+JbkbQ_YkXS4GuccnbrVA@mail.gmail.com> you write: > > > >One reason for not upgrading: OS dependencies. Apple Big Sur (and > Catalina) > >broke a lot of printer drivers, so I had a choice: Upgrade my OS or keep > my > >printer working. Dell, the distributor of the printers (made by > Fuji-Xerox, > >apparently) simply states that "due to circumstances beyond their > control", > >they won't be providing any Catalina/Big Sur printer drivers. > > Catalina broke a lot of applications, too, when it ended support for > 32 bit x86 code. I waited most of a year until the text editor I used, > Lugaru Epsilon, put out a new 64 bit update. > > I also have an old laptop running Windows 7. It's pretty slow but it > works OK and I'm not inclined to pay for Windows 10 which will make it > even slower. > > The whole software update process has deeply perverse incentives. I > can understand why software vendors are not eager to support software > running on ten year old equipment, but outside the computer world, ten > years is not very long. > > Yesterday my wife brought me a table lamp her mother bought around > 1960 where the cord had frayed. The cord was pretty long so I snipped > off the frayed part, carefully peeled off the felt that was glued to > the bottom of the lamp, removed the socket and took it apart with a > screwdriver, attached the new end of the cord to the socket, put it > back together, unscrewed and remounted the cord-mounted switch, put > the felt back with double-stick tape, and it's probably good for > another 60 years. Oh, and I replaced the old CF bulb with a lower > wattage LED which fits in the same socket. > > Will we ever have computers like that? I'm not holding my breath. > > -- > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > --00000000000041d26205b5e69c0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For peripherals, this would seem wholly avoidable - t= he printer protocol hasn't changed, the format of the printer format bi= ts hasn't changed (still PCL6), but it still doesn't work. Apple co= uld provide a few basic printer drivers - even if they don't support th= e fancier functionality. Indeed, if I pretend that my printer is an HP Lase= rJet (one of those few left), I can print, albeit only in black&white..= . This isn't about a particular printer or OS vendor, but even one crit= ical peripheral can keep an obsolete system from getting upgraded.

We've actually gotten better in some ways - document f= ormats seem to last decades once they become mainstream (PDF and Word, not = WordPerfect). Same for standards-based peripherals such as USB mice and key= boards. A 20-year-old USB keyboard may still work.

On Mon, Dec 7, 2020 at 4:= 17 PM John Levine <johnl@taugh.com> wrote:
In = article <CACgrgBa+JMDBWWBotfQeJMc=3DLMbkH+JbkbQ_YkXS4GuccnbrVA@mai= l.gmail.com> you write:
>
>One reason for not upgrading: OS dependencies. Apple Big Sur (and Catal= ina)
>broke a lot of printer drivers, so I had a choice: Upgrade my OS or kee= p my
>printer working. Dell, the distributor of the printers (made by Fuji-Xe= rox,
>apparently) simply states that "due to circumstances beyond their = control",
>they won't be providing any Catalina/Big Sur printer drivers.

Catalina broke a lot of applications, too, when it ended support for
32 bit x86 code. I waited most of a year until the text editor I used,
Lugaru Epsilon, put out a new 64 bit update.

I also have an old laptop running Windows 7. It's pretty slow but it works OK and I'm not inclined to pay for Windows 10 which will make it<= br> even slower.

The whole software update process has deeply perverse incentives. I
can understand why software vendors are not eager to support software
running on ten year old equipment, but outside the computer world, ten
years is not very long.

Yesterday my wife brought me a table lamp her mother bought around
1960 where the cord had frayed. The cord was pretty long so I snipped
off the frayed part, carefully peeled off the felt that was glued to
the bottom of the lamp, removed the socket and took it apart with a
screwdriver, attached the new end of the cord to the socket, put it
back together, unscrewed and remounted the cord-mounted switch, put
the felt back with double-stick tape, and it's probably good for
another 60 years. Oh, and I replaced the old CF bulb with a lower
wattage LED which fits in the same socket.

Will we ever have computers like that?=C2=A0 I'm not holding my breath.=

--
Regards,
John Levine, johnl@tau= gh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
--00000000000041d26205b5e69c0a-- From nobody Mon Dec 7 14:25:01 2020 Return-Path: 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 B63623A0BD6 for ; Mon, 7 Dec 2020 14:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LFGdE3qTbnUQ for ; Mon, 7 Dec 2020 14:24:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5BC3A0BBC for ; Mon, 7 Dec 2020 14:24:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ACB6389AE; Mon, 7 Dec 2020 17:27:04 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2RqrNHfXwhZS; Mon, 7 Dec 2020 17:26:56 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 15592389AD; Mon, 7 Dec 2020 17:26:56 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 76CEB48F; Mon, 7 Dec 2020 17:24:47 -0500 (EST) From: Michael Richardson To: Henning Schulzrinne , iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:25:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Henning Schulzrinne wrote: > It used to be that vendors announced end-of-life for products years a= fter > introduction. For example, there was no way for a purchaser of Window= s NT > to know, at purchase time, how long Microsoft was intending to suppor= t the > operating system. Now, better vendors seem to have started to make so= me > commitments, e.g., "this Android phone will receive new versions of t= he OS > for three releases and security updates until 2025". All the major Li= nux > distributions now have some kind of an LTS version, with long-term > stability and security/bug upgrades planned. There have been proposal= s (in > the UK?) of making vendors of IoT equipment state their support commi= tment, > so that a purchaser can choose "cheap" or "lasts a lifetime". yes, that's in the upcoming legislation. This document hints at it: https://assets.publishing.service.gov.uk/government/uploads/system/upl= oads/attachment_data/file/773867/Code_of_Practice_for_Consumer_IoT_Security= _October_2018.pdf This was a call for views that ended in September: https://www.gov.uk/government/publications/proposals-for-regulating-consu= mer-smart-product-cyber-security-call-for-views/proposals-for-regulating-co= nsumer-smart-product-cyber-security-call-for-views Box 4 - Requirement 3 - Provide transparency on for how long, at a minimu= m, the product will receive security updates Exact wording and approach to be finalised The =E2=80=98defined support period=E2=80=99 for the relevant =E2=80=98pr= oduct=E2=80=99 shall be published in an =E2=80=98accessible way=E2=80=99 that is =E2=80=98clear and transpa= rent=E2=80=99. This clause aligns with provision 5.3-13 of European Telecommunications Standards Institute (ETSI) European Standard (EN) 303 645 v2.1.1. > One reason for not upgrading: OS dependencies. Apple Big Sur (and Cat= alina) > broke a lot of printer drivers, so I had a choice: Upgrade my OS or k= eep my > printer working. Dell, the distributor of the printers (made by Fuji-= Xerox, > apparently) simply states that "due to circumstances beyond their con= trol", > they won't be providing any Catalina/Big Sur printer drivers. My mom's computer is just "too old", yet it is perfectly functional. > Given that most commercial systems are now assembled out of open-sour= ce > components, with customization or glue on top, you'd want some kind of > automated component checker. "17 of your components have not committe= d to > long-term support. Are you prepared to fix them yourselves?" Some kind of expert system perhaps. Who'd pay to maintain this? And would it, itself, go out of support? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/Oq68ACgkQgItw+93Q 3WUtjAf/ZJpEJKbCj8J1vjx5O7upKjO1XOpWSbh+nDiSlh4GlgVLsN8A4/xUsbxu quCp01wA5Hs5Z06QdxsXPs31rVIpxJzjL/I7vI4+gwrxLH3tdyX3YP0FaWb2lS1t q0diUoEpkP4L6PgNFZrPYh2ifE2wn4QcSsw+pHp5g01YpMdlLGvz7WGJjlDm2WGK s2R7JkHLBKTEC+WfOxFPzhtOmysKKiKORvx9zlm98K4d7rc7EpMnJraHTPb1yIfE W1hkw15XfAJlS76w7JYJem4sQvEo9f/E5goZ4jIz+YNQL1+e47ipNFdfOqPviz3/ KnwzLSP5V6LXKCPFpx83ANKWND/BNA== =halJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 7 14:51:05 2020 Return-Path: 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 E03ED3A0C03 for ; Mon, 7 Dec 2020 14:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 18Qrz2CelWtL for ; Mon, 7 Dec 2020 14:50:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866D03A0C00 for ; Mon, 7 Dec 2020 14:50:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 676D7389B1; Mon, 7 Dec 2020 17:53:05 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QdLhGOrR7VOc; Mon, 7 Dec 2020 17:53:04 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CEBE8389AE; Mon, 7 Dec 2020 17:53:04 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 29FEC48F; Mon, 7 Dec 2020 17:50:56 -0500 (EST) From: Michael Richardson To: iotops@ietf.org, architecture-discuss@iab.org In-Reply-To: References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:51:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable S=C3=A1vyo Vin=C3=ADcius wrote: > I really believe in the efficacy of an open source-based approach, but > there is a long way to develop a consistent framework (including comm= unity, > regulation, best practices, and other relevant stuff) to do it. > Still in this context, regulatory approaches need much attention beca= use > they can be restrictive to those companies, and contribute to more > bankruptcies. http://geer.tinho.net/geer.blackhat.6viii14.txt and https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html What can the IETF do? Mostly what we are already doing, which is to make it cheaper and easier to build products where the clients and the servers don't have to be vertically integrated. ... some text to tease you into going to read/listen-to the whole thing: 3. Source code liability -- CHOICE Nat Howard said that "Security will always be exactly as bad as it can possibly be while allowing everything to still function,"[NH] but with each passing day, that "and still function" clause requires a higher standard. As Ken Thompson told us in his Turing Award lecture, there is no technical escape;[KT] in strict mathematical terms you neither trust a program nor a house unless you created it 100% yourself, but in reality most of us will trust a house built by a suitably skilled professional, usually we will trust it more than one we had built ourselves, and this even if we have never met the builder, or even if he is long since dead. The reason for this trust is that shoddy building work has had that crucial "or else ..." clause for more than 3700 years: If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death. -- Code of Hammurabi, approx 1750 B.C. Today the relevant legal concept is "product liability" and the fundamental formula is "If you make money selling something, then you better do it well, or you will be held responsible for the trouble it causes." For better or poorer, the only two products not covered by product liability today are religion and software, and software should not escape for much longer. Poul-Henning Kamp and I have a strawman proposal for how software liability regulation could be structured. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/Osc8ACgkQgItw+93Q 3WUEwQgAllCgXfNv9bgHtOUybXjNaVf+6UT73U7PGvq48h7o4PIhsgvRxSsTNtUG Gfaa86QFoiZjI1smnXVWT4Ce5VRb2J2REclxPjw5yj7a5K3M+hLbl4tV7qK8JPGp P1OmQnA3aKCYi4fs7sdU2m/vtIk/LYYtbBxo60pkQeAoYPCJRb7/IMvUs4GkCBTM l40DoO5nN+hA4lugmwUwYoLDWOhyRWhjviQlaOrqZpxXNHURMb7UvN1UcHc8TPg9 bkW05IzY+USedO5GqsSd/8rx/x4yQW6vZdvfYFvGW5O/iVHoAIuuKxjiiW+Y37SF cu8hVkoYLPtbaSeHiXElv++tiK76wg== =MyTt -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 7 21:43:18 2020 Return-Path: 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 774373A0E74 for ; Mon, 7 Dec 2020 21:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 tYAko1kBT9fg for ; Mon, 7 Dec 2020 21:43:13 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05E33A0E73 for ; Mon, 7 Dec 2020 21:43:13 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 66FE5549B09; Tue, 8 Dec 2020 06:43:07 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5EBE2440041; Tue, 8 Dec 2020 06:43:07 +0100 (CET) Date: Tue, 8 Dec 2020 06:43:07 +0100 From: Toerless Eckert To: John Levine Cc: architecture-discuss@ietf.org Message-ID: <20201208054307.GG44833@faui48f.informatik.uni-erlangen.de> References: <20201207211653.1140729224BB@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201207211653.1140729224BB@ary.qy> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 05:43:17 -0000 On Mon, Dec 07, 2020 at 04:16:52PM -0500, John Levine wrote: > Yesterday my wife brought me a table lamp her mother bought around > 1960 where the cord had frayed. The cord was pretty long so I snipped > off the frayed part, carefully peeled off the felt that was glued to > the bottom of the lamp, removed the socket and took it apart with a > screwdriver, attached the new end of the cord to the socket, put it > back together, unscrewed and remounted the cord-mounted switch, put > the felt back with double-stick tape, and it's probably good for > another 60 years. Oh, and I replaced the old CF bulb with a lower > wattage LED which fits in the same socket. > > Will we ever have computers like that? I'm not holding my breath. "Home" computers from the 80th continue to exist as virtual machines, their software will probably survive a lot of hardware/software from today: even if you would emulate todays hardware to run todays software in the future, it would be dependent on many unspecified network interactions nobody can reproduce in 20 years. Vice versa, when you buy a lamp today, its much more unlikely that it will have a replaceable, standard socket bulb. Instead more likely a "lifetime" proprietary LED module which will fail 1 usec after the manufacturer has stopped offering replacement parts. Not to speak of a quite exhaustive matrix of incompatibilities between different dimmer types and LED high-voltage converter circuit types. Cheers Toerless > -- > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Tue Dec 8 06:41:15 2020 Return-Path: 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 1A9703A0F0B for ; Tue, 8 Dec 2020 06:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qRxvdL3PG8vG for ; Tue, 8 Dec 2020 06:41:11 -0800 (PST) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8CE3A0F0F for ; Tue, 8 Dec 2020 06:41:11 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id cw27so17806991edb.5 for ; Tue, 08 Dec 2020 06:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=CCKLtmuZ0uJB3CZ62vJ0RKZrNQRbXHZ2X6QDJm9nDAv1xdLLWZBGW7BnfbrqCqtIEp q75yBiAL454Aa6sySw9YDD5Tl/l0g4Vx9CvK5a3sPUjkef8CcetmAS7qecbYeMztcxXF 9GQLoQvf3ckKevuVV3ZOZGal/mJT6MXu2HLv3AcnsvEhU38O0uhpKu9TGn+QqSXl/hCf BfIzpbtx0oNWfEWQZB+Zk5InXsOYccgHvxYF44pfA/C8ih5ywHEE7moirCo/4Q6y/Rn8 JYdQ4q0088+puaIqFhyaqBwLclgbQroDBqQWqfL3rN+G0qk12BPgsoUN6iJUpOFAkxAL sl+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UTYp8A0QOMjtcdGjh5S+wPc4o7ZPoohCE82JQIFD3OY=; b=ouk6J/SppJrP5qtJF7tTMBC6dmIVE6BgoiOARTwJQgQinW3xbmg0FqTjpAbjdIMP8Y 5Xe3GfffzcdVDVirGx7SWiG4W8oxkP9HV8QrhyXqOsFIVmk1V7qyTCYObY5WzslB9qeQ y5AEvVmaP/p55I0XAMrh9la2GAQ6THDc7uVUTQIlh8RWIsfsnpgTRb5OC5w+mTvVS2uo wq8lhTJTbfSC5x3IbXxUOZD1lypzX8XChaTtLgMsSDkEBLeExlv1n/wyO/Y+bBwli8KW OXYs1n6S/ZpgRZCaqIJjLhi3u6uliHIweG/hnaWjccK3j85OQTx5qCZU2+Qe7IMQemIl qhIQ== X-Gm-Message-State: AOAM530iNX0qSJUGt7GO1OAGlWq3ke/3HuY22JTPSy8ZEiDG9+2xjJ4+ nVBzSHnrwtIbuN8O5xzUZWzP6yD8T5Y3wfcmPlE= X-Google-Smtp-Source: ABdhPJwOXAmuB4iBsPq09dURpxxHgLmP3dw31Nj6WCQNaPsPe0ipqPwcnO81YqT8U/T09dtKrSdBmQgJXlQEaoHuwfg= X-Received: by 2002:a05:6402:30ac:: with SMTP id df12mr9511452edb.175.1607438469796; Tue, 08 Dec 2020 06:41:09 -0800 (PST) MIME-Version: 1.0 References: <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <20201207091854.GD44833@faui48f.informatik.uni-erlangen.de> <2741.1607381456@localhost> In-Reply-To: <2741.1607381456@localhost> From: =?UTF-8?B?U8OhdnlvIFZpbsOtY2l1cw==?= Date: Tue, 8 Dec 2020 11:40:57 -0300 Message-ID: To: Michael Richardson Cc: iotops@ietf.org, architecture-discuss@iab.org Content-Type: multipart/alternative; boundary="000000000000fd971105b5f4eeb7" Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 14:41:13 -0000 --000000000000fd971105b5f4eeb7 Content-Type: text/plain; charset="UTF-8" Michael Richardson wrote: > http://geer.tinho.net/geer.blackhat.6viii14.txt > and > https://www.blackhat.com/us-14/video/cybersecurity-as-realpolitik.html I agree that we need to put as much effort as is possible to reinforce security, but a regulation becomes useless if it only allows the commercialization of devices that nobody can afford. Regulations need to create a tradeoff between protection and affordability and this turns harder in in-development-countries. What can the IETF do? > Mostly what we are already doing, which is to make it > cheaper and easier to build products where the clients and the servers > don't > have to be vertically integrated. > ... and we have a long way to go, but a starting point could be this issue raised by RFC 8576 (section 5.5): "Like all commercial devices, IoT devices have a given useful lifetime. [...] A user should still be able to use and perhaps even update the device. This requires for some form of authorization handover. [...] CyanogenMod for Android devices and OpenWrt for home routers are two such instances where users have been able to use and update their devices even after the official EOL. Admittedly, it is not easy for an average user to install and configure their devices on their own. With the deployment of millions of IoT devices, simpler mechanisms are needed to allow users to add new trust anchors [RFC6024] and install software and firmware from other sources once the device is EOL." So how should we tackle this? Develop a framework to simplify the third part development of software/firmware updates after the EOL? And how to integrate SUIT work on it? --000000000000fd971105b5f4eeb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael Richardson <mcr+ietf@sandelman.ca> wrote:
http://geer.tinho.net/geer.blackhat.6viii14.txt
and
https://www.blackhat.com/us-14= /video/cybersecurity-as-realpolitik.html

I agree that we need to put as much effort as is possible to reinforce se= curity, but a=C2=A0
regulation becomes useless if it only allows = the commercialization of devices that=C2=A0
nobody can afford. Re= gulations need to create a tradeoff between protection and=C2=A0
= affordability and this turns harder in in-development-countries.
=

What can the IETF do?
Mostly what we are already doing, which is to make it
cheaper and easier to build products where the clients and the servers don&= #39;t
have to be vertically integrated.

... a= nd we have a long way to go, but a starting point could be this issue raise= d by RFC 8576 (section 5.5):

&qu= ot;Like all commercial devices, IoT devices have a given useful
lifetime. [...] A user should still be able to use an= d
perhaps even update the device.=C2=A0 Th= is requires for some form of
authorization= handover.

[...] CyanogenMod for Android devices and OpenWrt for home routers
are two such instances where users have bee= n able to use and update
their devices ev= en after the official EOL. Admittedly, it is not easy
for an average user to install and configure their devices on = their
own.=C2=A0 With the deployment of m= illions of IoT devices, simpler mechanisms
are needed to allow users to add new trust anchors [RFC6024] and install<= /div>
software and firmware from other sources o= nce the device is EOL."
<= br>So how should we tackle this?
Develop a framework to simplify the thi= rd part development of software/firmware updates after the EOL?
And how = to integrate SUIT work on it?
--000000000000fd971105b5f4eeb7-- From nobody Tue Dec 8 13:53:09 2020 Return-Path: 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 44D1A3A11F4; Tue, 8 Dec 2020 13:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0eb3G6jiI1z4; Tue, 8 Dec 2020 13:53:05 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F913A11DC; Tue, 8 Dec 2020 13:53:05 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1kmkuk-0005yV-Ed; Tue, 08 Dec 2020 21:52:54 +0000 Date: Tue, 08 Dec 2020 13:52:53 -0800 Message-ID: From: Randy Bush To: Eliot Lear Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon In-Reply-To: <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 21:53:07 -0000 https://www.wired.com/story/amnesia33-iot-vulnerabilitiesmay-never-get-fixed/ From nobody Tue Dec 8 22:50:18 2020 Return-Path: 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 3E7913A0D06 for ; Tue, 8 Dec 2020 22:50:17 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 U7TMkhfOCQVG for ; Tue, 8 Dec 2020 22:50:16 -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 8A72F3A074E for ; Tue, 8 Dec 2020 22:50:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1240; q=dns/txt; s=iport; t=1607496615; x=1608706215; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=VhPFwg8rM9Ll5av1CzEb4VjfWqZCJjPd+F4Lfc0ndSk=; b=bgZ48bUax5QmY4Wnhu+0kd1EzKvAcHKNW8/ccZtxWS3/eMQ661KlR/OJ B7dmVBwuoc6dvnassbuMXkVXw3xkiyUrIfb0baEnDd2TiohH2CMwwZhvP GFfnMiwnZqdcKyfn/MzRDTOedj00h5VcGRXbfqt54lHp3WsqXGm1K75ta A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DcBQDActBflxbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+DH1cBIBIujG9TiCecMwQHAQEBCgMBASUKBAEBg0sBAXMBAQgCgX8mOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DIVyAQEBAQIBeQULCxguV?= =?us-ascii?q?wYTgyYBgmYgD6t6dIE0hVeFHgoGgTiBU4wLggCBOByCJy4+iAiCLASDeoFBZ?= =?us-ascii?q?5wJnBiCfoMjgTeWZgMfgxIBj2GPQbExg20CBAYFAhWBbSGBWTMaCBsVZQGCP?= =?us-ascii?q?j4SGQ2OO4NXillAAzA3AgYKAQEDCYpqAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,404,1599523200"; d="asc'?scan'208";a="31758964" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 06:50:11 +0000 Received: from [10.61.196.80] ([10.61.196.80]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B96oAv6027868 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Dec 2020 06:50:10 GMT From: Eliot Lear Message-Id: <302A37B6-4A3C-4CDE-8C29-410A982296FA@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 9 Dec 2020 07:50:09 +0100 In-Reply-To: Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon To: Randy Bush References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <277E5229-EFCC-4758-B4F6-6B159212BA14@ambotec.org> <50213DD8-794D-4180-A918-A6B94FDC61C3@cisco.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.196.80, [10.61.196.80] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [arch-d] [Iotops] How old is too old and what this means for product lifecycles? 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 06:50:17 -0000 --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Randy > On 8 Dec 2020, at 22:52, Randy Bush wrote: >=20 > = https://www.wired.com/story/amnesia33-iot-vulnerabilitiesmay-never-get-fix= ed/ Yes. That article hits on nearly every security and incentive problem = the IOT industry has. Eliot --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/Qc6EACgkQh7ZrRtnS ejN0Cgf9EbtIQG3V+9tPY/SYPwsns7hSAKuMTROI8Eu4Ra9bskzKdvVjyAxPwPdj Nn2Bmv+zQwp8QYs1qhrxkyTfWMcp+Bi4XrYdI+CrqwPc285O9n8XLtIIf1b+ZoAV UL2L1JsyH4FOpEApCkRbWmk2Py4fNMg6FnpZQaOUKyaTOfIDoz1P2mTh0NAGyu79 52SOobUOg+YPZmAq7n0vzC/qUdLEPNem75JBQaKB3A6oNBgjV8IuU5jCO9KkObtQ mcCxxB6ZG5n0AIeau008xStADDOWVBht8dBsi1lJNbv1VWT9aZUBohUYQ0CVw5mL fw21k7EnYsBt22NTfy0k8t3ujc7oig== =AU34 -----END PGP SIGNATURE----- --Apple-Mail=_E3D66599-7099-4DF1-8E91-D3272F86F042--