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

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Jan 2018 16:10:29 +0000

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.

-- 
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: Fri, 5 Jan 2018 17:52:00 +0100

Hi Stephen,

Just a few comments on top of your comments:

On 05.01.18 17:10, Stephen Farrell wrote:
>
> SF review of draft-irtf-t2trg-iot-seccons-09
> 20180105
>
> (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:-)
>
> - 50 pages, sheesh

A few of us are considering writing a book on this subject.  The
challenge will be keeping it under 600 pages.  Of course, picking the
RIGHT 50 pages for this work is a different story.

Totally agree with your top point that the audience and intended use has
to be crystal clear up front.

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

Yes, but it has to mesh with your top point.
>
> - 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."

If you think THAT's sales speak...  Emm... we're talking about massive
swathes of devices that have nothing whatsoever in common except for the
idea that they have a transceiver, and are all classed IoT.  The spin
started a long time ago.
>
> - 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.

There are actually two points: old code and unpatched code.  Old code
isn't necessarily bad if there are no known vulnerabilities with it. 
Let's face it: there aren't too many reports of problems with /bin/true.

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

Different devices need to handle this differently, and this is a
fundamental challenge to keeping such a doc smaller.  For instance,
Internet Barbie probably needs different capabilities in this regard
than, say, building lighting and management, which has different
requirements from, say, a car, which has different requirements from,
say, a manufacturer floor robot.  The best I think one can do is
establish a bit of a matrix.

>
> - 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. 
>
> - p6, Security for these devices is not more important than
>   for other (sub)systems. The reason security for these
> devices deserves additional effort is that to-date, vendors
> have done a terrible job. The situation today with these
> devices resembles PC security about 20+ years ago.

There's SOME of that but I would take care not to lay all of that on IoT
vendors.  Shining security successes of any form are hard to come by. 
To me the key is that "IP on everything" has become a bit more of a
reality, and when one gets beyond general purpose computing with its
well known business model and environmental constraints, there's some
fresh thinking needed to look a problems we either thought solved or
didn't care about.  And you've hit on some of that above.  How long does
a device remain active?  What are the crypto implications for that? 
What about planning updates, not to mention memory (which really hits
COGS)?  How long to do that for?  Those were relatively easy questions
when 4 years is the average lifetime of a laptop with oodles of memory. 
Harder when we're talking 15.

>
> - 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.
>
> - 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.
>
> - 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.
>
> - p12, Mirai shows that sets of crap devices can create a
>   DDoS vector - that deserves a mention here. (And you note
> it in 4.3.)
>
> - 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:-)
>
> - 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. 

It depends on the goal and audience.

>
> - 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.
>
> - 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.
Agree.  Suggest, "to minimize risks at a reasonable cost, and to
mitigate vulnerabilities as and when they are discovered."  Or some such.
>
> - p12, a PIA ought also consider the kind of inferences that
>   an observer of the system can make and re-identification
> and is not only about handling PII
>
> - 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. 
>
> - 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.
>
> - 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.
>
> - p21, one of the significant challenges here is vendor
>   lock-in. IMO, that encourages short-term thinking (e.g.
> "it'll be more secure since it only talks to our
> cloud-server") but at the possible longer term cost of not
> getting security and multi-vendor interop. which is what the
> buyers of devices presumably would prefer.

I am not sure I understand your point.  multi-vendor interop is itself a
threat vector, from an epidemiological perspective.  That is-
interoperability comes at a cost, but one people often think is worth
paying.  My favorite example of this was the Morris worm, not because of
how widely it spread, but because it didn't go father due to processor
differences.  But it also goes to Geer at al and monocultures.  I don't
know if I would address that in this work, other than perhaps to point
out that a convergence in IoT approaches will have the usual pluses and
minuses, just as has happened elsewhere (e.g, SNMP or even the processor
fiasco).

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Jan 2018 17:29:37 +0000

Hiya,

> Just a few comments on top of your comments:

Same here.

> A few of us are considering writing a book on this subject.Â  The
> challenge will be keeping it under 600 pages.Â  Of course, picking the

Fair point.

> to be crystal clear up front.

Right. Some audiences might only need 10 pages with good
references. Others might need that book but that'd not be
a good RFC.

> If you think THAT's sales speak...Â  Emm... we're talking about massive
> idea that they have a transceiver, and are all classed IoT.Â  The spin
> started a long time ago.

Sure. Doesn't mean an RG draft needs to contribute
more to that pile though. (For at least this reader,
such text is very off-putting.)

> There are actually two points: old code and unpatched code.Â  Old code
> isn't necessarily bad if there are no known vulnerabilities with it.Â 

Fair enough. I guess it'd have been more accurate to say
"old packages" or some such. I do think the versioning of
e.g. the linux kernel used tends to tell a lot.

> Let's face it: there aren't too many reports of problems with /bin/true.

Well, I thought [1] was interesting. But sure.

   [1] https://lists.gnu.org/archive/html/coreutils/2017-12/msg00045.html

> fundamental challenge to keeping such a doc smaller.Â  For instance,
> say, a manufacturer floor robot.Â  The best I think one can do is

True. Text based on your paragraph above though could be a
good addition.

> vendors.Â  Shining security successes of any form are hard to come by.Â 
> didn't care about.Â  And you've hit on some of that above.Â  How long does
> a device remain active?Â  What are the crypto implications for that?Â 
> COGS)?Â  How long to do that for?Â  Those were relatively easy questions
> when 4 years is the average lifetime of a laptop with oodles of memory.Â 

I don't think the duration creates any real new issues.
Memory, power etc constraints do. But I guess I would
defend the proposition that yes, vendors have done a bad
job to date, just as was the case with PCs in the '90s.
We're in a better place with PCs now, and will also be
with smaller devices in a shorter timeframe (I expect)
but IMO a lot of the security/privacy issues in this
context are down to commercial decisions about pricing
and time to market and aren't that much to do with
technical constraints. (But we're digressing, I am not
suggesting the draft ought try to allocate blame for
the current situation.)

> Agree.Â  Suggest, "to minimize risks at a reasonable cost, and to
> mitigate vulnerabilities as and when they are discovered."Â  Or some such.
>>
> I am not sure I understand your point.Â  multi-vendor interop is itself a
> threat vector, from an epidemiological perspective.Â  That is-
> paying.Â  My favorite example of this was the Morris worm, not because of
> differences.Â  But it also goes to Geer at al and monocultures.Â  I don't

From the POV of someone deploying I think vendor lock-in
is a fairly clear threat in this context. Esp when one
thinks about services that are suddenly EOL'd by the
vendor. I agree that multi-vendor interop doesn't in
itself mean "more secure" but it does at least tend to
force use of explicit well-defined security mechanisms
that can (appear to be) unnecessary in a single-vendor
environment. And yes, sometimes when forced to define
such mechanisms, it becomes clear that nobody would
use the resulting system for various reasons. (E.g. if
the answer were "use whatever flavour of IPsec you
prefer":-) So I'm not saying multi-vendor interop is
always "right" but dealing security without vendor
lock-in is a challenge worth a mention I reckon.

Cheers,
S.