Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons

From: Mohit Sethi <[email-masked]>
Date: Tue, 13 Feb 2018 14:44:13 +0200

Hi Stefan,

Thanks for the detailed review. We have submitted updated versions to 
address your concerns. You can find the latest version (-11) here: 
https://tools.ietf.org/html/draft-irtf-t2trg-iot-seccons-11 and the diff 
from the earlier version which you reviewed (-09) here:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-irtf-t2trg-iot-seccons-09.txt&url2=https://tools.ietf.org/id/draft-irtf-t2trg-iot-seccons-11.txt

Here are our responses to your comments:

> I wasn't
> clear who are the intended readers - if this is mainly
> meant for the RG, then does it need to be an RFC? If
> the intended readership is someone else, then who?
> And will the current text be useful for that set of
> folks?

The draft says in the abstract "This document can be used by IoT 
standards specifications as a reference for details about security 
considerations applying to the specified protocol.". Will this draft 
solve all the IoT security problems and save the world? No. That was 
never the intention. The draft provides a summary/collection of major 
security challenges for IoT and the existing tools and protocols that 
are available. This would serve as a good read for those designing new 
protocols. And instead of repeating many of the generic security 
considerations in each draft,  they could simply refer to this document.

> (Note that I suggest referring to rfc 8240 and the LPWAN
> overview draft and am an editor for both of those. I do
> think they'd be good additions, but didn't want you to think
> I'm sneakily trying to up my h-index:-)

They are now added at relevant places in the document.

> - 50 pages, sheesh

The draft is currently 30 pages long with 10 pages of references. Yes, 
it is relatively long. But this an RG document that summarizes a lot of 
things.

> - p1: crap code is surely the biggest security challlenge
>   here, if this doc is to be useful it'll need to recognise
> that.

The draft says in section 3: "Vulnerable Software: Things in the 
Internet of Things rely on software that might contain bugs.  This makes 
the things vulnerable to many different types of attacks, depending on 
the criticality of the bugs, e.g., buffer overflows or lack of 
authentication."

> - p3: I don't see the point of sales-speak such as "The
>   things that are part of the Internet of Things are no
> longer unresponsive and have transformed into computing
> devices that understand and react to the environment they
> reside in."

Not a sales pitch but rephrased anyhow.

> - p4, the lifecycle doesn't start when a tangible device is
>   manufactured but rather when the oldest bit of code the
> ends up in the device was written.  That's a significant
> point, esp for smaller vendors who often re-use unpatched
> old builds that "work" but may be wildly insecure.
> - p4, I'd argue that the lifecycle could include some
> recognition of OSS, but I'm not sure how to properly
> include that.
> - p4, the lifecycle could also include an on-the-shelf phase
>   and a phase where a device is re-badged by some vendor who
> wasn't the actual original manuf.  Such phases can
> significantly complicate s/w update and bootstrapping.
> - p4, there are two other end-states that probably ought be
>   part of the lifecycle - where a vendor end-of-life's a
> device type that's still in use and where a device is simply
> forgotten but keeps on trucking. 

Good points. We have added a paragraph before Figure 1 stating that the 
described lifecycle is a simplified model that can be extended, e.g., 
with the situations that you describe.

> - p7, section 2.2 seems pointless if it's not used later in
>   the document - you may as well delete this. FWIW, I don't
> find figure 3 useful.

Removed.

> - p9, the list seems to me to be very for-profit-vendor
>   oriented.  I wonder would a non-profit or device-using
> organisation write a different list? I think they would,
> e.g. they might include "crap s/w" and "attempted capture
> via proprietary APIs/data formats/cloudy services" as
> threats.

We do say that the list is not-exhaustive. Some of it has more to do 
with business security than actual device/system security.

>
> - p11, I would argue that privacy deserves much more
>   attention in this document than this, and that this
> document isn't much use without that. For example, it's
> important to include the scenario where a static sensor
> emits a packet due to the presence/absence of people - in
> that scenario anyone who can see that packet can potentially
> invade the privacy of the people involved.  You do include
> more in section 5, but see my comment below about how that
> section is(n't:-) organised.

We have added this example to Section 5.9.

> - p20, "the fact is that many IoT devices and systems have
>   very limited security." It seems a bit late to say this on
> page 20:-)

Added some text earlier in the document (for example, in the abstract).

> - p21, I'm not sure an RFC is a good place to wonder about
>   potential future regulation, unless that's to be done in a
> more thorough manner. I'd say deleting the last two
> paragraphs of section 4.3 and replacing those with a single
> sentence that "redional regulations aren't unlikely" might
> be better. 

Removed some text and added that regional regulations aren't unlikely.

>
> - p22, I don't agree with the crypto points made (IMO, only
>   devices that can verify an occasional signature ought be
> exposed to the Internet) - but even so the references here
> aren't good - curve 25519 ought be the main ECC reference
> relating to lessened CPU requirements. It's also a surprise
> to not see a mention of chacha.

Added references to curve 25519 and chacha.

>
> - p12, "Thus, ensuring a proper level of security in an IoT
>   system at any point of time is challenging.  To address
> this challenge, a process for secure product creation is
> required to ensure that an IoT system is secure and no
> security risks are present." That's just silly - aiming for
> a perfect system ("no security risks") is pointless as those
> do not exist.

Rephrased

> - p13, 4.1 should have some mention of LPWANs and indeed
>   those deserve more text in general as the set of usable
> security mechanisms and challenges differ in those parts of
> networks.  You do mention LPWAN in 5.1.4 - which confused me
> as that text probably should be here in 4.x.  You might also
> wanna reference the LPWAN overview draft, currently in IETF
> LC. 

Added in 4.1.

>
> - p16 and elsewhere - the state-of-the-art text should
>   really try to indicate which things are or more, or less,
> importanct. That can be tricky, but e.g.  presenting HIP as
> being of equal importance to (D)TLS here isn't useful, nor
> particularly credible. I also wonder if OSCOAP is as mature
> and important as the text implies.

Text has been adapted to make clear that TLS, DTLS are the most 
important protocols. Wording is added to make clear that HIP is less 
relevant and OSCoAP is relatively new.

> - p21, I don't get the logic behind the organisation of
>   section 5, it seems to be a just-so list if things
> described at fairly different levels of detail, e.g.  5.1 vs
> 5.2. I'd say a bit of thought as to how to organise this
> section could lead to a better organised text.  I'm not sure
> how that'd be best done myself, but perhaps some discussion
> within the RG would help there.

Section 5.2 is much shorter since the RG decided to include that 
material in a different Internet Draft.

> - p24, homomorphic crypto? Huh? I don't buy that at all.
>   And following the [SEAL] reference leads to a dead end.
> If you want to make a claim like this more detail would be
> needed. I'd say deleting this is best.

The text says that it is limited in use. However, this is an area in 
which many people are working and thus, we would rather keep it. We have 
updated the reference. Microsoft updated it in the last months.

> - p28 - how is referring to an expired draft from 9 years
>   ago (yes, 2009!) useful?

Removed.

> - p28, [iotsu] is better referred to via rfc 8240 and I
>   think a lot of the text in 5.4 is likely included in that
> report. The overlap is probably fine, but it'd be no harm to
> just check to see if anything else from 8240 would be worth
> including here.

Updated the reference to RFC 8240.

> - p33, at the start of 5.9 "Users" is the wrong term, you
>   should say "People" - that's not just a nit, but an
> important difference (and one worth explicitly calling out)
> as the people whose privacy is affected by devices need not
> be "users" in any sense at all. Automatic number plate
> scanners or camera based systems are usually good examples.

Updated as suggested.

> - p34, in 5.10 you could add some mention of and reference
>   to methods for h/w tamper detection/resistance.

Added

>
> - p36 says "Thus, a potential approach is the definition and
>   standardization of security profiles,..." That conclusion
> is not justified based on the text of this document.
> (Where's there anything that implies that this conclusion is
> warranted?) Secondly, I don't agree with the conclusion
> itself - in the case of RPL that approach has lead to
> nothing good happening that I've seen, and I'd expect it to
> lead to more fig-leaves if applied in other cases. Now,
> while I may be wrong, and your conlusion may be right, I
> think I'm fairly safe in saying that much more justification
> is needed before this conclusion could be credibly drawn.

Removed.

If you don't find some of your comments here, then we chose not to take 
any action on it. Please let us know if something is still needed.

Oscar, Sandeep and Mohit

On 01/05/2018 06:10 PM, Stephen Farrell wrote:
> Hiya,
>
> Carsten asked me to take a look at this draft and
> I said I would over the holidays, so I'm only a
> wee bit later than promised:-)
>
> In general, I think some more work is needed. Aside
> from the specific points in the attached, I wasn't
> clear who are the intended readers - if this is mainly
> meant for the RG, then does it need to be an RFC? If
> the intended readership is someone else, then who?
> And will the current text be useful for that set of
> folks?
>
> Apologies in advance if some of the issues I raise
> have been discussed in the RG before - I haven't
> had time to participate in the RG to date. (I'm also
> not subscribed to the RG list so please do cc me
> on any follow ups.)
>
> Cheers,
> S.
>
>
>
>
> _______________________________________________
> T2TRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/t2trg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2018 11:05:52 +0000

Hi Mohit,

Sorry for the slow response...

> considerations in each draft,  they could simply refer to this document.

So I'm not sure that the text in the abstract is really
right, but maybe it's just me misinterpreting that. I do
think this is a useful read for those writing code and specs
for protocols in this space, but I do not think they can
"simply refer to this" in order to deal with the challenges
they face. If the abstract said this is background material
but implementers and specification writers need to figure
out and document their specific threat models, and mitigations
based on those, then that'd be better.

The reason I asked about this is that it's fairly common
to find internet drafts where the security considerations
just says "go read RFCxxxx" and I don't think pointers like
that to this document would be a good outcome here.

> it is relatively long. But this an RG document that summarizes a lot of

Fair 'nuff I guess.

> Internet of Things rely on software that might contain bugs.  This
> makes the things vulnerable to many different types of attacks,
> depending on the criticality of the bugs, e.g., buffer overflows or lack
> of authentication."

Yes, that is point#10 in section 3. Personally I think
that's the biggest challenge in this space and deserves
to be better highlighted. And it's not simply vulns, (all
systems will have some CVEs) - some of the code we've
seen deployed really is just very very crappy e.g. with
default admin/admin access exposed to the Internet in
gazillions of cameras all findable via shodan. IMO such
cases aren't really "bugs."

I forget if the draft says somewhere that if you deploy
crap, that will be found and exploited, but it probably
ought. And a couple of pointers to examples of that
having happened would be good too.

> with the situations that you describe.

Fair enough. I'd highlight it more, but that's maybe a
matter of opinion. For me, figure 1 still seems too much
focused on what larger manufs will/can do for sets of
devices sold to larger customers.

> with business security than actual device/system security.

I still think there'd be value in the RG trying to reflect
inputs here from open-source developers, individual end
users and maybe pentesters. Did anyone try get review from
such folks? (Note: I'm not saying I know what they'd say,
or if it'd make much difference, but I do wonder.)

> Added references to curve 25519 and chacha.

Great.

I still think the RG should consider whether to make a strong
recommendation that devices that are incapable of verifying a
reasonable signature are really highly likely to cause trouble.
IOW, couldn't the RG RECOMMEND that such devices ought not be
even indirectly exposed to the Internet, given the real-world
threats faced? If the RG did have consensus on that, then that
would I think help those developing standards and subsequent
users of devices built to those standards.

> updated the reference. Microsoft updated it in the last months.

My scepticism remains unchanged:-)

I don't think this is useful background for the intended
audience until after someone has documented a usable scheme
e.g. via a CFRG RFC.

>> scanners or camera based systems are usually good examples.

Thanks. I think it'd be useful to explicitly point out the
difference though - the set of people affected by devices can
be much bigger than the set of users of those devices, and
implementers and people writing standards ought to, but perhaps
don't, consider both, esp. when it comes to privacy issues.

>> is needed before this conclusion could be credibly drawn.

Thanks. That does leave section 6 without "next steps"
though doesn't it? I guess you could say that implementers
and those writing spec need to consider how all of these
issues (and those that emerge later) affect their work,
and need to devote real effort to addressing these issues,
and (for the spec writers) say how they've done that, so
that those reading and implementing are less likely to
screw up yet again;-)

Cheers,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Feb 2018 13:08:38 +0100

Hi Stephen,

> users of devices built to those standards.

I think this depends on just how connected we are talking about. Where
does one draw the line?  Surely we have seen Bluetooth exploits, for
example.  What about serial devices?  Does an actuator that takes a
simple +/- count?  To put this into some context, let's talk about
automotive vulnerabilities.  A classic way into a car is via the 3G
interface in the entertainment system, but an equally possible way in,
as Cantor et al demonstrated was via the diagnostic port.  Should a
brake actuator require authentication on the CAM?  How many ms do you
get or how many mw can you spend on the op before it impacts the
distance an electric vehicle can travel before its next charge?  A
careful drawing of the line is in order for any such recommendation, and
the parameters of that recommendation are worthy of exploration.

>>> Â  system at any point of time is challenging.Â  To address
>>> Â  those deserve more text in general as the set of usable
>>> networks.Â  You do mention LPWAN in 5.1.4 - which confused me
>>> as that text probably should be here in 4.x.Â  You might also
>>> Â  really try to indicate which things are or more, or less,
>>> importanct. That can be tricky, but e.g.Â  presenting HIP as
>>> Â  section 5, it seems to be a just-so list if things
>>> described at fairly different levels of detail, e.g.Â  5.1 vs
>>> section could lead to a better organised text.Â  I'm not sure
>>> Â  And following the [SEAL] reference leads to a dead end.
>>> Â  ago (yes, 2009!) useful?
>> Removed.
>>
>>> Â  think a lot of the text in 5.4 is likely included in that
>>> Â  should say "People" - that's not just a nit, but an
>>> Â  to methods for h/w tamper detection/resistance.
>> Added
>>
>>> Â  standardization of security profiles,..." That conclusion

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2018 12:41:52 +0000

Hiya,

On 22/02/18 12:08, Eliot Lear wrote:
> does one draw the line?Â  Surely we have seen Bluetooth exploits, for
> example.Â  What about serial devices?Â  Does an actuator that takes a
> simple +/- count?Â  To put this into some context, let's talk about
> automotive vulnerabilities.Â  A classic way into a car is via the 3G
> as Cantor et al demonstrated was via the diagnostic port.Â  Should a
> brake actuator require authentication on the CAM?Â  How many ms do you
> distance an electric vehicle can travel before its next charge?Â  A

I agree that any "baseline" crypto capability recommendation
would need such exploration and justification. OTOH, we do
kinda know that s/w update pretty much needs signatures, which
is why I suggest that the ability to verify some signatures
at some time(s) could be a good baseline capability to consider.
(That's not to suggest that all inbound messages to all devices
be signed, as that'd not be a good plan:-)

What I'm suggesting is that the RG do the exercise of trying
to see if such a baseline could be usefully described. (And as
I'm not on the RG list, it could be that that's been discussed,
but if so, that's not visible in this draft.)

Cheers,
S.

---

From: "Garcia-Morchon O, Oscar" <[email-masked]>
Date: Wed, 28 Feb 2018 08:33:37 +0000

Dear Stephen,

we have further improved the draft based on your comments.

The link below shows the diff between the current version and the previous version:

https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-irtf-t2trg-iot-seccons-11.txt&url2=https://raw.githubusercontent.com/t2trg/iot-seccons/master/draft-irtf-t2trg-iot-seccons-12.txt

Below also an explanation of the changes.

Kind regards, Oscar.

---------

>>>>>>>UPDATE: We updated the text in the abstract. It now reads: " This document can be used by implementors and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations."

cases aren't really "bugs." I forget if the draft says somewhere that if you deploy
>>>>>>>UPDATE: We updated the list in section 3 and moved "Vulnerable Software/Code" as the first security challenge. The text now reads "Vulnerable Software/Code: Things in the Internet of Things rely on software that might contain severe bugs and/or bad design choices.  This makes the things vulnerable to many different types of attacks, depending on the criticality of the bugs, e.g., buffer overflows or lack of authentication.  This can be considered as one of the most important security threat.  The large-scale distributed denial-of-service (DDoS) attack, popularly known as the Mirai botnet, was caused by things that had well-known or easy-to-guess passwords for configuration."

>>>>>>>UPDATE: We added text in section on software update. The text now reads "Therefore, it is necessary that devices which are incapable of verifying a reasonable signature are not exposed to the Internet (even indirectly). "

>>>>>>>UPDATE: We added text in section 6. The text now reads "Authors of new IoT specifications and implementors need to consider how all the security challenges discussed in this draft (and those that emerge later) affect their work.  The authors of IoT specifications not only need to put in a real effort towards addressing the security challenges, but also clearly documenting how the security challenges are addressed.  This would reduce the chances of security vulnerabilities in the code written by implementers of those specifications."

My scepticism remains unchanged:-) I don't think this is

useful background for the intended audience until after

someone has documented a usable scheme e.g. via a CFRG RFC.

>>>>>>>COMMENT: I agree that HE is an ongoing research topic. In initial versions of the draft, we did not have it. However, we added the possibility of homomorphic crypto after input from Ari Keraenen on 6/7/2017. The draft now states HE as possibility and acknowledges that the performance is still bad. However, advances are made and lots of people are actively working on it. As a side note and as part of an internal project, we did some experiments to protect -- by means of HE – data in a small algorithm. The experiments showed that in our specific application and also given the fact that the algorithm is not used very frequently, this approach for protection might actually be feasible/make sense. So, all together, I would keep this text.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, February 22, 2018 12:06 PM
To: Mohit Sethi <[email-masked]>; [email-masked]
Cc: Garcia-Morchon O, Oscar <[email-masked]>; Jim Schaad <[email-masked]>
Subject: Re: [T2TRG] review of draft-irtf-t2trg-iot-seccons

Hi Mohit,

> considerations in each draft,Â  they could simply refer to this document.

Fair 'nuff I guess.

>> Â  here, if this doc is to be useful it'll need to recognise

> Internet of Things rely on software that might contain bugs.Â  This

>> Â  things that are part of the Internet of Things are no

>> Â  manufactured but rather when the oldest bit of code the

>> ends up in the device was written.Â  That's a significant

>> Â  and a phase where a device is re-badged by some vendor who

>> wasn't the actual original manuf.Â  Such phases can

>> Â  part of the lifecycle - where a vendor end-of-life's a

>> Â  the document - you may as well delete this. FWIW, I don't

>> Â  oriented.Â  I wonder would a non-profit or device-using

>> Â  attention in this document than this, and that this

>> invade the privacy of the people involved.Â  You do include

>> Â  very limited security." It seems a bit late to say this on

>> Â  potential future regulation, unless that's to be done in a

>> Â  devices that can verify an occasional signature ought be

Great.

e.g. via a CFRG RFC.

screw up yet again;-)

Cheers,

S.

>> [email-masked]<mailto:[email-masked]>

--

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