Subject: Re: [T2TRG] [irsg] IRSG review of "State-of-the-Art and Challenges for the Internet of Things Security" (draft-irtf-t2trg-iot-seccons)

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Sun, 8 Apr 2018 20:54:25 +0000

Dear Vincent, all,

Many thanks for your comments. Below you find feedback on how we have addressed your comments
that you can find in the updated document:

https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-13

With this, we believe that the document is ready for the next stage (which is presumably the IRSG Poll)

Kind regards, Mohit & Oscar.

From: T2TRG [mailto:[email-masked]] On Behalf Of Vincent Roca
Sent: Friday, March 23, 2018 7:46 PM
To: Ari Keränen <[email-masked]>
Cc: Vincent Roca <[email-masked]>; [email-masked]; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [T2TRG] [irsg] IRSG review of "State-of-the-Art and Challenges for the Internet of Things Security" (draft-irtf-t2trg-iot-seccons)

Dear Ari, authors, all,

You’ll find below my IRSG review of  draft-irtf-t2trg-iot-seccons-12
Sorry, this is a very long and detailed review but it turns out it’s a domain of interest to me.
The goal is to be useful. I hope it's the case.

Cheers,

   Vincent

----
Vincent Roca, PhD/HDR, Inria research institute, France
https://www.inrialpes.fr/planete/people/roca/

Main comments:

This is a great document, pretty useful, and very well written.
My general opinion is pretty good even if I have a comments.

>> Thanks

1) Privacy in IOT deserves more

It is a bit surprising to me that privacy is under represented when discussing IOT security.
No mention in abstract, no mention in Introduction. One needs to wait section 3, bullet 7 and
onwards to see some text on privacy threats.
Then this document introduces a list of 11 security threats (section 3), privacy being one of
them. This is a questionable viewpoint (i.e., privacy is 1/11th of the risks)!
Similarly, there's a 1 page discussion (section 5.9) of privacy out of 33.

>> We agree that there are many important topics, privacy is indeed one of them, in particular, in view of the latest news. In general, it is incorrect to assign weights to the list of security threats in section 3 and deduce from it that privacy is 1/11th. Everyone has their favorite threat. Stephen Farrell for example stated that bad software/code is the most important threat. Anyhow, we have moved privacy up on the list. However, we don't talk about privacy in the abstract or the introduction. But we do not talk about many of the other threats as well.

This is against:
- current trend to place privacy considerations at the same level as security (said differently
  privacy is an integral part of cybersecurity)
- the major threats the deployment of IOT represents in our everyday's life places, and we are just at
  the beginning.

Another main issue WRT privacy is the lack of definition of personal data (EU) or PII (US).
One cannot discuss privacy without defining it since this is not so obvious, this is not related
to the nature of data but to linkability direct or not to a person.
Of course there are cultural differences across regions and the notion of personal data is not defined
the same way. But definitions remain important.

>> We have included a definition of personal data according to GDPR.

To conclude, I'd be in favour of removing privacy considerations from this ID altogether in order to
write another one that focusses only on this topic more seriously. There's a lot to say. And of course
this should be explained in abstract/introduction.

>> You do mention that "privacy  is an integral part of cybersecurity" but then ask us to remove privacy considerations? Of course, we could have another document focusing only on privacy. But while we wait for that, we think that for completeness, it is better to have the current text around privacy. This is in the end the goal of this document, to have an overview of state of the art and challenges in IoT Security. We have of course added definitions of personal data etc. and tried to improve the existing text based on your background.

2) Lack of discussion of the highly sophisticated data flows in smart home devices

In the particular case of smart homes (connected bulbs, thermostats, locks, intelligent speakers,
...) the architecture becomes pretty complex. The device itself is associated to a smartphone app,
there are also interactions with manufacturer servers, and of course external cloud storage using
a third party service. There are interactions between all these components (during setup/association
and normal operation), plus data flows and data processing.
Security of the system is therefore limited by the security of each component which means that the
IOT security is related to that of cloud services, to that of web services, etc.
I'd appreciate to have a high level discusssion on the topic.

Additionaly, the question becomes even more complex (interesting?) when you have several such
systems, with different security models/practices, that are merged in the same unified system,
under the control of a single central hub.

Of course this is a specific domain of application for IOT.

>> This is a pretty specific use case. We describe a generic use case, but this draft is not about describing specific ones. In an early version of the draft (back in 2012), we had even security profiles for difference scenarios (one of them, a home but also smart city, etc). However, it was decided to leave them out and focus on an overview of challenges.

Additional comments:

** Section 5.6. Verifying device behaviour

For home equipments, we see more and more home security/monitoring gateway offers.
A few ones I've spotted:
- Fsecure Sense [https://www.f-secure.com/fr_FR/web/home_fr/sense]
- Symantec [https://us.norton.com/core]
- Safethings [https://safethings.avira.com]
- Bitdefender [https://www.bitdefender.com/box]
- Luma smart Wi-Fi router [https://lumahome.com]
- Dojo [https://dojo.bullguard.com/]
- Cujo [https://www.getcujo.com]

There's no mention of this trend in the document. It could (partially) answer the question:
"where and how this monitoring feature is implemented still remains an open question."

>> We have included a short paragraph describing this model. But it is better to not include specific vendors. The reasons being that we should be vendor independent and the list above is also not complete, just consider Nokia Smart home gateway https://networks.nokia.com/solutions/smart-home and Akita https://www.kickstarter.com/projects/akita/akita-instant-privacy-for-smart-homes. This list would never be complete.

** Section 5.7.  Testing: bug hunting and vulnerabilities
Item 1:
Hence the need for an agreed and dynamically updated certification and labellisation program
(like the EU current initiative in the domain) for all equipments that are commercialized.

>>  Good point. We have included a line addressing this.

Item 2:
Especially as the security of the whole is limited by the weakest point. This is also an
important aspect that needs to be mentioned/discussed.

>>  Good point. We have added a sentence to illustrate this.

** Section 5.8 Quantum resistance

Well, post-quantum cryptography is essential for documents that need long term confidentiality.
Is it really the case with IOT? I may be wrong but I don't have exemple that comes to my mind.
If we agree, then this section could probably be squeezed (it's currently 1 page long!).

>>  It applies in multiple ways. One of them relates to long term confidentiality, also important in IoT. But there are also other use cases. For instance, IoT devices remain operational for long time (> 10 years). At some point of time, digital signatures used today will not be secure anymore, so that for those devices it will not be feasible to deploy a software update in a secure way. We have added a line describing this.

** Section 5.9:
I don't agree with: "Ziegeldorf [Ziegeldorf] defines privacy in IoT as a threefold guarantee:..."
Those three aspects are essential, sure, but those three guarantees DO NOT define the problem
unlike what is said. Besides they do not follow the current way of presenting things (inherited
in most parts from regulation):

- transparency is one of the key aspects. It's a much better concept than "awareness". I want
  the data controller to be transparent WRT practices. And transparency also includes the potential
  transfer of personal data to third parties (3rd point in the text).

- user control (user empowerment, etc.) is, I agree, another key point. However the final goal is
  not to control what happens inside IOT devices (if it's designed correctly I don't mind too much),
  but above all what happens to personal data transmitted to the data controller since it then becomes
  out of reach. This split of control between items 2 and 3 is not appropriate.

- accountability (for the data controller) is the third aspect since it is the only guaranty for
  the user that an independant trusted party (e.g., a national data protection agency) can actually
  check that actual practices are in line with what has been declared (transparancy).

So I'd remove Ziegeldorf definition of privacy altogether (it's misleading) and replace it with
some text around my above points (and may be other aspects).

>> We agree that there are many definitions for privacy. We have included clarifications according to your points, but we doubt whether removing the reference is right.

** Section 5.9:
Concerning the "privacy threats and challenges", once again I don't agree.
First I think the wording "threats and challenges" is strange. Where's the challenge? Is identifying
user's devices the challenge or is preventing user re-identification the challenge? I'd remove the
term challenge.

>> We have rephrased this.

Then the list is not satisfying IMHO:
- identification: the identification of a user (through its name, address...) is not the main issue.
        Collecting unique IDs along with raw data, as is most of the time the case, is the concern.
        Identification of all the user's device is called "cross device tracking" (e.g., trhough
        audio beacons, etc.). That's another threat.

- collecting geolocation is an issue (it's called physical tracking: being able to track a given
        user's device in the physical world, e.g., through wifi MAC in certain frames).
        But a major problem with geolocation is inference. Many things can be inferred. Some of them
        (in EU) belong to the sensitive personal data category. That's a major issue.

- I find the "Interaction" item a bit strange. I think it refers to some attempts to present
        personalized advertisements in public places when a known device (e.g., known MAC address)
            is nearby.
        There's an issue, sure, but the way it's presented is rather obscure if we don't know
        the example. Besides, I'm not sure it deserves a item by itself, as this is an intrusive
        exploitation of personal data (after user profiling) above all.

- "Lifecycle transitions" is not a threat in itself (change wording). The challenge is the
        secure/guarranteed initialisation of a device.

- Linkage: this is not only through the combination of IOT devices' information. This is much
        broader than that. Inference is through auxilliary information, be it from IOT devices or anything else.

>>We have improved the description that we very briefly summarized from Ziegeldorf so that they reflect your comments. Note that in this document we discuss the different topics briefly so that we can have an overview of them.

Then the difficulty with a list is to be sure it's reasonnably exhaustive (otherwise it should be said it’s not
the case). I'm pretty sure we can find other threats... E.g., surveillance!

The last paragraph is nice and raises a tough research issue, I agree.

** Throughout the document: on several occasion authors mention "private data" with different meanings.
In section 3, "7.   Extraction of private information:" refers to cryptographic keying material.
That I can understand and agree.
However, section 5.9, the authors say: "to ensure that private data remains private". Here private
data refers to personal data, something that is totally different.
Then in section 5.6 the authors use "sensitive private data" to refer to personal data that one would
consider as worth being protected. There is some confusion in the wording with the concept of
"sensitive personal data" of the FR/EU regulation (i.e., data related to some specific domains like
health, political/religious beliefs, etc.). It's confusing IMO.

>> We have refined these points and we have included a definition on personal data.

** Section 5.10. Data leakage

I really don't like the title. For me, data leakage refers to privacy concerns (data in the sense
personal data). Here the section deals with device attacks and reverse-engineering considerations.
That should be reflected in the title.

>> We have updated the title and the description .

** Section 5.11. Trustworthy IoT Operation

I don't understand why this discussion (or lack of) is organised around three questions:
"  1.  How to prevent large scale vulnerabilities in IoT devices?"

=> By reducing risks. That's also the goal of labelisation/certification initiatives in the domain (see
above). But when a attack is found for a very popular device, this is mechanically a "large scale
vulnerability". I don't understand the point here.

"  2.  How to prevent attackers from exploiting vulnerabilities in IoT
       devices at large scale?"

=> Thanks to practical device patching processes. But this has already been discussed.

"  3.  If the vulnerability has been exploited, how do we stop a large
       scale attack before any damage is caused?"

=> I'd rather say how to mitigate. And above all, this attack first needs to be identified!
Of course with the Dyn attack, it was not an issue, but higly sophisticated malware targeting a well
chosen IOT target may remain undetected if goal is to exfiltrate valuable information for instance...

>> We have rephrased according to your suggestions. In general, the questions are organized around 3 points:

-          How to avoid that the devices have vulnerabilities at all.

-          If there are vulnerabilities, how to avoid that they are exploited.

-          If they are exploited, how to stop the attack.
 These points are also stated as research questions since those are aspects that are not fully solved today.

Typos and other minor comments:

** Section 3, item 5:
The following sentence deserves explanations:
        "(thereby, presenting a weak link and offering the potential of
        man-in-the-middle attacks this way)"
Where is the weak link? Is it the human-assisted step? Is it the channel where key exchange
is taking place but is vulnerable to eavesdropping?

>>> We have removed this sentence, since indeed, it was confusing.

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Jim Schaad <[email-masked]>
Date: Sat, 21 Apr 2018 11:06:13 -0700

One small comment in line

From: Garcia-Morchon O, Oscar <[email-masked]> 
Sent: Sunday, April 8, 2018 1:54 PM
To: Vincent Roca <[email-masked]>; Ari Keränen <[email-masked]>
Cc: [email-masked]; Jim Schaad <[email-masked]>; [email-masked]
Subject: RE: [T2TRG] [irsg] IRSG review of "State-of-the-Art and Challenges for the Internet of Things Security" (draft-irtf-t2trg-iot-seccons)

Dear Vincent, all,

From: T2TRG [mailto:[email-masked]] On Behalf Of Vincent Roca
Sent: Friday, March 23, 2018 7:46 PM
To: Ari Keränen <[email-masked] <mailto:[email-masked]> >
Cc: Vincent Roca <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Jim Schaad <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [T2TRG] [irsg] IRSG review of "State-of-the-Art and Challenges for the Internet of Things Security" (draft-irtf-t2trg-iot-seccons)

Dear Ari, authors, all,

Cheers,

   Vincent

----

Main comments:

>> We agree that there are many important topics, privacy is indeed one of them, in particular, in view of the latest news. In general, it is incorrect to assign weights to the list of security threa…

[JLS] I think that it might be reasonable to put that into the document.  That is that this list is not ordered in any way and different situations will focus more or less on each of these items.

This is against:

  the beginning.

 

Additional comments:

A few ones I've spotted:

Item 1:

 

Item 2:

 

 

** Section 5.9:

** Section 5.9:

term challenge.

            is nearby.

 

 

 

 

 

 

       devices at large scale?"

>> We have rephrased according to your suggestions. In general, the questions are organized around 3 points:

*	How to avoid that the devices have vulnerabilities at all.
*	If there are vulnerabilities, how to avoid that they are exploited.
*	If they are exploited, how to stop the attack.

 

** Section 3, item 5:

>>> We have removed this sentence, since indeed, it was confusing.

  _____

---

From: Mohit Sethi <[email-masked]>
Date: Sat, 21 Apr 2018 21:42:18 +0300

Hi Jim,

Fixed in the new version just submitted. New text says:

  The threats in the following list
    are not in any particular order and some threats might be more
    critical than others depending on the deployment scenario under
    consideration:

Hope this is sufficient!

--Mohit

On 04/21/2018 09:06 PM, Jim Schaad wrote:
> *From:*Garcia-Morchon O, Oscar <[email-masked]>
> *Sent:* Sunday, April 8, 2018 1:54 PM
> *To:* Vincent Roca <[email-masked]>; Ari Keränen 
> <[email-masked]>
> *Cc:* [email-masked]; Jim Schaad <[email-masked]>; [email-masked]
> *Subject:* RE: [T2TRG] [irsg] IRSG review of "State-of-the-Art and 
> Challenges for the Internet of Things Security" 
> (draft-irtf-t2trg-iot-seccons)
>
> Dear Vincent, all,
>
> *From:*T2TRG [mailto:[email-masked]] *On Behalf Of *Vincent Roca
> *Sent:* Friday, March 23, 2018 7:46 PM
> *To:* Ari Keränen <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Vincent Roca <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Jim Schaad <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [T2TRG] [irsg] IRSG review of "State-of-the-Art and 
> Challenges for the Internet of Things Security" 
> (draft-irtf-t2trg-iot-seccons)
>
> Dear Ari, authors, all,
>
> *Main comments:*
> >> We agree that there are many important topics, privacy is indeed one 
> of them, in particular, in view of the latest news. In general, it is 
> incorrect to assign weights to the list of security threats in section 
> 3 and deduce from it that privacy is 1/11th. Everyone has their 
> favorite threat. Stephen Farrell for example stated that bad 
> software/code is the most important threat. Anyhow, we have moved 
> privacy up on the list. However, we don't talk about privacy in the 
> abstract or the introduction. But we do not talk about many of the 
> other threats as well.
>
> [JLS] I think that it might be reasonable to put that into the 
> document.  That is that this list is not ordered in any way and 
> different situations will focus more or less on each of these items.
>
> This is against:
>
> >> You do mention that "privacy  is an integral part of cybersecurity" 
> but then ask us to remove privacy considerations? Of course, we could 
> have another document focusing only on privacy. But while we wait for 
> that, we think that for completeness, it is better to have the current 
> text around privacy. This is in the end the goal of this document, to 
> have an overview of state of the art and challenges in IoT Security. 
> We have of course added definitions of personal data etc. and tried to 
> improve the existing text based on your background.
>
> >> This is a pretty specific use case. We describe a generic use case, 
> but this draft is not about describing specific ones. In an early 
> version of the draft (back in 2012), we had even security profiles for 
> difference scenarios (one of them, a home but also smart city, etc). 
> However, it was decided to leave them out and focus on an overview of 
> challenges.
>
> *Additional comments:*
>
> >> We have included a short paragraph describing this model. But it is 
> better to not include specific vendors. The reasons being that we 
> should be vendor independent and the list above is also not complete, 
> just consider Nokia Smart home gateway 
> https://networks..nokia.com/solutions/smart-home 
> <https://networks.nokia.com/solutions/smart-home> and Akita 
> https://www.kickstarter.com/projects/akita/akita-instant-privacy-for-smart-homes. 
> This list would never be complete.
>
> >>  It applies in multiple ways. One of them relates to long term 
> confidentiality, also important in IoT. But there are also other use 
> cases. For instance, IoT devices remain operational for long time (> 
> 10 years). At some point of time, digital signatures used today will 
> not be secure anymore, so that for those devices it will not be 
> feasible to deploy a software update in a secure way. We have added a 
> line describing this.
>
> ** Section 5.9:
>
> >> We agree that there are many definitions for privacy. We have 
> included clarifications according to your points, but we doubt whether 
> removing the reference is right.
>
> ** Section 5.9:
>
>         broader than that. Inference is through auxilliary 
> information, be it from IOT devices or anything else.
>
> >>We have improved the description that we very briefly summarized from 
> Ziegeldorf so that they reflect your comments. Note that in this 
> document we discuss the different topics briefly so that we can have 
> an overview of them.
>
> Then the difficulty with a list is to be sure it's reasonnably 
> exhaustive (otherwise it should be said it’s not
>
> => By reducing risks. That's also the goal of 
> labelisation/certification initiatives in the domain (see
>
> *Typos and other minor comments:*
>
> ** Section 3, item 5:
>
> ------------------------------------------------------------------------
>
> The information contained in this message may be confidential and 
> legally protected under applicable law. The message is intended solely 
> for the addressee(s). If you are not the intended recipient, you are 
> hereby notified that any use, forwarding, dissemination, or 
> reproduction of this message is strictly prohibited and may be 
> unlawful. If you are not the intended recipient, please contact the 
> sender by return e-mail and destroy all copies of the original message.
>
>
>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Vincent Roca <[email-masked]>
Date: Thu, 26 Apr 2018 14:53:12 +0200

Dear Authors,

Sorry for this late answer. Here are my answers WRT version -14.
Note that I’ve removed all items where we agree.

> >> We agree that there are many important topics, privacy is indeed one of them, in particular, in view of the latest news. In general, it is incorrect to assign weights to the list of security thr…

VR: Sure, I understand. That being said, and it was my point, I see more and more often « security and privacy » in
official documents from the European Union. For instance, several H2020 European calls for proposals are titled in this way:

https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds03-2019-2020.html <https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds03-2019-2020.html>
(TOPIC : Digital Security and privacy for citizens and Small and Medium Enterprises and Micro Enterprises)

https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds04-2018-2020.html <https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds04-2018-2020.html>
(TOPIC : Cybersecurity in the Electrical Power and Energy System (EPES): an armour against cyber and privacy attacks and data breaches)

https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds05-2018-2019.html <https://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/su-ds05-2018-2019.html>
(TOPIC : Digital security, privacy, data protection and accountability in critical sectors)

and I could find other examples.

There’s undoubtedly a European bias. However I fully support the idea of moving the privacy threats at the same
level as security threats instead of having it as one of the (huge number) of security items. Mentioning it earlier
(abstract and/or intro) was a way to improve it.

> >> You do mention that "privacy  is an integral part of cybersecurity" but then ask us to remove privacy considerations? Of course, we could have another document focusing only on privacy. But whil…

VR: I understand. Both strategies are possible and make sense. Let’s leave it as it is.

> >> This is a pretty specific use case. We describe a generic use case, but this draft is not about describing specific ones. In an early version of the draft (back in 2012), we had even security pr…

VR: Okay. I was not aware of the document history...

> - Fsecure Sense [https://www.f-secure.com/fr_FR/web/home_fr/sense <https://www.f-secure.com/fr_FR/web/home_fr/sense>]
> - Symantec [https://us.norton.com/core <https://us.norton.com/core>]
> - Safethings [https://safethings.avira.com <https://safethings.avira.com/>]
> - Bitdefender [https://www.bitdefender.com/box <https://www.bitdefender.com/box>]
> - Luma smart Wi-Fi router [https://lumahome.com <https://lumahome.com/>]
> - Dojo [https://dojo.bullguard.com/ <https://dojo.bullguard.com/>]
> - Cujo [https://www.getcujo.com <https://www.getcujo.com/>]
>  
> >> We have included a short paragraph describing this model. But it is better to not include specific vendors. The reasons being that we should be vendor independent and the list above is also not complete, just consider Nokia Smart home gateway https://networks.nokia.com/solutions/smart-home <https://networks.nokia.com/solutions/smart-home> and Akita https://www.kickstarter.com/projects/akita/akita-instant-privacy-for-smart-homes <https://www.kickstarter.com/projects/akita/akita-instant-privacy-for-smart-homes>. This list would never be complete.

VR: Of course, no reference should be provided to specific equipments. My non-exhaustive list was there only meant to illustrate the trend.
I’m okay with the added paragraph. Thanks.

[…]

> >>  It applies in multiple ways. One of them relates to long term confidentiality, also important in IoT. But there are also other use cases. For instance, IoT devices remain operational for long t…

VR: IoT use-cases I have in mind won’t last for a decade, but you’re right, there are other situations where this might
be important.

> >> We agree that there are many definitions for privacy. We have included clarifications according to your points, but we doubt whether removing the reference is right. 

VR: I let you judge.

> >>We have improved the description that we very briefly summarized from Ziegeldorf so that they reflect your comments. Note that in this document we discuss the different topics briefly so that we…

VR: Sure, it’s a difficult exercise, I understand.

You’ve adde a typo during the process, in item 5: "is sold" => "sold"

[…]

Cheers,

  Vincent