[T2TRG] draft-irtf-t2trg-iot-seccons review comments

[Ari Keränen <[e-mail]>]

Hi Authors,

Here's my review comments for the T2TRG IoT Security Considerations draft. I tried to do a thorough "final" review so some of the comments are rather detailed. I used the 269603a commit version in Github.

Overall I think the draft is in pretty good shape and there's lots of good material worth publishing. However there are some issues I'd consider having a second look; see details below. Additionally I'll send you another mail with suggested editorial nits and tweaks. Those shouldn't require mail list discussion (but feel free to disagree).


Cheers,
Ari

---

Section 1:

I don't think a full history of the document (second to last paragraph) is needed in the final version. RFC5743 calls for description of level of support, but probably few sentences less is enough.

Section 3.1:
> The thing is later installed and commissioned within a network by an installer during the bootstrapping phase. Specifically, the device identity and the secret keys used during normal operation are provided to the device during this phase. 

The device ID and keys could also be provided before install/commission, during manufacturing. 

Section 4: I'm not sure SIP is worth listing as "related IP protocol".

> Privacy threat: The tracking of a thing's location and usage may pose a privacy risk to its users. An attacker can infer information based on the information gathered about individual things, thus deducing behavioral patterns of the user of interest to him. Such information can subsequently be sold to interested parties for marketing purposes and targeted advertising.

Probably targeted advertising is not the biggest problem here, albeit probably most common today. I'd recommend making clear that advertising is just one example and perhaps mention other/bigger risks too, such as tracking of dissidents in oppressive regimes. 

This is probably(?) only editorial issue, but there are many instance of "IoTs". Since the acronym is already plural ("Internet of Things"), the s in the end doesn't sound right. I'd recommend "s/IoTs/IoT/g" and occasional rephrasing where needed.

> DoS attack can be launched by physically jamming the communication channel, thus breaking down the T2T communication channel

Jamming breaks also other channels than T2T.

Fig 3: "Thing's model" sounds ambiguous. What does it actually mean?

Section 5.1:
> The CoRE working group {{WG-CoRE}} provides a framework for resource-oriented applications intended to run on constrained IP network (6LoWPAN). One of its main tasks is the definition of a lightweight version of the HTTP protocol, the Constrained Application Protocol (CoAP) {{RFC7252}}, that runs over UDP and enables efficient application-level communication for things.

Actually CoRE applies beyond 6LoWPAN, so maybe just drop that part in parenthesis and say "constrained IP networks".

And CoAP is not just "lightweight version of HTTP". I've been using "RESTful protocol for constrained devices, modelled after HTTP".

> Additionally industry alliances and other standardization bodies are creating constrained IP protocol stacks based on the IETF work. Some important examples of this include:

Makes sense to add OMA with LwM2M to the list since that's heavily re-using IETF CoRE and IP infra.

Section 5.4:
> Despite the acknowledgement that security in the Internet is needed and multiple guidelines exist, the fact is that many IoT devices and systems are not fully secure. 

"fully secure" is something we may never achieve, but with many current IoT devices and systems it's even much worse. So maybe say here "are not very secure".

Section 6.1.1:
> The IoT is a resource-constrained network that relies on lossy and low-bandwidth channels for communication between small nodes, regarding CPU, memory, and energy budget

IoT networks are not always low-bandwidth nor nodes constrained. For example critical MTC cases are usually quite the opposite. It's OK to focus on that part of IoT here but we shouldn't generalize that too far. And "IoT" is not a "network", so could say here e.g., "IoT devices are often using resource-constrained networks...".

Section 6.1.3:
> The term end-to-end security often has multiple interpretations.

We actually discussed this in lengths in the Amsterdam T2TRG meeting. See the end of notes in: https://www.ietf.org/proceedings/interim-2017-t2trg-01/minutes/minutes-interim-2017-t2trg-01-201703091000-00

Perhaps we could finally have a documented definition of this we can agree on?

> Even though 6LoWPAN and CoAP progress towards reducing the gap between Internet protocols and the IoT, they do not target protocol specifications that are identical to their Internet counterparts due to performance reasons.

IoT protocols such as CoAP and 6LoWPAN are Internet protocols. There are also non Internet protocols (esp. non-IP protocols) that are used for building "IoT", or rather M2M systems, but that's a different story.

Perhaps better wording here is "constrained Internet protocols".

> There are essentially five approaches to handle such end-to-end confidentiality and integrity protection while letting middleboxes access/modify data for different purposes:
[...]
> 2. Reusing the Internet wire format in the IoT makes conversion between IoT and Internet protocols unnecessary. However, it can lead to poor performance in some use cases because IoT specific optimizations (e.g., stateful or stateless compression) are not possible.

These two parts don't seem to be aligned; e2e security with middle boxes and not needing protocol conversion? And also issue with "IoT protocols" and "Internet protocols" (see my comment above).

And how about homomorphic crypto?

> Moreover, it cannot be used with encrypted data because the lack of cleartext prevents gateways from transforming packets.

I'm not sure if I follow the line of thought there.

> Currently the IoT based object security format based on COSE {{ID-cose}} is different from the Internet based JOSE or CMS. 

Again "IoT vs. Internet". Also in following sentence. 

> To the best of our knowledge, none of the mentioned security approaches that focus on the confidentiality and integrity of the communication exchange between two IP end-points provides a fully customizable solution in this problem space.

What is "a fully customizable solution"?

Section 6.3.1:
> Moreover, end-to-end security associations are an important measure to bridge the gap between the IoT and the Internet.

Again "IoT vs. Internet".

Section 6.3.2:
> All discussed protocols only cover unicast communication and therefore do not focus on group-key establishment. 

Here good to be more explicit which protocols. I assume (D)TLS and IKEv2 (ESP)?

Section 6.4:
> IoT devices have a reputation for being insecure at the time of manufacture.

What do you mean by this? Is that "already insecure when they are manufactured" or "to be secured after manufacturing", or something else?

Section 6.5:
> An IoT device user/owner would like to monitor and know if the device is calling home (i.e. verify its operational behavior). 

Not everyone will be familiar with "calling home" feature. I'd suggest re-phrasing or explaining that.

> For example, the user should be ensured that his/her TV is not sending data when he/she inserts a new USB stick.

In some cases this could be legitimate thing to do (right?).

Section 6.8:
> First, functionalities enabled by means of RSA/ECC - namely key exchange, public-key encryption and signature - would not be secure anymore due to Shor's algorithm. Second, the security level of symmetric algorithms will decrease, e.g., the security of a block cipher with a key size of b bits will only offer b/2 bits of security due to Grover's algorithm.

If there's an easy (like sentence or two) way to explain Shor's and Grover's algorithms, that might be useful here. Otherwise it's probably better to actually shorten this and just say that the crypto operations are not secure anymore and give references.

Section 6.9 ("Privacy protection"):
> When IoT systems are deployed, the above issues should be considered to ensure that private data remains private. How to achieve this in practice is still an area of ongoing research.

Could refer to RFC6973 here and e.g., RFC7221 too for recent IETF work on the topic.

Section 6.11:
> The idea behind MUD files is simple: devices would disclose the location of its MUD file to the network during installation. The network can then (i) retrieve those files, (ii) learn from the manufacturers the intended usage of the devices, e.g., which services they require to access, and then (iii) create suitable filters.

I think you can go beyond "suitable filters" with MUD. For example using anomaly detection algorithms. And would be good to clarify what kind of filters you mean (firewall rules?).