Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt

Eliot Lear <> Mon, 15 July 2019 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AD281201E5 for <>; Mon, 15 Jul 2019 09:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HDGlhUkH6HNS for <>; Mon, 15 Jul 2019 09:16:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 154F51201E4 for <>; Mon, 15 Jul 2019 09:16:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9579; q=dns/txt; s=iport; t=1563207392; x=1564416992; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=N13LoiowyybiA01V642pR/uJJ3WHqu6HXtG7jhCpMqA=; b=bhb1ppWJV6GrAk8w6Y2owsQLtpcjf9+ZUVI5CslMUrCro0SFjQ5fMGxz KpEjyqQJ+OoZdyTk/tH+JEGxnYw5MKQ6AGSDfHycWuT/PzCNsGhjp8hUS CNZV6ZENH4EsT8Llvp7EG4Q8CNDtMmghFEMB+yqXpu0usjSxFhdt9YGKZ Y=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAB9pixd/xbLJq1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBZwWBOisBIBIohByIe4tTJZJ6h34CBwEBAQk?= =?us-ascii?q?DAQEvAQGEQAIOgno3Bg4BAwEBBAEBAgEFbYVIhUoBAQEBAgEjTQcCBQsLGBg?= =?us-ascii?q?SAgJXBhODIgGBew+rcIEyhUeEZhCBNAGBUIdFgmCBf4E4DBOBTlAuPoQoa4I?= =?us-ascii?q?7MoImBIwFTQKIHZUFbQmCG4IfgQyOLoIzG4ItlV2OZpMUgwsCBAYFAhWBZiI?= =?us-ascii?q?3B4EaMxoIGxVlAYFZaD6COm8BDI0TPQMwjX2CLgEB?=
X-IronPort-AV: E=Sophos;i="5.63,494,1557187200"; d="asc'?scan'208,217";a="14262987"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 16:16:30 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x6FGFWeN028388 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 16:16:29 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_DB5207E9-3DF1-48CC-8377-66F138A7E1E5"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 18:16:29 +0200
In-Reply-To: <>
Cc: Bret Jordan <>,, Melinda Shore <>, IETF SecDispatch <>
To: Phillip Hallam-Baker <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [Secdispatch] [Smart] New Version Notification for draft-lazanski-smart-users-internet-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jul 2019 16:16:35 -0000


> On 15 Jul 2019, at 18:03, Phillip Hallam-Baker <> wrote:
> I am pretty sure this is not security 101 stuff. In fact I am pretty sure that it will be quite a while before the academy really gets to grips with this stuff. They don't have the same biases we do but they have different ones.
> For example, the need to patch systems is brought up and this is almost always seen as a good thing. Not in the process control world it isn't. The problem of unauthorized updates is a very serious concern for them.

I think I agree with your thesis statement but not your supporting statement above.  There are a great many “best practices” that are coming out, and they all to a one usually involve usernames and passwords for a good number of devices that might not require either.  And in fact, the idea of a password for machine controlled devices is Just Bad.

Patches themselves from the vendors are absolutely required to be available, but the timing of their installation needs to be left to customers based on when – if at all – those devices can allow for a window where the device may miss a beat.  But even in these cases, process control systems need in service upgrade mechanisms, because the reality is that the bugs will be there.

> Devices that automatically update themselves are vulnerable to a denial of service attack by the device provider.
> This is not an attack many device providers are worried about because it isn't an attack that is going to affect them (for a start) and they think they can trust themselves. Which may well not be true. I have seen a single employee cause $1 million worth of vandalism after being upset that his wages were being garnished for alimony. I really doubt that more than 5% of the companies that make IoT devices have effective controls.

Ok, but that is no reason to not have automated updates available.  That is more of a reason to have strong audit processes in place.

> The same is true of devices that depend on a tied service. My Revolv hub is useless because Google bought the company and shut down the service leaving me with $2500 worth of dead equipment in my walls.
> This is not 101 stuff and in fact I don't think that a single one of the IoT vendors out there is showing that they understand it. We are still at what I call the 'narcissistic' phase of the market in which every medium sized IoT vendor thinks it is all about themselves.
> The fact that an IoT device makes the owner dependent on the provider is totally a security issue. The fact that the device providers don't want to acknowledge it doesn't make it any less so.

I agree that this is indeed a security issue, but that doesn’t mean that it’s the wrong way to go.  There are other factors to take into consideration, not the least of which is cogs and e-Waste associated with unnecessarily shipping extra horse power to 20 million endpoints when a little elastic processing in the cloud will do.