Subject: Security Considerations, IoT and Everything

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Nov 2016 15:25:36 -0500

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 22 Nov 2016 16:20:14 -0500

Hi,

On Tue, Nov 22, 2016 at 3:25 PM, Michael StJohns <[email-masked]>
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?
>
> 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.
>
> 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.
>
> 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.

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2016 21:56:42 +0000

> *from* the protocols to the Internet as a whole?

Yes. As Kathleen said please do contribute to the relevant
thread [1] on the saag list.

S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg07514.html

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Nov 2016 23:03:02 +0100

On 22 Nov 2016, at 21:25, Michael StJohns <[email-masked]> wrote:
> 
> Is it time to revise BCP72/RFC3522 to require we also address threats *from* the protocols to the Internet as a whole?

Indeed.  We did some of this in the security considerations of RFC 7252 (e.g., section 11.3 and 11.5).  A catalog of issues to consider would certainly help in writing future security considerations sections.

https://tools.ietf.org/html/rfc7252#section-11.3
https://tools.ietf.org/html/rfc7252#section-11.5

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Nov 2016 17:35:25 -0500

> [1] https://www.ietf.org/mail-archive/web/saag/current/msg07514.html
Thanks - missed this on the SAAG list when it first came out.

To be honest, this thread/discussion appears a bit moribund: it wasn't 
brought up during the SAAG meeting this time AFAICT, it doesn't appear 
to actually be a WG item as of yet, there doesn't appear to be much if 
any discussion on the SAAG list (a quick look doesn't find anything 
since July excepts Stephen's note - and that was all related to 
privacy), and the ID and GIT don't appear to have been updated since 
August.  The version on GIT seems to be only a references update from 
3522.  It looks like there was maybe a 10 minute - if that - chat about 
this in Berlin.

Perhaps it's time to have a broader (than SAAG) discussion on this as it 
really reaches further?

Mike

ps - on another note, why doesn't the SAAG have a datatracker page like 
rtgwg?

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2016 22:48:51 +0000

On 22/11/16 22:35, Michael StJohns wrote:
> To be honest, this thread/discussion appears a bit moribund:

Yep. I hope though that topics such as this will be raised
and dealt with. I guess it'll be slower than we hoped though.

> it wasn't

I don't care if it's broad or narrow so long as we cover the
ground. If/when folks engage then we'll find the right method
for handling engagement. (Could be on here, on saag or on a
new list - but for now, I think saag is the better option.)

> ps - on another note, why doesn't the SAAG have a datatracker page like

Saag's not a WG. People suggest it now and then (and others
dislike the idea). Feel free to raise that too (though I'd
far prefer we discuss 3552bis myself.)

Cheers,
S.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 22 Nov 2016 20:01:34 -0500

> far prefer we discuss 3552bis myself.)

I didn't ask why SAAG is not a WG, I asked why it didn't have a 
datatracker page.  Not having a datatracker page makes it difficult to 
track things that are associated only with the SAAG (e.g. the draft 3552 
replacement).  In the IETF meeting APP, I can't lookup "saag" in the wg 
list to see what's what for the meeting for example and that appears to 
be a directly related to SAAGs lack of datatracker presence.

E.g. - this is an administrative question for the ADs, not a "why don't 
we have a working group question" for the community.

Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 22 Nov 2016 21:21:15 -0500

Hi Mike,

On Tue, Nov 22, 2016 at 5:48 PM, Stephen Farrell <[email-masked]>
wrote:

> > brought up during the SAAG meeting this time AFAICT,

In addition to Stephen's response, which covered the other points in your
message...

There was a presentation slot for this update in Berlin and Yoav went to
the mic during open mic to request feedback during this meeting in Seoul.
I added a plea for contributions restating the importance of this draft and
the need for contributions explaining how useful it is to other areas of
the IETF in particular to make sure these requests were heard and it was
understood that it was important.

Thanks,
Kathleen

> it doesn't appear

-- 

Best regards,
Kathleen

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Nov 2016 11:05:05 +0200

> On 23 Nov 2016, at 3:01, Michael StJohns <[email-masked]> wrote:
> 
> I didn't ask why SAAG is not a WG, I asked why it didn't have a datatracker page.  Not having a datatracker page makes it difficult to track things that are associated only with the SAAG (e.g. the draft 3552 replacement).  In the IETF meeting APP, I can't lookup "saag" in the wg list to see what's what for the meeting for example and that appears to be a directly related to SAAGs lack of datatracker presence.
> 
Hi, Mike. 

While there isn’t a SAAG datatracker page, there is a SAAG github group where you can find (among no other things) the text of rfc3552bis.

Having a datatracker page implies that there are drafts in there. AFAICT this is the first draft that people associate with SAAG so a page didn’t make sense before.

https://github.com/IETF-SAAG

Yoav

---

From: Dave Taht <[email-masked]>
Date: Thu, 24 Nov 2016 07:43:14 -0800

NIST published this last month.

http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-160.pdf

On Wed, Nov 23, 2016 at 1:05 AM, Yoav Nir <[email-masked]> wrote:
> I didn't ask why SAAG is not a WG, I asked why it didn't have a datatracker
> page.  Not having a datatracker page makes it difficult to track things that
> are associated only with the SAAG (e.g. the draft 3552 replacement).  In the
> IETF meeting APP, I can't lookup "saag" in the wg list to see what's what
> for the meeting for example and that appears to be a directly related to
> SAAGs lack of datatracker presence.
>
> Hi, Mike.
>
> While there isn’t a SAAG datatracker page, there is a SAAG github group
> where you can find (among no other things) the text of rfc3552bis.
>
> Having a datatracker page implies that there are drafts in there. AFAICT
> this is the first draft that people associate with SAAG so a page didn’t
> make sense before.
>

-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org