Security Considerations, IoT and Everything

Michael StJohns <mstjohns@comcast.net> Tue, 22 November 2016 20:25 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128EE129785 for <ietf@ietfa.amsl.com>; Tue, 22 Nov 2016 12:25:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 bPDrcxkzYk74 for <ietf@ietfa.amsl.com>; Tue, 22 Nov 2016 12:25:37 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 B4415129A4C for <ietf@ietf.org>; Tue, 22 Nov 2016 12:25:37 -0800 (PST)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-10v.sys.comcast.net with SMTP id 9HcDc3pKsRing9HdJcVaoy; Tue, 22 Nov 2016 20:25:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479846337; bh=ByF83FasXSf6YCmTiejzCekhjXQau3xpfi+DLWseGVs=; h=Received:Received:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type; b=DDt9rrjEg/gof+uLci8ixlGaX9nJP/hq5k1870gTSOWdreb/K2U1KUYmgmITOSClV aDp/a1G516IghKUXzL9qc0w6F5C1WPFWd2ZLj12++xBoy9IXljHzL5t4D7DjPdScmH uvzBnWtp5ulK2vP3oHRrjfLrO02RrwN8rLDss9N6/Rbaytf9mhZY5xv26IK/t1gEEH EBJWIKMdIp7UXXK00Imbgp0EFCWEdL94KNq8jGJiR3pG9ijMfee4h7G10cSzoWZhwp /WkW1ZcoBcJkxfCsxbJ0LOvvlebXNASH121ULlcW/xA9pDLK8BMoaEyERgWs5PzbzQ C7ogJdjT2mRlg==
Received: from [192.168.1.115] ([68.83.216.245]) by resomta-ch2-16v.sys.comcast.net with SMTP id 9HdIcMz3qLNQs9HdIc9ZZr; Tue, 22 Nov 2016 20:25:36 +0000
To: ietf@ietf.org
From: Michael StJohns <mstjohns@comcast.net>
Subject: Security Considerations, IoT and Everything
Message-ID: <734ef353-487f-4f64-6cfe-f7909e705a41@comcast.net>
Date: Tue, 22 Nov 2016 15:25:36 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfOBOsbDieva8Sg2edtXKZ08mmkN15XX4z/9aRcdBsD266A/lvAhT6kC8IitfTJX37zuSVhPglLRa0rn126AzLWE+9ZwgjbeWZhri4x6FoNFt4HFs2nEs TP+QhUpCkdZu/nEJpKzpgCM++1Sv8EnNYgTVh4/WYI99A45QZxBgX5RU
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/aCTmx7ehD6XtphPWaQk1ftSJK3Y>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Nov 2016 20:25:39 -0000

Hi  -

During the plenary presentations in Seoul we were treated to a view of 
how the Internet has changed with the introduction of cheap 
network-connected devices with poor security.  That presentation, as 
well as discussion in various IoT/Constrained Devices related working 
groups got me thinking about RFC security considerations and how they 
may need to change in the future. Basically, we've been writing Security 
Consideration sections that address threats *to* the protocol and 
devices that implement the protocol.  Is it time to revise BCP72/RFC3522 
to require we also address threats *from* the protocols to the Internet 
as a whole?

For example, DNS has been used quite frequently as a stepping-off point 
for DDoS attacks.  In the recent IOT related attacks, bad UI/Password 
management choices were a contributing factor to those IoT devices being 
used in DDoS.    In 
https://www.engadget.com/2016/11/03/hackers-hijack-a-philips-hue-lights-with-a-drone/, 
the researchers were able to take advantages of bad crytographic design 
choices (e.g. all of the firmware was signed/verified using the same 
secret key - which was present in all lightbulbs), and a flaw in the 
Zigbee attack, and a drone (to get close enough) to take control of a 
group of HUE lightbulbs, re-write their firmware and flash SOS.

One of the claims for IoT is 10s of billions of devices added to the 
internet within the next 5-10 years, and that may be a low estimate.  
The targets for IoT are everywhere from simple 
sensor/controller/actuator devices (e.g. thermostats, lighting systems) 
to more complex combinations of devices at all grades of capability from 
ultra cheap throwaways to consumer/commercial/industrial.  Then there's 
the how cyber-physical thing - internet connected devices that can 
interact and control things in the real world. Consider for a moment the 
threat to safety and health if the HUE were instead designed to be used 
for UV sterilization instead of plain lighting.

There's also this push for cheap and fast to market. Unfortunately, that 
may mean poorly protected devices with unintended consequences to the 
Internet as a whole.  We're starting to see worked examples of this.

So getting back to RFC3522:

1) Is it time to update this 2003 document in view of current threats?

2) Can we say anything useful with respect to security protocol design, 
protocol fields of use and probable impact on the Internet?

3) Should we set a minimum bar to try and avoid standardizing unsafe 
protocols or at least unsafe security choices in protocols?


In the early days of the internet, connected devices were mostly big 
iron - main frames and mini-computers.  Next came the wave of PCs.  Next 
the smart phones and tablets.  All of these had one thing mostly in 
common - there was generally a Human in the loop somewhere watching the 
device.  For IoT - humans not so much. That's obviously both an 
advantage and disadvantage; but it might also be an indication that we 
need to re-think our internet security strategies - again.


Mike