Re: [Iotops] [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

Henning Schulzrinne <hgs@cs.columbia.edu> Mon, 07 December 2020 14:43 UTC

Return-Path: <hgs10@columbia.edu>
X-Original-To: iotops@ietfa.amsl.com
Delivered-To: iotops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF1C3A13F7 for <iotops@ietfa.amsl.com>; Mon, 7 Dec 2020 06:43:39 -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=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 j2LQTzLsVTFd for <iotops@ietfa.amsl.com>; Mon, 7 Dec 2020 06:43:37 -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 284E13A13F4 for <iotops@ietf.org>; Mon, 7 Dec 2020 06:43:37 -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 0B7EgEjY031449 for <iotops@ietf.org>; Mon, 7 Dec 2020 09:43:36 -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 sendprodmail10.cc.columbia.edu (sendprodmail10.cc.columbia.edu [128.59.72.18]) by mx0a-00364e01.pphosted.com with ESMTP id 3587901qc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <iotops@ietf.org>; Mon, 07 Dec 2020 09:43:36 -0500
Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by sendprodmail10.cc.columbia.edu (8.14.4/8.14.4) with ESMTP id 0B7EhZce014051 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <iotops@ietf.org>; Mon, 7 Dec 2020 09:43:35 -0500
Received: by mail-qv1-f70.google.com with SMTP id t16so7375936qvk.13 for <iotops@ietf.org>; 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=jQZWtiWQDm7T4pa2MVZ8Bji+U9w408PZurvjlL9TTLZ2foBG67q9FAA8dEIdZKRQ8f gE+FAD73VUdT7c2twAh2ZwifD1g5So/+cqRcc/pL5FC8sn4OzGDjQQClJIMTOPkoBTlF t+syui4/8+nJZ345oZPS1DVVfFeNa5jpui70FgqGuFhG9ToG17ePEA5hn2uprZ5bds5t ZHfEuwZuskVxtK2y++TzHPEAOS99X/pmOuK8VBC23qWBVWRN1fUv9Zh1tgTBpKBYr0Jt LqWwpvkcOJizRG3ZDhVPu9MDVjd5z/rczKSXxFurDm5mFr8or6NZdm3OsePEhr2/0u2V qvdQ==
X-Gm-Message-State: AOAM5327dGLhQSbBCyEcJEyDyl8HAU+P2EtpjOSB2zbfxKcMqnSWf4/C 7ykpC7QFb1szABrpe9x3yt6jTEnh+X7ZaFV5W3xBu7Fi51bw1T8SnQmjW7FJ+kcCdUkhiGglfz1 2r5pUweVtADtk1YX3kp9PYc0QReczhCE=
X-Received: by 2002:a05:620a:2296:: with SMTP id o22mr24565517qkh.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: <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> <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 <hgs@cs.columbia.edu>
Date: Mon, 07 Dec 2020 09:43:07 -0500
Message-ID: <CACgrgBa+JMDBWWBotfQeJMc=LMbkH+JbkbQ_YkXS4GuccnbrVA@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Amyas Phillips <amyas@ambotec.org>, iotops@ietf.org, Ted Lemon <mellon@fugue.com>, architecture-discuss@iab.org, Randy Bush <randy@psg.com>, "Ackermann, Michael" <MAckermann@bcbsm.com>
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: <https://mailarchive.ietf.org/arch/msg/iotops/DDGnTwBLVS3kGldU2PxxCbnsAs8>
Subject: Re: [Iotops] [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: iotops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <iotops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iotops>, <mailto:iotops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotops/>
List-Post: <mailto:iotops@ietf.org>
List-Help: <mailto:iotops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iotops>, <mailto:iotops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Dec 2020 14:43:40 -0000

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 <tte@cs.fau.de> 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 <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???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
>