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

Bret Jordan <> Mon, 15 July 2019 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F664120176 for <>; Mon, 15 Jul 2019 09:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ig8L0xYnT54p for <>; Mon, 15 Jul 2019 09:24:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31E32120168 for <>; Mon, 15 Jul 2019 09:24:09 -0700 (PDT)
Received: by with SMTP id u14so7666176pfn.2 for <>; Mon, 15 Jul 2019 09:24:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yHZnHZQT7W1VbBLWQy2PoMdnhJkjmXv/qcHKp6GSFhs=; b=M+5o1SR15lvoyjb0o+2ZWufsaaRpGFuTX1u115CWHkN+4aj7NKKWd/lRqWtVFZqsQ9 AYEttH8RFac2BvsLp0pazt2LHAMhJCFF2WgKJKi9gir5PxuVjfqyHYT5mVIwbJHdPkjh 5Dm3rCf5hSarjxz045+fKI34Jdc9gsExUVmG0acnW06vQnqcCdtHKYlCeD9Pt9SaVVFW 73mL2CvzqXBvgG/faLWoHd4cv8f9T0ThNJDUA+Q2wFadBBO6Xen6WG1yxw0k+Y0/jXxe zEUtGf8ITqY6C70kjFSxRbzVWBROc5sSg9UKxgm6xCwYxKPlGVL+Vl98hWTdcX8bPpD8 7yzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yHZnHZQT7W1VbBLWQy2PoMdnhJkjmXv/qcHKp6GSFhs=; b=FuN95XPeKccFCaRKbkBXi76PzyfYdU1WJ7dfb+eKPOehKIMQMKt6E2Ds6ywX+nbOUJ CUwPPH6XtJ2/Q/XEcq1GrcYMdH7VCAe4duoV2eTkvcLYoDbZ6/7HcXiYP4z/GNKOxflk g9Eb7dnRp5hbZA7QZlSozNW08wXNqrUp8zeYPRIZ0AQSQdlkyyiDsVcFqkCLNx8TooR4 Jh8Bn/xG1Wt/Fi5CV+oCqEKKS104crSwi4DX0BVVWrtaFFpFR6SlhsIi8ifK4aAkEyOS 4nbI3qPGqiwjOy294o51OpQm6c+k5lYe/79xuLCZbG4NeMVMH/WCRY/KUfCmNWAjitFU eq4Q==
X-Gm-Message-State: APjAAAWBjWvaIswndKOuxw4+A55TlFjE36doQ1nhW6P3eNIE+yd/+GgZ w78pRR9W6Rh8OBueDf92Bd8=
X-Google-Smtp-Source: APXvYqzemOfg7fCJHQZYUL4WDhv2zmEXKYX8+v5EkklN0v1BM1ehnBTQAeXFF/nRxjGjNBFiyOdc7A==
X-Received: by 2002:a63:fd50:: with SMTP id m16mr27471960pgj.192.1563207848687; Mon, 15 Jul 2019 09:24:08 -0700 (PDT)
Received: from ?IPv6:2605:a601:a990:4d00:a925:658c:7e16:1f17? ([2605:a601:a990:4d00:a925:658c:7e16:1f17]) by with ESMTPSA id z2sm15997596pgg.58.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 09:24:07 -0700 (PDT)
From: Bret Jordan <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E2A33079-237E-45BF-8835-D2F9BF6D37BC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 15 Jul 2019 10:24:05 -0600
In-Reply-To: <>
Cc: Phillip Hallam-Baker <>,, Melinda Shore <>, IETF SecDispatch <>
To: Eliot Lear <lear@CISCO.COM>
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:24:12 -0000

My key points were due to the responses I hear form some in the IETF, specifically

“If you just patched your endpoints there would be no issue”
“All endpoints can easily run security software”

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

> On Jul 15, 2019, at 10:16 AM, Eliot Lear <lear@CISCO.COM> wrote:
> Phil,
>> 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.
> Eliot