Hi,
On Tue, Nov 22, 2016 at 3:25 PM, Michael StJohns
<mstjohns(_at_)comcast(_dot_)net>
wrote:
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.
In addition, we are already in process of updating RFC3552, security
considerations and are looking for feedback on the SAAG list.
Thanks.
Mike
--
Best regards,
Kathleen