Subject: [T2TRG] some comments on draft-irtf-t2trg-iot-seccons-06.txt

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Sep 2017 08:32:31 +0200

Hi everyone,

This draft is coming along very well.  Just a few small issues.

Section 2.2, bullet #3:

Is that meant to be "Secure Bootstrapping" or "Security Bootstrapping"? 
The definition could use some sharpening, but I don't know which way to
suggest without some clarification from the authors.

Section 5.1.4 overreaches just a bit when you write:

>    D2D is primarily driven by network operators
>    that want to utilize short range communication to improve the network
>    performance and for supporting proximity based service

I don't think you need to say that.  There are a plethora of reasons for
D2D.  Let me give you just one example.  The people at the University of
Nebraska use a form of D2D to provide telemetry up and down a cargo
train, using very low power communications.  While proximity plays a
role, network performance isn't the issue.  It's the 5 year battery life
that must be maintained in a box car.

Section 5.2 should mention draft-ietf-anima-bootstrapping-keyinfra, as
ongoing work that is directly relevant.

Section 5.3.1 should probably at least talk about the limitations of
group keying when it comes to validating the source of a message, and
the need for additional measures (object/message signing, or other) for
that purpose, and maybe even refer to limits of those measures (e.g.,
sig/validation CPU processing / latency costs (a referral back to
Section 5.1.1 might do well).

Section 5.4 reads a bit like a newspaper and current events.  That makes
the document fragile over time.  My suggestion is that you distill the
issues and principles, and indicate what is left for future work.  It is
not necessary, IMHO, for an RFC (which is where this is going) to play
the role of a news search engine, although perhaps a brief reference to
ongoing activity is ok.

Section 5.6 could use some beefing up.  End of life is a massive issue. 
One could write an entire RFC on just this topic.  There are many issues
associated with it, including vendor support costs, proprietary software
issues, and carbon footprint. There are negative externalities as well. 
If I use a device past its support lifetime, a bug in that device may
not hurt me, but it may hurt you.  I have no incentive, therefore, to
throw the thing away.  Moreover, if I do just for that purpose, I could
be contributing to an environmental nightmare.  This has implications
for manufacturers, who may need to amortize support costs differently.

This section ties directly to software update, and so you might want to
switch sections 5.5 and 5.6.

Section 5.10 needs just a bit of elaboration on bullet points 1 and 3. 
How are long term keys exposed?  How are proprietary algorithms
counterfeited (I'm not sure I understand what that means)?

In Section 5.11, shodan.io is referred to.  I think you want to say a
bit more about this, because it lays plain just how bad the situation
is.  Saying *how* shodan.io gets its information is useful.  For
instance, there's a lot of misconfiguration out there.  There's some
fingerprinting going on, etc.  Also, the text reads as if the user won't
believe you.  You write: “This is not fiction but reality...”, which you
probably don't need to state.

Regards,

Eliot