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

Christian Huitema <huitema@huitema.net> Sat, 05 December 2020 19:43 UTC

Return-Path: <huitema@huitema.net>
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 <architecture-discuss@ietfa.amsl.com>; 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 <architecture-discuss@ietfa.amsl.com>; 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 <architecture-discuss@iab.org>; 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 <huitema@huitema.net>) 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 <architecture-discuss@iab.org>; 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 <huitema@huitema.net>) 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 <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <MAckermann@bcbsm.com>; 5 Dec 2020 19:43:39 -0000
To: Randy Bush <randy@psg.com>, Eliot Lear <lear@cisco.com>
Cc: architecture-discuss@iab.org, iotops@ietf.org, Ted Lemon <mellon@fugue.com>, "Ackermann, Michael" <MAckermann@bcbsm.com>
References: <160496076356.8063.5138064792555453422@ietfa.amsl.com> <MWHPR02MB2464CD5D5B7568E9EAC58B26D6F20@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178EC0521427BF7C3523CACD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <CAChr6SzvQK+exfgYEwfVNknMjr-Y-UJ4A7k0DkOkL9wmLQ84aQ@mail.gmail.com> <MWHPR02MB246499F35613820D45EB55AAD6F10@MWHPR02MB2464.namprd02.prod.outlook.com> <DM6PR14MB3178A0C152A746E41C6A01C6D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <f8486514-9726-68d0-2bc8-dccd4293017e@cs.tcd.ie> <DM6PR14MB317843CA2B3D67F6660F4F0DD7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <127BB8C9-679E-48C1-8617-C6092AEE9914@fugue.com> <DM6PR14MB3178C1F8B6E4FD6E9FD9C8C4D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <8E6EB6FF-E83B-44B5-A0A2-7499678DC6B6@fugue.com> <DM6PR14MB317817FD62369A8E0FF93CA8D7F10@DM6PR14MB3178.namprd14.prod.outlook.com> <77363965-99A5-4790-B40B-011827C8D113@fugue.com> <80F697E4-B225-49E0-8271-CDAB66E42A95@cisco.com> <m2zh2sktty.wl-randy@psg.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <25c496c0-98d0-e15b-d16f-e55b40936e35@huitema.net>
Date: Sat, 05 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: <m2zh2sktty.wl-randy@psg.com>
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: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/af9TPeYLEZ1Tsy8-0uKuNs6cRKs>
Subject: Re: [arch-d] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Dec 2020 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