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

Randy Bush <> Sat, 05 December 2020 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 732FC3A0AA0; Sat, 5 Dec 2020 10:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cxWi-IXpNK4i; Sat, 5 Dec 2020 10:10:07 -0800 (PST)
Received: from ( [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF8E73A0A9C; Sat, 5 Dec 2020 10:10:06 -0800 (PST)
Received: from localhost ([] by 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" <>,,
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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: [Iotops] How old is too old and what this means for product lifecycles? Re: [Last-Call] [TLS] Last Call: <draft-ietf-tls-oldversions-deprecate-09.txt> (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Dec 2020 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

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

randy, who still has a curta and a k&e log log duplex decitrig