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

From: Ari Keränen <[email-masked]>
Date: Wed, 21 Mar 2018 08:41:06 +0000

Dear IRSG,

We would like to request an IRSG review of the "State-of-the-Art and Challenges for the Internet of Things Security" Thing-to-Thing Research Group (T2TRG) draft: 

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

In preparation for the IRSG review this document was already thoroughly reviewed by the IRSG member Stephen Farrell, the shepherd Jim Schaad, and many others, and the document has been updated since to address the comments.

Thanks,
Ari

---

From: Vincent Roca <[email-masked]>
Date: Wed, 21 Mar 2018 09:52:27 +0100

Hello Ari,

I volunteer to review your doc.
Cheers,

  Vincent

> Le 21 mars 2018 à 09:41, Ari Keränen <[email-masked]> a écrit :
> 
> Dear IRSG,
>

---

From: Arbnor Zeqiri - Universitet <[email-masked]>
Date: Wed, 21 Mar 2018 10:41:03 +0100

Hello Ari,

I volunteer to review this draft.

Have a good time.

On Wed, Mar 21, 2018 at 9:52 AM, Vincent Roca <[email-masked]> wrote:

> > We would like to request an IRSG review of the "State-of-the-Art and
> Challenges for the Internet of Things Security" Thing-to-Thing Research
> Group (T2TRG) draft:
> >
> > In preparation for the IRSG review this document was already thoroughly
> reviewed by the IRSG member Stephen Farrell, the shepherd Jim Schaad, and
> many others, and the document has been updated since to address the
> comments.
> >
> >
> > Thanks,
> > Ari
>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg
>

-- 
Msc Arbnor Zeqiri
University of Mitrovica "Isa Boletini"
Teaching Assistant - Faculty of Mechanical and Computer Engineering
40000 Mitrovicë - Republic of Kosova
tel. (049 814-870)

---

From: Vincent Roca <[email-masked]>
Date: Fri, 23 Mar 2018 19:46:25 +0100

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.

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.

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.

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.

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.

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."

** 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.

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.

** 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!).

** 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).

** 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.

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.

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.

** 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.

** 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...

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?